commit df4510aec0063c7f96f5996a165c2261ec099358 Author: Greg Kroah-Hartman Date: Fri Nov 6 12:10:54 2026 -0500 Linux 7.3.2 Link: https://lore.kernel.org/r/20261104211038.406938024@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: SJ Park Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Takeshi Ogasawara 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 Tested-by: Justin M. Forbes Tested-by: Sean Lyon Signed-off-by: Greg Kroah-Hartman commit e53d1cf05da8ea58a5743b7ce5894fb51b0b9700 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 c314b2be197ac9f52189bbcdc5e1c49c1819ad8c Author: Namjae Jeon Date: Mon Oct 26 15:26:31 2026 +0900 ksmbd: keep retry timeout clamp bounds constant commit 146c3fc6540e24eef6296395a35bf5b924182e8b upstream. With CONFIG_HZ=1024, msecs_to_jiffies(1200) includes an overflow check that calls jiffies_to_msecs(MAX_JIFFY_OFFSET). Its saturation branch returns MAX_JIFFY_OFFSET, which exceeds the six-second upper bound. GCC 10.5 carries that branch into clamp_t()'s bounds check and fails to build ksmbd_tcp_writev() on MIPS. Compute the 1200 ms lower bound with DIV_ROUND_UP() instead, so both bounds are compile-time constants. The lower bound still rounds up to the next jiffy, and the retry interval remains between 1.2 and 6 seconds. Fixes: c0632d2010ff ("ksmbd: track delivery of queued TCP writes") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202610251743.jztr17Ib-lkp@intel.com/ Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b0ce89f6f6ed0285edcaf43729a9b0b71482ac18 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 efb488fd08fd9993d5bad6b6e2848d12a16e1a3a Author: Alice Ryhl Date: Wed Nov 4 15:12:38 2026 -0500 rust_binder: wake epoll on self-work queued to poll thread [ Upstream commit 985955d8e6b2b15cfd65b7ac6893e3a5a90c5870 ] When a thread pushes work to its own todo list, InnerThread::push_work() returns PushWorkRes::OkNotifyPoll if the thread uses epoll, but four call sites in thread.rs discard this return value. As a result, a non-blocking BC_* write that enqueues work onto the calling thread's todo list without also reading will not wake epoll. Check the return value and call self.process.notify_poll(false) when PushWorkRes::OkNotifyPoll is returned. This is similar to commit 97830f3c3088 ("binder: signal epoll threads of self-work"), but in C Binder pending thread work also prevented subsequent process work from waking epoll, causing a permanent hang, which is not the case in Rust Binder. This means that in practice, it merely delays notifications rather than completely failing to send them. Cc: stable@kernel.org Fixes: dbb17c9ea756 ("rust_binder: move (e)poll wait queue to Process") Reported-by: Poil Zero Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20261016-binder-poll-self-work-v1-1-c29c87d99abb@google.com Signed-off-by: Greg Kroah-Hartman [ sashal: adapted reply_inner() to unconditional immediate completion because TransactionFlag::DeferComplete is absent ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit edacf65866a9f397438d5b9ff9f43312b29b4b3c Author: Ian Bridges Date: Tue Nov 3 16:37:18 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 Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7b54fe3db87bc3dee16c66b400206978e515a705 Author: Namjae Jeon Date: Tue Nov 3 16:37:17 2026 -0500 ksmbd: rebind completed CREATE replays without draining the old channel [ Upstream commit 864bbcd5dc5e70d639a3011eae81a872b69ff402 ] A completed DurableHandleReqV2 CREATE can be replayed through another channel while its original channel is exiting. The existing replay path returns the open but leaves its connection and oplock references pointing at the old channel. Its open count also stays on that channel, and a later CLOSE through the surviving channel decrements the wrong counter. After checking the owner, lease key and persistent flag, verify that an active open is still published in the requesting session's file table. Do this even when no oplock was granted, and before processing a consumed replay. Do not read a borrowed opinfo session pointer for this check. Keep a healthy original binding. If the original channel is exiting or releasing, move the open and its own oplock references to the requesting channel. Serialize this with CLOSE using the session file-table lock, and with detach, reconnect and notification snapshots using m_lock. The earlier lock index and lease-table changes make their lifetimes independent of this connection change. No old-channel r_count wait is needed, including when an unrelated request remains active there. Account final close against fp->conn in one place, balance durable detach and reconnect, and transfer the count with a replay binding change. A final global lookup put may run after CLOSE has removed the volatile id; unlink the open from the inode list on that final close as well. A live completed CREATE replay may follow a break that lowered the durable open's batch oplock. Apply the batch eligibility check only to detached reconnects, while retaining the owner, lease key and persistent flag checks for active replays. Fixes: bb8bf7eb13b5 ("ksmbd: add SMB3 request replay support") Reported-by: Pan Guihua Signed-off-by: Namjae Jeon Retain the file lifetime and connection accounting groundwork needed by failed durable reconnect cleanup. Always unlink the open from the inode list on final close, including when a global lookup owns the last put. Charge that close to the bound connection and balance the count across durable detach, reconnect and reconnect failure. Serialize detach and reconnect with the inode lock, reject reopening a closed handle, and detach only the oplock belonging to that open. Preserve the existing byte-range lock connection lists and their reference transfers. Active CREATE replay rebinding is omitted because the independent lock indexing it requires is absent; no new helper is introduced. Prepare CREATE error cleanup to distinguish an open retained by the request from one that has not acquired that reference. Close and complete a retained request open explicitly, while preserving the existing put for the other case. This supplies the cleanup branch required by the durable reconnect unpublication fix without the unrelated tree-disconnect changes. Assisted-by: LLM Stable-dep-of: 248b5819591c ("ksmbd: fix use-after-free after a failed durable reconnect") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcfad21ec64c736f6fd08375123186b9f3b2684c Author: DaeMyung Kang Date: Tue Nov 3 14:48:26 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: Used non-const mnt_idmap pointers in stream write and truncate helpers to match existing xattr APIs. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff7debe48426132a6851378c3e3b015b117a34a4 Author: DaeMyung Kang Date: Tue Nov 3 12:03:53 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: retained non-const mnt_idmap pointers and passed NULL for the new argument in the additional get_file_stream_info() caller ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 44950fdcc645041912fecc257c01a1f253abf05e Author: Henry Hu Date: Tue Nov 3 12:03:40 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 struct mnt_idmap * parameter in ksmbd_acls_fattr() to match the existing UID/GID mapping helpers. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5b190b352b0ba85f4debe436f42950ced10fadb Author: Ian Bridges Date: Tue Nov 3 12:03:28 2026 -0500 ksmbd: fix app-instance non-durable supersede session UAF [ Upstream commit f728cfee6929057087c303d07d7a6a7c61196b48 ] ksmbd_close_fd_app_instance_id() supersedes a prior open that has the same AppInstanceId. It reaches that open's session through opinfo->sess. This pointer is not refcounted. Session teardown detaches durable handles before it frees the session. It does not detach a non-durable open. That open still points at the session through opinfo->sess after the session is freed. Another session can supersede the open at the same time. The supersede then takes a write lock through the stale pointer, in the freed session's file table. BUG: KASAN: slab-use-after-free in _raw_write_lock+0x71/0xd0 Call Trace: _raw_write_lock+0x71/0xd0 ksmbd_close_fd_app_instance_id+0xd9/0x670 [ksmbd] smb2_open+0x3e10/0xd910 [ksmbd] Freed by task 212: ksmbd_session_destroy+0x38d/0x480 [ksmbd] Fix this by looking the session up by opinfo->session_id. The lookup returns a reference, as smb2_break_collect_channels() does. Recheck that opinfo->sess still points at it before using it. Do the lookup without m_lock held. destroy_previous_session() takes m_lock under the session table lock, and taking them in the other order here would deadlock. Fixes: 16c30649709d ("ksmbd: handle durable v2 app instance id") Cc: stable@vger.kernel.org # e0386cd6498b: ksmbd: validate AppInstanceId takeover target Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06b9fb5c9cee9620fdadb8a13eceac57f27e2907 Author: Namjae Jeon Date: Tue Nov 3 12:03:27 2026 -0500 ksmbd: retry break notifications on another connection [ Upstream commit 14ad1f21fbf05179116dd6ef4ab3b6556478fa50 ] An oplock or lease break belongs to an open that can outlive its original channel. A draining channel or stalled TCP writer can otherwise leave the break pending until timeout or invalidate a durable open. Snapshot the owner's live channels and try eligible connections with the same notification. Track TCP delivery separately from the SMB ACK, retry when a channel stops progressing, and share one break deadline. Run ordinary break waits on a dedicated workqueue so blocked request responses do not stall breaks. Publish NONE before sending a level II break, which requires no ACK, so an unsolicited ACK observes the completed level while TCP delivery is pending. Keep the first rename lease notification in the request context and enqueue the interim writer only after the notification is accepted. Join that work before returning so a blocked interim response does not stop notification retries or release the request early. Reported-by: Pan Guihua Signed-off-by: Namjae Jeon Stable-dep-of: f728cfee6929 ("ksmbd: fix app-instance non-durable supersede session UAF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c814ae191f8ec88e2dc44cff76c8c44cd6b621f7 Author: Namjae Jeon Date: Tue Nov 3 12:03:26 2026 -0500 ksmbd: track delivery of queued TCP writes [ Upstream commit c0632d2010ffc006eed9becc8d0d10d54f294bbd ] A nonblocking break send must distinguish a PDU accepted by TCP from one still queued in ksmbd. Retrying an accepted PDU can send duplicates, while abandoning a partial send can corrupt the stream. Queue owned PDU bytes when TCP cannot accept the full message. Track the stream position through socket delivery and TCP ACK, and expose it to break retries. Bound retained data and stop queued writes during teardown. Reported-by: Pan Guihua Signed-off-by: Namjae Jeon Stable-dep-of: f728cfee6929 ("ksmbd: fix app-instance non-durable supersede session UAF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 234689e9d91490ecf8184097562187f99e2ebb61 Author: Daijiamu <3058704216@qq.com> Date: Tue Nov 3 12:03:25 2026 -0500 ksmbd: use clear_and_wake_up_bit() directly [ Upstream commit 8852052e32df965a76daecbd8cda0ecf950b54df ] clear_and_wake_up_bit() was introduced by commit 8236b0ae31c8 ("bdi: wake up concurrent wb_shutdown() callers.") to replace the open-coded clear_bit_unlock() + smp_mb__after_atomic() + wake_up_bit() sequence. Replace the sequence and drop the now-trivial wake_up_oplock_break() wrapper, calling the helper directly at each call site. Suggested-by: ChenXiaoSong Signed-off-by: Daijiamu <3058704216@qq.com> Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Stable-dep-of: f728cfee6929 ("ksmbd: fix app-instance non-durable supersede session UAF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 52bda0cf91b62bf679d67d6a3adc20b0be8ff4f7 Author: Ian Bridges Date: Tue Nov 3 11:57:47 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 Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 824a572c0f909ca51fdb7e18e4eee33ca7896c7a Author: Jérémy Jean Date: Tue Nov 3 11:57:46 2026 -0500 ksmbd: fix SMB2 CREATE response buffer overflow [ Upstream commit 713c31a3a225b6239a37ac7fbfb394567f8b3519 ] smb2_allocate_rsp_buf() uses the MAX_CIFS_SMALL_BUFFER_SIZE (448-byte) buffer for a single SMB2_CREATE response. That buffer also holds a 4-byte length field, which only leaves 444 bytes for the SMB2 body. The AAPL response made this buffer too small. After 8f1b796ff113, a request with AAPL response contexts may need at least 456 bytes. In the 456-byte case, create_aapl_rsp_buf() is appended last, clears 128 bytes, and writes 12 bytes past the allocation. KASAN reports: BUG: KASAN: slab-out-of-bounds in create_aapl_rsp_buf+0x31/0x6e0 Write of size 128 at addr ffff88800370954c by task kworker/0:0/9 ... create_aapl_rsp_buf+0x31/0x6e0 smb2_open+0x58f9/0xef10 ... smb2_allocate_rsp_buf+0x19d/0x370 ... The buggy address is located 332 bytes inside of allocated 448-byte region [ffff888003709400, ffff8880037095c0) Reserve enough space for any fixed CREATE response KSMBD can build. Store the required allocation size in the per-dialect values table. This keeps the small buffer for other commands and avoids using the max transaction buffer for every CREATE. Fixes: 8f1b796ff113 ("ksmbd: add AAPL kAAPL_SERVER_QUERY create context support") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Namjae Jeon Stable-dep-of: 714f27729121 ("ksmbd: fix out-of-bounds read when padding the final compound response") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ece68b35c1609d3fa250b4a430f125054b2c7311 Author: Cheng Yongkang Date: Wed Nov 4 11:44:47 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 f2de154da4fd450377a282a948d1522b14a3d168 Author: Cheng Yongkang Date: Wed Nov 4 11:44:46 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 5f7e7afd5418c63473f6ac3a05219e9e6e8a59d9 Author: Kyle Zeng Date: Wed Nov 4 11:44:45 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 Signed-off-by: Greg Kroah-Hartman commit 8298ce6443ff75f7edc3e30c967270a9c3c12d4b Author: Chris Mason Date: Wed Nov 4 11:44:44 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 953174dcb862a7a364efdb65e178dcd3aea5562e Author: Chris Mason Date: Wed Nov 4 11:44:43 2026 -0700 io_uring: free the task context after a grace period Commit 9f5315d3f4368590c9fe06d4313b7247470bcf15 upstream. A task other than the owner can free a request, io_ring_exit_work() running the local task_work of a DEFER_TASKRUN ring for example, or io_do_iopoll() reaping completions. io_put_task() then takes the else branch: percpu_counter_sub(&tctx->inflight, 1); if (unlikely(atomic_read(&tctx->in_cancel))) wake_up(&tctx->wait); put_task_struct(tctx->task); The first line is what lets the owner leave io_uring_cancel_generic(), and on exec it frees the tctx right after. Nothing holds that off for the remaining three lines, the task reference only covers a tctx freed along with the task_struct. It used to work out because io_uring_del_tctx_node() took the uring_lock that the freeing side holds across io_put_task(), until that moved to tctx_lock. Free the tctx with kfree_rcu(), and enter an RCU read section in io_put_task() before the count is dropped. Fixes: 5623eb1ed035 ("io_uring/tctx: add separate lock for list of tctx's in ctx") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 521861b17a107875c884df9474e7746617f256d5 Author: Chris Mason Date: Wed Nov 4 11:44:42 2026 -0700 io_uring/bpf-ops: clear bpf_ctx while submitting SQEs Commit 8543a39f03db8816a2d80d0c92c132a19f2afb48 upstream. bpf_io_uring_submit_sqes() calls io_submit_sqes() from inside the loop program, with current->bpf_ctx set, and requests issued inline run with it set too. The socket code uses has_current_bpf_ctx() to recognize calls from bpf_setsockopt() and friends, where the caller holds the socket lock and has already been vetted, and skips both. So a SOCKET_URING_OP_SETSOCKOPT from the SQ passes sockopt_capable() without the capability, and runs without lock_sock(). A task with no capability can set SO_MARK, IP_TRANSPARENT or TCP_REPAIR, and two threads changing IP_OPTIONS on one socket, one through the ring, double free in no time. SOCK_DESTROY via IORING_OP_SENDMSG ends up in tcp_abort() without the lock the same way. Clear the run context around io_submit_sqes(). The SQEs come from userspace and must be issued like those of any other ring. They still run inside the program's RCU tasks trace read section, so a request that sleeps there holds up that grace period, but other request types do that already. Fixes: 890819248a86 ("io_uring/bpf-ops: add kfunc helpers") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1601d274c2810846cef01e445b864f7ada31bf4a Author: Chris Mason Date: Wed Nov 4 11:44:41 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 Signed-off-by: Greg Kroah-Hartman commit e98b26bc2a25c8aa9406daf2756a36489092bafc Author: Chris Mason Date: Wed Nov 4 11:44:40 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 Signed-off-by: Greg Kroah-Hartman commit 9f1afd6d70683a8115ba5da4ad7e90a497d7d3ca Author: Chris Mason Date: Wed Nov 4 11:44:39 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 Signed-off-by: Greg Kroah-Hartman commit 4f943e9fe98d7c62d98a9fd3621c45018a70cf83 Author: Josef Bacik Date: Wed Nov 4 11:44:38 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 6ee59400b97776253cc7a4317ff6d1d52c22f142 Author: Jens Axboe Date: Wed Nov 4 11:44:37 2026 -0700 io_uring: keep the drain active when a deferred drain request is started Commit 2295613cd3713beffc8665e956135a5d48dfc208 upstream. ecb6817b769f ends the drain when the dispatched drain request has posted its CQE and nothing else is deferred. But the deferred list is processed in between, and if the request it starts is itself a drain request, the drain is over before that one has even run. A request submitted after that point then runs ahead of it: 1. P0 in flight, D1 and D2 (both IOSQE_IO_DRAIN) deferred behind it 2. P0 completes, D1 is started 3. D1 completes, drain_done is set, D2 is started, the list is empty 4. IO_RING_F_DRAIN_ACTIVE is cleared with D2 still in flight Anything submitted now bypasses the drain. The same happens with D2 as the head of a link, as those aren't tracked in ->drain_req at all. Have io_queue_deferred() report whether it started a drain request, and don't end the drain if it did. Starting non-drain requests and ending it is still fine, they were only waiting on the drain request that just completed. Fixes: ecb6817b769f ("io_uring: end the drain when the drain request completes") Reported-by: Karl Mehltretter Link: https://lore.kernel.org/io-uring/20261027043323.98916-1-kmehltretter@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cbb8c211b5140a0ccb81e57f142083be5fb55b03 Author: Daan De Meyer Date: Wed Nov 4 11:44:36 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 681fc755316c4adb37ce481894fb619ff2c477fd Author: Dominik Maier Date: Wed Nov 4 11:44:35 2026 -0700 io_uring/register: enforce per-task restrictions in io_uring_register_blind() Commit 4a93427e99a8524f3612f29ec8bc0da5f8435a51 upstream. When io_uring_register(2) is invoked with fd == -1, it dispatches directly to io_uring_register_blind() without checking current->io_uring_restrict. As a result, a task with per-task register restrictions installed via IORING_REGISTER_RESTRICTIONS can still invoke blind registration opcodes such as IORING_REGISTER_SEND_MSG_RING even when those opcodes are not in the task's allowed register_op bitmap. Check current->io_uring_restrict->register_op in io_uring_register_blind() before dispatching blind registration opcodes. Fixes: ed82f35b926b ("io_uring: allow registration of per-task restrictions") Assisted-by: ARTIST LLM Signed-off-by: Dominik Maier Link: https://patch.msgid.link/20261022232121.2538616-1-dmnk@google.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cf635f0def46818d43f40c816b6ba0ff5f3f1618 Author: Dominik Maier Date: Wed Nov 4 11:44:34 2026 -0700 io_uring/net: mask socket type with SOCK_TYPE_MASK in io_socket_bpf_populate() Commit e66907c3ba229399ecfb4ef032b95a4a071c894e upstream. When an IORING_OP_SOCKET request is prepared in io_socket_prep(), sock->type retains creation flags such as SOCK_CLOEXEC and SOCK_NONBLOCK until __sys_socket_file() masks them off with SOCK_TYPE_MASK during execution. However, io_socket_bpf_populate() copies sock->type into bctx->socket.type without masking off ~SOCK_TYPE_MASK. As a result, a cBPF filter inspecting bctx->socket.type against socket types such as SOCK_DGRAM or SOCK_STREAM can be bypassed by ORing SOCK_CLOEXEC or SOCK_NONBLOCK into the socket type. Mask sock->type with SOCK_TYPE_MASK when populating bctx->socket.type. Fixes: cff1c26b4223 ("io_uring/net: allow filtering on IORING_OP_SOCKET data") Assisted-by: ARTIST LLM Signed-off-by: Dominik Maier Link: https://patch.msgid.link/20261022232120.2537530-1-dmnk@google.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit beddc87a6349f0c4dfe2f356a238a3793ae51fa2 Author: Yichong Chen Date: Wed Nov 4 11:44:33 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 49dd02e4f711ad6be852f00713ef777001c1b3fc Author: Yichong Chen Date: Wed Nov 4 11:44:32 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 eefd13e3cb2cf1ba7d95adbf7a6bfa4ead1ac9a3 Author: Lizhi Hou Date: Tue Sep 29 11:14:59 2026 -0700 accel/amdxdna: Add support for AIE2 revision 9 commit 63e91c1997898f32f68a5dbf68195d68b8e58443 upstream. aie2_get_dev_revision() fails to recognize AIE2 revision 9 hardware. Add AIE2_DEV_REVISION_GRGH to the list of supported AIE2 revisions. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260929181459.928468-1-lizhi.hou@amd.com Signed-off-by: Greg Kroah-Hartman commit 72b1e2fc0c878a23b6cd520955686254e7a9e53f Author: Derek J. Clark Date: Mon Sep 14 15:53:03 2026 -0700 HID: hid-lenovo-go-s: Use devm_kzalloc for drvdata commit d3c157b4cdffd14604c2d8435e279761c511bac2 upstream. Changes drvdata from static global to devm allocation per device. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit fba8d8f8352ce29d9f8994b4072886e1940fca23 Author: Derek J. Clark Date: Mon Sep 14 15:53:02 2026 -0700 HID: hid-lenovo-go-s: Move static led_classdev_mc to drvdata struct commit 7a5673e5f0f71cfe4004c1f1c3112cd1ea8ae1d9 upstream. In the next patch I will switch drvdata from static global to a devm_kzalloc struct. In preparation for that, move the led_classdev_mc to be a member of the gos_cfg_drvdata struct. As part of that effort, provide a constant name when accessing it and access the led_classdev through the led_classdev_mc. Fixes: be6d7dbb368ba840d7 ("HID: hid-lenovo-go-s: Add RGB LED control interface") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d69db0135c6ea7b1234d3fbf5abe78716b50224d Author: Derek J. Clark Date: Mon Sep 14 15:52:58 2026 -0700 HID: hid-lenovo-go-s: Add kobject_uevent notify during reset-resume commit 81e8c0bb3831fb84ef44417bba1b52333d0580a9 upstream. Adds kobject_uevent notification after setting os_mode attribute on resume. Fixes: 3524900cc571bd922a ("HID: hid-lenovo-go-s: restore OS_TYPE after resume from s2idle") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f8a0d1a1ff0a752116af2c601092a3c1634adca2 Author: Derek J. Clark Date: Mon Sep 14 15:53:01 2026 -0700 HID: hid-lenovo-go-s: Reorganize and rename hid_gos_cfg commit 186323f048317e033819291e5d70ad19ded53768 upstream. Renames hid_gos_cfg struct to gos_cfg_drvdata in preparation for later fixes. This is a prerequisite for later fixes. No functional change intended. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 313199a9902164c27ec869ab00bc52befaffc45e Author: Derek J. Clark Date: Mon Sep 14 15:53:00 2026 -0700 HID: hid-lenovo-go-s: Move attribute init to after device query commit 8f456881ba40a04494440663231ba773a06588f3 upstream. Currently this driver registers attributes before the MCU is ready to accept commands. This can lead to attribute access that blocks the MCU in some rare cases. Move attribute construction to gos_cfg_setup, after the device has been queried. Gate creation to drvdata.gp_registered and drvdata.rgb_registered so a resume before setup has run doesn't prevent attribute creation or attempt to re-register the same attributes. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 542a74e19639ac0e35979189bf7ec0ed022f8644 Author: Derek J. Clark Date: Mon Sep 14 15:52:55 2026 -0700 HID: hid-lenovo-go-s: Bound stale reply window before reusing send_cmd_complete commit 6224755416e627badf69b330afec9ac6b85e5098 upstream. mcu_property_out() reinits send_cmd_complete immediately after a timeout is detected, before the next command that reuses it is sent. If the MCU's reply to the timed-out command arrives after this reinit but before the next command's wait begins, it silently satisfies the next, unrelated command's wait instead of the one it actually answers, handing that caller stale data with no way to detect the mismatch. Track when a command has timed out via cmd_orphaned. Before the next command reuses the completion, wait a bounded 25ms for a stale reply to arrive and be consumed, then unconditionally clear the flag and reinit the completion. This does not fully eliminate the window in which an unrelated reply could still be received, but bounds it to a short interval right before a new command is sent. Behavior matches the solution to the same problem in hid-msi. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cd4a95557f3c156bf06bb2e2b5667d59343ebdb2 Author: Derek J. Clark Date: Mon Sep 14 15:52:59 2026 -0700 HID: hid-lenovo-go-s: Add suspend function and gate access under bool. commit e69b64d3d75eb10177f75d3d4947e032cb46eeb9 upstream. Currently a device can suspend while delayed work is pending or executing. Cancel delayed work if it was pending and restart it if it hasn't run yet. Gate access to show/store functions behind a bool to prevent access prior to cfg_setup() being completed. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5ae8f5f45f43b025df6d35afd04feae9a86b9a4b Author: Derek J. Clark Date: Mon Sep 14 15:52:57 2026 -0700 HID: hid-lenovo-go-s: Use pm_ptr for reset_resume callback commit 5c07247116ff749e09fe45cef439d7b2b66454b6 upstream. Adds missing pm_ptr to the .reset_resume callback for hid-lenovo-go-s Fixes: 3524900cc571bd922a ("HID: hid-lenovo-go-s: restore OS_TYPE after resume from s2idle") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0c66569ee94790614a9f9c78e8ad62cf3fdcf944 Author: Derek J. Clark Date: Mon Sep 14 15:52:54 2026 -0700 HID: hid-lenovo-go-s: Return ret instead of 0 in mcu_property_out() commit 8ac42b2885322dc7fb03d88c5411e9dbd24f80d9 upstream. Currently mcu_property_out() blanket returns 0, discarding the ret value and any errors with it. Wait completion returns a positive value when it is not timed out, which would error on all successes, so if it is positive return the ret value from the raw event handler. Only if it is 0 set it to -EBUSY, otherwise pass the actual error. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit df2b31428cb2e6c8f8fec8225b42e5e8d85bf7ee Author: Derek J. Clark Date: Mon Sep 14 15:52:56 2026 -0700 HID: hid-lenovo-go-s: Prevent deadlock if device removed during setup commit 0ef3036c68979194fdee77a3a825fb94ef307a54 upstream. hid_gos_cfg_remove() calls a mutex before canceling delayed work. That delayed work function calls mcu_property_out(), which holds the same mutex. Prevent deadlock my removing the mutex prior to stopping the work. Additionally, since cancel_delayed_work has the potential to re-arm, switch to disable_delayed_work. Fixes: a23f3497bf208c59ad ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Derek J. Clark Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9d918eadad41fe956185f3e3974e15e426a12de4 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 977b08b4f7e2e2d156d98a99b75bc41002496695 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 1e190aef086106e76c0e01cf9d9bbc2f0f32db7f 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 1b19a4415e9baac8f5fad0577756621d5bb14487 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 ab7282fa4d956cba0da12bc12fdf3c38886939b2 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 2265963373b820d70de3c4397dda5495b70fae35 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 9933238906e53b932d2e71addd749adfbffa04f9 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 eea6b9207e9af5548bc7aa54f725d0c19b605bbe 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 9e1793d9db78d32d6db9cc224cfbf17a54691c80 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 f8a96c52cf87efef7a5ab429a8f74193c9d728ea 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 ebe54f9e793bf05c7bd82110fdab24f10b89eac3 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 54a9b3a72c669c841e4e6499b487e9ceec607f1b 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 19711bd64d60378137353ac3e6b774bd3a660f89 Author: Myeonghun Pak Date: Fri Oct 2 17:44:16 2026 -0400 HID: mcp2221: always initialize and cancel init_work commit 6a006ff898b459e0bd10375d7fbe0ea7f7a132b9 upstream. The writable gpio_mode_enforce parameter can change between probe and remove. If it changes from false to true after probe, remove skips cancellation of init_work. Pending or running work can then access devm-managed driver state after teardown. Changing it from true to false can make remove cancel an uninitialized delayed work item. Initialize init_work whenever IIO is reachable and cancel it unconditionally on remove. Keep the parameter check only for scheduling the initialization. The false-to-true cancellation gap was previously reported by Sashiko. We also encountered this issue during our static-analysis research. Fixes: 200e6c6e94fa ("HID: mcp2221: Add module parameter to enfoce GPIO mode") Reported-by: Sashiko Link: https://lore.kernel.org/linux-input/20260715143415.916A21F00A3A@smtp.kernel.org/ Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Myeonghun Pak Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6ee339f14d81da30909075f2dc88926dd317591a 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 28d0c18328218cc1a5ea7341bd457c658aca0f73 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 f768b56558e8f327d595fe574afd0200e06d0a11 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 773307dd4c3e8c27eb31650af2df2d91cba22de8 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 b747cf83155509ef4009b6cf9ffbe45a0b0383ae 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 20518a118bf185e72f769eb07aeed5848c095d31 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 6b510a8a03a1d7bcc9de6cbdce3bbb2bbef1c07c Author: Panz Dev Date: Tue Aug 18 17:14:31 2026 +0200 HID: asus: do not send keyboard init reports to touchpads commit 8099f9da59f1c338bf88e25b7aa2a7fdf840879c upstream. Commit 0919db9f3583 ("HID: asus: always fully initialize devices") added a loop during asus_probe() to send keyboard feature report initializations (asus_kbd_init) to all ASUS HID devices. On ASUS laptops with I2C/HID touchpads (such as the ASUS E200HA), sending keyboard feature reports (FEATURE_KBD_REPORT_ID) to touchpad endpoints sends invalid feature requests to touchpad hardware, corrupting probe state and causing the touchpad to become unresponsive. Wrap the asus_report_id_init loop in an `if (!drvdata->tp)` check so keyboard feature initialization only runs for actual keyboards. Tested on ASUS E200HA (where touchpad functionality is fully restored) and ASUS VivoBook Flip 14 TP401MA (confirming zero regressions). Fixes: 0919db9f3583 ("HID: asus: always fully initialize devices") Cc: stable@vger.kernel.org Signed-off-by: Panz Dev Reviewed-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a59661811be67ac0911e9af44e43b9b7c169f065 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 368106434cb0a5fd10e0977cd44eb3ca96dab65d 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 e06f76c09e7cdb0851556ebf5939dd87550a387c 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 5226d19421d2e093ebd93ebe3d38e34e850bfe4f Author: Ahmed Yaseen Date: Fri Aug 28 10:42:21 2026 +0000 HID: usbhid: skip interrupt IN polling for devices with no input reports commit 4563e596bd913fb2d5b10b2ef306c754cf97ced2 upstream. usbhid starts polling a device's interrupt IN endpoint on open (usbhid_open() -> hid_start_in()). If the report descriptor declares no input reports there is nothing to read there, so the poll is useless, and on some composite devices it is also harmful. The ASUS ROG N-Key keyboards expose a second, input-less interface used only for RGB control via feature reports. Opening its hidraw node (any hidraw reader does, including SDL/Steam Input or a plain cat) starts the pointless IN poll and keypress reports on the keyboard interface get dropped for as long as the node stays open: a lost key-down drops a letter, a lost key-up leaves the key stuck. usbmon shows the dropped reports never reach the URB layer. The useless poll itself is long-standing; commit 4ac74ea68f64 ("HID: asus: early return for ROG devices") is what exposes it on these devices by keeping the input-less interface alive instead of ejecting it, so its hidraw node can be opened and the poll started. Skip the poll in usbhid_open() when the device has no input reports. Feature reports and hidraw output keep working over the control and OUT endpoints, so the interface is otherwise unaffected. Fixes: 4ac74ea68f64 ("HID: asus: early return for ROG devices") Link: https://discuss.cachyos.org/t/keyboard-input-issues-on-asus-rog-strix-16-2025-with-cachyos-during-gaming/30823 Link: https://github.com/ublue-os/bazzite/issues/4590 Cc: stable@vger.kernel.org Tested-by: Kerim Kabirov Tested-by: GameBurrow Signed-off-by: Ahmed Yaseen Reviewed-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 39006b7b1a7f9fae1a37344ec4ac2c5a300eb650 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 9ffe72ff3f1ef66dc554ecafbe0861c8c118eb41 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 fd224f1778e13660aec4e1f51fcdaeab5794e7ee Author: Sean Christopherson Date: Mon Sep 21 17:13:31 2026 -0700 KVM: guest_memfd: Establish memslot<=>guest_memfd bindings *after* memslot is ready commit 3fe5d2944e5ac3fc5073344b0982c73703332e18 upstream. Wait to bind a memslot to a guest_memfd instance until *after* the memslot is fully prepared, as creating the binding in guest_memfd will effectively expose the memslot to readers. As pointed out by Sashiko, binding the memslot before it's ready to be exposed to the rest of the world can break various memslot assumption and rules. E.g. x86 could observe a NULL rmap pointer if a PUNCH_HOLE hit the guest_memfd after the binding was created, but before KVM made it through kvm_prepare_memory_region(). Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260826170551.BEF801F000E9@smtp.kernel.org Link: https://patch.msgid.link/20260922001332.1121266-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 024be82ac4c4df650cc6daca6d7db79daee95470 Author: Shivank Garg Date: Tue Sep 1 07:20:38 2026 +0000 KVM: guest_memfd: take the invalidate lock when unbinding a dying file commit 0ee2c883b62deb74d8c43007e8049dc006d3a2fb upstream. kvm_gmem_unbind() takes mapping->invalidate_lock only if the get_file_active() succeeds. When the guest_memfd file is dying, its reference count is already zero so get_file_active fails and the binding is removed without holding the invalidate lock. kvm_gmem_invalidate_{start,end}() checks f->bindings independently to decide whether to begin or end KVM MMU invalidation. So, the bindings must therefore remain stable between the two calls. Otherwise, unbind can remove a binding after start increments mmu_invalidate_in_progress, but before end finds the binding and decrements it. Example, unbind race with memory failure: CPU 0: memory failure CPU 1: memslot delete ---------------------------------- --------------------------- (guest_memfd file is dying) kvm_gmem_error_folio() kvm_gmem_invalidate_start() finds binding mmu_invalidate_in_progress++ kvm_gmem_unbind() get_file_active() fails removes binding kvm_gmem_invalidate_end() no binding found counter stays elevated mmu_invalidate_retry() then returns 1 forever, so guest page faults retry without ever installing a mapping and the guest hangs. Remove the distinction between live and dying files in the unbind path. Always use slot->gmem.file and take the invalidate lock when it's non-NULL. Normal unbind callers hold slots_lock, which prevents release from clearing the pointer or freeing the file state until unbind completes. Final VM teardown can only see a NULL pointer because guest_memfd pins the KVM until release has cleared all bindings. Fixes: ae431059e75d ("KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dying") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260728092027.225CF1F000E9@smtp.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Shivank Garg Reviewed-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260901-gmem-unbind-fix-v2-1-12febe1d2216@amd.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 99944e95a375b8f4f45d56a574c727af86987d34 Author: Sean Christopherson Date: Mon Sep 21 17:13:30 2026 -0700 KVM: guest_memfd: Split bind() into prepare()+commit() phases commit 83411f32b8ad96c6b05b1511d1a588daab44bd25 upstream. Split binding a memslot to a guest_memfd instance into prepare() and commit() phases so that KVM can separate preparing the memslot from binding the memslot to the gmem instance, i.e. from committing the memslot. This will allow waiting to commit the memslot+gmem binding until the memslot is fully prepared, which is necessary as the memslot becomes reachable when the binding is created. As a bonus, drop the unwind-on-failure from the commit phase (other than nullifying the bindings), as the only reason bind() did the full unwind is because it technically didn't own the memslot, i.e. "needed" to leave memslot in the same state it started in. No functional change intended (the unwinding down on bind() failure was effectively dead code since KVM simply deletes the memslot on failure, i.e. there was nothing that could actually observe the unwind). Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260922001332.1121266-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 0f5a9b6e7b222595a3146320875203621bb22d7d Author: Xiaoyao Li Date: Wed Aug 19 17:49:02 2026 +0800 KVM: TDX: Enable Bus Lock VM exit commit 63d196e2e20429de5ba501f1b6059d9b93140007 upstream. Enable Bus Lock VM exit functionality for TDX guests. Bus Lock VM exit is an existing feature supported by KVM. Userspace can enable Bus Lock VM exit through KVM_BUS_LOCK_DETECTION_EXIT 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 Bus Lock VM exit for TDX guests by programming the BUS_LOCK_DETECTION control in the TD VMCS and by adding the exit handler. Note, there is no enumeration bit for this feature by TDX module because all TDX modules support it and allow to set the TD VMCS as long as the hardware supports the feature. Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported") Cc: stable@vger.kernel.org Originally-by: Chenyi Qiang Signed-off-by: Xiaoyao Li Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260819094903.3060020-9-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e29464ad0eb316a56dc17ec92479336bf338f8c6 Author: Xiaoyao Li Date: Wed Aug 19 17:48:58 2026 +0800 KVM: TDX: Don't assume exit_reason[31:16] is all-0 in tdx_to_vmx_exit_reason() commit bc335ce04408750585b4b32f248c543c9493d545 upstream. When handling the real Exit Reason, don't assume the upper 16 bits as all-0 in tdx_to_vmx_exit_reason(), in preparation for enabling Bus Lock VM exit. When Bus Lock VM exit is enabled, the bit 26 of Exit Reason becomes valid and it can be 1 with various exit reasons. Change the logic in tdx_to_vmx_exit_reason() to check the 'basic' Exit Reason for correctness. Also preserve bit[31:16] when changing the (basic) Exit Reason, to not lose the information in bit[31:16]. Change the return type of tdx_to_vmx_exit_reason() to "union vmx_exit_reason" for the convenience of manipulating the basic field. Fixes: c42856af8f70 ("KVM: TDX: Add a place holder for handler of TDX hypercalls (TDG.VP.VMCALL)") Cc: stable@vger.kernel.org Signed-off-by: Xiaoyao Li Link: https://patch.msgid.link/20260819094903.3060020-5-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 55bbc1ab487336f8be644757d9325d2c3654ab05 Author: Xiaoyao Li Date: Wed Aug 19 17:48:59 2026 +0800 KVM: TDX: Stuff exit_reason with UNDEFINED on wait_for_sept_zap return commit e5f1d62c59aea4f270773de1bf6e8867f5b1124c upstream. Forcefully update the exit_reason to KVM's "standard" EXIT_REASON_UNDEFINED if tdx_vcpu_run() bails without trying to run the vCPU because KVM needs to wait for an in-progress S-EPT zap to complete. This avoids handling the previous exit multiple times due to a stale exit_reason. Fixes: 4b2abc49712b ("KVM: TDX: Kick off vCPUs when SEAMCALL is busy during TD page removal") Cc: stable@vger.kernel.org Signed-off-by: Xiaoyao Li Link: https://patch.msgid.link/20260819094903.3060020-6-xiaoyao.li@intel.com [sean: use EXIT_REASON_UNDEFINED, drop comment about bits 31:16] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 07c720cd164fcdc9d3801ccf08ee84cff30bad51 Author: Xiaoyao Li Date: Wed Aug 19 17:48:57 2026 +0800 KVM: TDX: Set bits 31:16 to 0 and use UNDEFINED when synthesizing exit reason commit b43c520b198ab70868307a489ef2117ed6d6c4cc upstream. Set bits 31:16 to 0 instead of all-1s when synthesizing an exit reason, e.g. if the TDX Module never attempted VM-Enter, or when stuffing the exit reason due to an unexpected "real" EPT Misconfig. Opportunistically use VMX's KVM-defined EXIT_REASON_UNDEFINED (0xdead) instead of -1u. KVM is going to support Bus Lock VM exit for TDX, after which bit 26 of the Exit Reason becomes meaningful and indicates that a bus lock happened. The existing synthesized Exit Reason, -1u, will cause a false positive in that case. Change the synthesized Exit Reason from -1u to U16_MAX, so that bits 31:16 are set to 0. This also avoids the potential issues when other bits in 31:16 become valid in the future. As a bonus, the check for synthesized Exit Reason in tdx_failed_vmentry() becomes unnecessary. Just drop it. 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-4-xiaoyao.li@intel.com [sean: use EXIT_REASON_UNDEFINED instead of another magic value] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 02b92b0d7cdcda3c1f7196a3210bbe867ae6693e 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 8afd903bf712a6357e404f52c0995dd5c4a4b031 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 416da9d1824cf34c709f3222f5012714810734dd 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 e34057e59ed784a37657835aac9f54eec0864342 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 6513f7be321ea273ad19ceb08afeac2b93ea28dd 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 88df2f2f928addf78867a4af226fd62f5a132bf6 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 873ddb74ff0253e1cd1ebc88a77b9fb6d7830e9c 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 54f21a7fd8cccc21f1312ce17dfa47d45a68bf3c 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 ff7b7447397638c31200e87993589ea42d6f96ff 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 99aa3b5a308d469cab3a66a5dc80871f08b3b6f8 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 73f427e5afd94edd5d0e7cdddc2ecc794f28c492 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 0a751ea342e36aec367a915e38373a32b32870eb 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 b8fbd8c259c0b13811e1d81c1d89afdbbdf5b2d7 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 64bc41553f640a11b563cab1e2b878f78ef8f940 Author: Sean Christopherson Date: Mon Sep 21 16:56:55 2026 -0700 KVM: VMX: Formally define KVM's "0xdead" exit reason used for failed VM-Enter commit d85f7dc8cf3c91a131946dae4c3aa8d9c97322d7 upstream. Add EXIT_REASON_UNDEFINED to track KVM's magic "0xdead" value that's used to stuff the exit reason on a failed VM-Enter so that the magic can be reused by TDX, and to make it more obvious that it's an arbitrary, KVM- defined value (though the whole "dead" thing makes it pretty darn obvious). Opportunistically add a compile-time assert to ensure the KVM-defined exit reason never collides with a "real" exit reason. No functional change intended. Cc: Xiaoyao Li Cc: Yan Zhao Cc: Binbin Wu Cc: Rick Edgecombe Cc: stable@vger.kernel.org Reviewed-by: Binbin Wu Reviewed-by: Xiaoyao Li Link: https://patch.msgid.link/20260921235656.1107929-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 045e0736e5bd3cc8030bf7c60ed404c368b077b7 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 61478eb01872a86d54c934028c948fae746f651b 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 359888db0e2253365583376ab24dede981ce9f32 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 81c460713ca62fa33ee1241fda1ddaf099facb32 Author: Sean Christopherson Date: Wed Sep 2 16:20:24 2026 -0700 KVM: nSVM: Reject KVM_SET_NESTED_STATE if L1 has EFER.LMA=1 && EFER.LME=0 commit 5dc500a354cc8e109df678076ae3488094649468 upstream. Reject KVM_SET_NESTED_STATE if the incoming L1 host state has what is effectively an impossible EFER combination of LMA=1 but LME=0, i.e. if the state says long mode is active but not enabled. Unlike VMX, SVM doesn't have an explicit consistent check for the illegal combination; presumably hardware simply ignores EFER.LMA if EFER.LME=0. Unfortunately, KVM doesn't ignore EFER.LMA in this case and consumes the illegal state when constructing the shadow MMU for L2. E.g. if userspace also clears CR4.PAE, then kvm_calc_cpu_role() will compute a role with 4 or 5 levels of paging, but shadow_mmu_init_context() will wire up the MMU to use the paging32 template, which maxes out its levels at 2. Note, the "real badness" is effectively the same as what happened with the nVMX bug fixed by commit 112e66017bff ("KVM: nVMX: add missing consistency checks for CR0 and CR4"). Unfortunately, the sanity check added by commit 72e2fb24a0b0 ("KVM: x86/mmu: Bug the VM if a vCPU ends up in long mode without PAE enabled") doesn't work for this case, since L2 state is active at the time of the page fault, but it's L1 that has the bad state. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260902232028.2767071-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 7d787fb34e825218702496fb0d5892529bea9366 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 a9a7f2d8bd7d820a7dfe778ec3435ca97661e5b7 Author: Sean Christopherson Date: Mon Sep 21 17:13:29 2026 -0700 KVM: Only bind memslot to guest_memfd instance for CREATE operations commit 513333a5546017da2a4a6173bfb70372f83733b3 upstream. For additional defense-in-depth, and to avoid having to handle impossible unwind scenarios when binding to a memslot fails, bind a memslot to a gmem instance only for CREATE operations, i.e. don't attempt to establish a binding for MOVE and FLAGS_ONLY operations. And when FLAGS_ONLY operations are eventually supported (this is currently all dead code), creating a new binding would be incorrect; KVM instead needs to do a 1:1 replacement of the existing binding, i.e. FLAGS_ONLY will need its own dedicated handling. Update the relevant TODO to make a better guess as to what needs to be done to support toggling dirty logging for guest_memfd memslots. Because it's dead code, no functional change intended. Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260922001332.1121266-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 92f77936554b01ed5bff3175e511111b5aa57976 Author: Peter Ujfalusi Date: Thu Oct 8 11:54:11 2026 +0300 ALSA: x86: hdmi: fix chmap array missing terminator entry commit f5e1a9a3fddab8421416b68bb132ae9626d07156 upstream. had_build_channel_allocation_map() allocates a single struct snd_pcm_chmap_elem via kzalloc() and stores it as intelhaddata->chmap->chmap. struct snd_pcm_chmap.chmap is expected to be a zero-terminated array (see snd_pcm_std_chmaps[]), but had_register_chmap_ctls() never overrides the TLV callback installed by snd_pcm_add_chmap_ctls(), so the generic pcm_chmap_ctl_tlv() from ALSA core is left in place. pcm_chmap_ctl_tlv() is reachable by any local user via SNDRV_CTL_IOCTL_TLV_READ on the "Playback Channel Map" control and walks the array with "for (map = info->chmap; map->channels; map++)". Since the driver's single element is never terminated, this walks past the allocation. The same pointer is also freed on hot-unplug and rebuilt on hot-plug under intelhaddata->mutex, while the TLV callback runs under card->controls_rwsem without that mutex, so the walk can also race a concurrent free of the array. Fix this by allocating a second, zeroed element so the array is properly terminated, and by dropping the inherited TLV callback entirely at registration time, since the driver never implements one of its own. Fixes: 5dab11d89777 ("ALSA: x86: hdmi: Add audio support for BYT and CHT") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20261008085411.13742-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c7dec767830a54b2c69a90e86b60720e430d516 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 0d2f62032027a8dd21df5da68bb8fc3d4fc2987a 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 18edbcab25d9b5c205c38e6c6ad9ca5e4436147e 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 3b3127f5a85fd0b3792064a5e435e70a7025ea84 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 6b576c59a8ce1d69108d1b844cecb9e4a0349af4 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 3f37c5ff0b93b6dcced633eb62a7091281527830 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 ec98e8bdbde85e2dd2d43570e25b52bdfac1735b 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 5ed5c9b33f37d1672727e498cee082b3611e367f 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 9d161fa805f49dd21d131065485065067bb96c8a 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 86f3078ed2bd6645f5d44fa41917453b774808c1 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 0d58852577741727c767ba69705175f4f7a16f8d 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 7ad8c8ee23c26a5263b8ddfc216d2937727d6d03 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 42923e0fc817a7e78d1a5e7cb82966d27919e332 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 1c582f719010b5ff9f678cf8307594be0570831b 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 9abeb05bce3fbe00e8d10b8dcc775b81cd61d6d9 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 bd4beccf0899864ec4cb725d08fba87b627e8e1a Author: Ameer Hamza Date: Sat Aug 15 03:19:53 2026 +0500 sunrpc: honor the netlink unix_gid NEGATIVE flag commit 7bc856dfaa104bf2bc26abd40b53dbf857c2d5bc upstream. The unix_gid netlink upcall protocol has an explicit SUNRPC_A_UNIX_GID_NEGATIVE attribute for failed group lookups, and mountd sends it, but sunrpc_nl_parse_one_unix_gid() only allocates an empty group list for a flagged reply without propagating the flag into the entry, so it installs a valid positive entry with zero groups. Such an entry strips the uid of all supplementary groups until it is refreshed or expires: the same defect the previous patch fixes on the classic channel, on a transport that can say "lookup failed" explicitly. Set CACHE_NEGATIVE for flagged replies, as the netlink ip_map path already does for its negative flag. An empty GIDS list without the flag remains a positive entry. Fixes: 0850e8603cd7 ("sunrpc: add netlink upcall for the auth.unix.gid cache") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Ameer Hamza Link: https://patch.msgid.link/20260814221953.108837-3-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 147a30e2e482c9764acf529ba22916cf1212d7ed 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 99eb91d68e73a08bfc784eff6f5c02ecb6ea58ba 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 70614e41d379e5b9b1893ac65b49ae4cea6c36eb 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 35fc1e20d2b002f43073707ee2f77811706b64ea 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 49f6570e1a8989268cfb71448e3d301c5c850c2d 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 d67360912543356aca6fc39e4bb286e08d1c77af 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 cca29c873bb8ff8a66025a3adc830755b7636723 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 df6a0f9256e271c5ae055238d1145cffd14e3193 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 cf44075507def39c9d3cf298ffed4006b4d05b18 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 479651d608f3734fd0b8ca6243e247e9f09d0414 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 ed98b0c57e5e84290c5b35428144ab26778905f3 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 c0dacde381e1311bba8074e660d41ecc57c3bd2b 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 a52df9d2bde0111b64162fe8db5dfaabbd6c5549 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 42c6f630b87cf85cbd72267e1c062c2edfcccbfd 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 a596d1979fcb4e5011d3d48ac4d927f81c9c9cab 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 35c0d6b9d14c1f065dfa8338063fbe3b396b4b3c 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 24a2a428cb2a95cabdeccd98912b41bc13907065 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 a307eaf5f55dec005e2cefcc05d691cfd5c4ab95 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 542bce50f1771265d8a6ee71bd253bb5182b20cf 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 a8bb6c0085ab543d4879b3824306d0fbc7dda229 Author: Jeff Layton Date: Fri Sep 4 12:11:37 2026 -0400 nfsd: don't offer flexfiles layouts when NFSv3 isn't being served commit 5d28b2c920d9d9d3c45b41769342ad785eb372a7 upstream. The flexfiles layout driver hands out a deviceinfo that names this server as an NFSv3 DS (flexfilelayout.c hardcodes da->version = 3). With v3 disabled, the client can't talk to the DS: it loops on v3 NULL calls that the server answers with PROG_MISMATCH, and I/O hangs in D state. Skip LAYOUT_FLEX_FILES in nfsd4_setup_layout_type() unless v3 is enabled. Reported-by: Benji Wiebe Closes: https://lore.kernel.org/linux-nfs/c734eeb8-8486-4491-bb4d-b9656cbaffbe@app.fastmail.com/ Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260904-pnfs-ff-v1-1-5f502cf25401@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4e3c12151f13c4e51eb381f9377835fb94b9f56a 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 226c11eb20042ce4251f50870ce61f86581f8152 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 cd58899f22a9a232c741f890728fb5d9a2b007fe 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 d568594503a09ed2761fada2117e4fbaa31972e0 Author: Chuck Lever Date: Sun Aug 2 13:04:35 2026 -0400 NFSD: Destroy a recalled delegation the client does not hold commit bbfa823f624d41e85ebca929ac77dc2182cadfed upstream. A client that answers CB_RECALL with NFS4ERR_BADHANDLE or NFS4ERR_BAD_STATEID has no record of the delegation, so the FREE_STATEID that clears it from cl_revoked never arrives. Every later SEQUENCE reply carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client loops issuing TEST_STATEID. Destroy such a delegation when it is reaped rather than revoking it onto cl_revoked. RFC 8881 Section 20.2.4 completes the recall at the reply when its status is neither NFS4_OK nor NFS4ERR_DELAY, so a rejected recall leaves nothing to revoke. An administrative revoke keeps that path, since NFS4ERR_ADMIN_REVOKED reports it. A destroyed stateid returns NFS4ERR_BAD_STATEID instead of NFS4ERR_DELEG_REVOKED. A client that rejects the recall but still holds the delegation gets no notice that its state was revoked. CB_RECALL can outrun the reply that granted the delegation, so honor a rejection only once the client has seen that grant. Per RFC 8881 Section 2.10.6.3, retirement of the slot that carried the grant is that proof; retry until then, and revoke when the retries lapse. Fixes: 3bd64a5ba171 ("nfsd4: implement SEQ4_STATUS_RECALLABLE_STATE_REVOKED") Cc: stable@vger.kernel.org # 6.14.x Link: https://patch.msgid.link/20260802-nfsd-deleg-destroy-badhandle-v1-8-323aa7196055@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fea77ec4a37614cbbe4fb26c621227182439f487 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 99ab5346b69834587b4ae59d1addea5960b50c8b 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 340fd5acb07f0299e71afc54a4a4b32e129177c4 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 f29fa7b0e4d777073ffd3aedc88233b3c68a9cca 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 e0bd99a6afb93d800f5c9475c65e7e07bc03cf8e 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 ca85441a75b526228923e2959bd576403c4bba85 Author: Mike Snitzer Date: Mon Sep 28 11:54:26 2026 -0400 NFS/localio: detect a short read or write before the iterator has moved commit db3ca539c1142d2c5380c5dbd3154ab7bb1c7d77 upstream. nfs_local_call_read() and nfs_local_call_write() issue a misaligned DIO as up to three segments and must stop at the first short one, or the next segment lands at the wrong file offset. They test for that by comparing the bytes transferred against iov_iter_count() of the segment, read after read_iter() or write_iter() has advanced the iterator, when the count is the residual rather than the request: before the call: count == expected after the call: count == expected - status The test is therefore status < expected - status, and it fires only when less than half of the segment was transferred. A short I/O that covers between 50% and 99% of a segment slips through: the loop moves on with ki_pos advanced by the short amount, the next segment is issued at the wrong offset, and the header's byte count is over-reported to the caller. A write that slips through also never sets NFS_CONTEXT_WRITE_SYNC, which is what makes the writes that follow a short one synchronous. Take the segment's count before issuing it and compare against that. This is the same defect that commit 250ec14932d5 ("nfsd: fix partial-write detection in nfsd_direct_write") fixed in NFSD's version of this loop. Fixes: c817248fc831 ("nfs/localio: add proper O_DIRECT support for READ and WRITE") Fixes: d0497dd27452 ("nfs/localio: backfill missing partial read support for misaligned DIO") 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 430e46dabbd93abef27eeebd77dae1f528e638f5 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 2a31674c3e72d7c81b3cc8ed9ad5d6524056a2c9 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 2e58e4f9a8dcab90d384d5888ffec38c8718ea05 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 71f6e7a9ab81f3a42c01989af274800aa92919e0 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 fe52fa5319458d3d5f04046422b4cf954024a26f 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 e3668ce48f8963b4e1ab9c2c0a080f9d3fb53ea4 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 db9ff4e24e34d900bd2156c50e133227687562fc 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 f9ef68e056966c0c9d6e8e69f74f0e95b8b79504 Author: Trond Myklebust Date: Fri Sep 11 11:00:02 2026 -0400 NFSv4: Fix a regression in the handling of CB_RECALL_ANY commit 25dde935988bc0cc2991cedbea90a2ce65066d54 upstream. When the flag NFS_DELEGATION_RETURN was replaced by the server->delegations_return list, the test in nfs_mark_return_if_closed_delegation() was replaced by one that stops all further marking of delegations for return when closed as soon as the server->delegations_return list is non-empty, breaking CB_RECALL_ANY behaviour. While the intention at the time was probably to check if delegation->entry was non-empty in order to emulate the effect of the NFS_DELEGATION_RETURN test, that is no longer an option, since delegation->entry is also used for the LRU list. By just removing the offending check altogether, the patch can end up moving delegations from the server->delegations_delayed list prematurely, triggering an early retry. However that should be mostly harmless behaviour. Fixes: 0ebe655bd033 ("NFS: add a separate delegation return list") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit fde95d71af2c3a3efac0cd4a09f7082e3d1d7805 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 92371c6d8b0ea9e7c336ad902bcc076f2caa2aa8 Author: Benjamin Coddington Date: Tue Sep 15 08:22:05 2026 -0400 NFSv4/pnfs: bound the CB_NOTIFY_DEVICEID array count before allocating commit 32f0967ea296d447925465c98e7eec71d4e2f755 upstream. decode_devicenotify_args() hands the server's notification count straight to kmalloc_objs() as the array length, without checking it against the message that carried it. Bound it the way nfs4xdr.c bounds an attribute length, against xdr_stream_remaining(). Fixes: 1be5683b03a7 ("pnfs: CB_NOTIFY_DEVICEID") 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 1c46038a0117c4495783edc8a7532dbda7828e49 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 5131cc775413ad6d360090f3be0ab8b7699136e0 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 7873ce517fc139d8dd7b5d158663bea23e653e6b 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 3e7b577a8904d514fcdc351d3c1d4e8de377c9e0 Author: Shakeel Butt Date: Sat Sep 5 12:16:12 2026 -0700 kernfs: don't lose IN_DELETE_SELF when decoding a file handle commit dc1a0cc95737344b1a6aa42075e573e9625c6b9a upstream. __kernfs_remove() clears i_nlink on a node's inodes and finds them with ilookup(). A decode that has pinned the node but not yet hashed its inode is invisible to that pass: CPU0 CPU1 open_by_handle_at() kernfs_find_and_get_node_by_id() pins the node, still active rmdir() marks the subtree removing ilookup() finds no inode kernfs_get_inode() hashes an inode with i_nlink 1 Nothing fixes it later: kernfs_refresh_inode() never touches i_nlink for a file and skips it for a directory being removed. The inode keeps the 1 it was born with, and dentry_unlink_inode() sends IN_DELETE_SELF only at 0, so a watcher never learns the node went away. The other callers of kernfs_get_inode() are safe: those in fs/kernfs hold kernfs_rwsem, and cgroup_may_write() is covered by cgroup_mutex, which cgroup_destroy_locked() holds across kernfs_remove(). __kernfs_fh_to_dentry() has held nothing since exportfs support was added. Take kernfs_rwsem for reading, as ->get_parent already does, and cover the lookup as well as kernfs_get_inode(). __kernfs_remove() deactivates the whole subtree under the write lock, so under the read lock either the lookup refuses the node, or the inode is hashed before the ilookup() pass runs. The same holds for ->fh_to_parent, since a node cannot be active while an ancestor is being removed. Reproduced with a 300ms delay between the lookup and kernfs_get_inode(), decoding a handle for a file in a cgroup directory while another task rmdir()s it: st_nlink is 1 without this patch and 0 with it. ->get_parent still has a window of its own. It takes the same lock but has no active check, so reconnect_path() can build an inode for an ancestor that is already gone. That needs the active test rather than a lock, and changes what ->get_parent returns, so it is left to the series that reworks these paths. Fixes: eea5d2bb34ba ("kernfs: Send IN_DELETE_SELF and IN_IGNORED") Cc: stable@vger.kernel.org Acked-by: Tejun Heo Signed-off-by: Shakeel Butt Link: https://patch.msgid.link/20260905191613.3143937-4-shakeel.butt@linux.dev Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c7e3ac100b0be35063366c3b6452d81f25b11c90 Author: Daejun Park Date: Tue Oct 6 09:34:25 2026 +0900 xfs: map pNFS layouts to the end of the extent again commit e3c682dd11303a95ff82ea63b9172dce788578d4 upstream. Since commit 36ca6f11424a ("xfs: fix overlapping extents returned for pNFS LAYOUTGET"), xfs_fs_map_blocks() maps only the range that nfsd asks for. For O_DIRECT, the Linux block layout client asks for the range of the I/O at hand, so it now needs a LAYOUTGET for every O_DIRECT read or write to a part of a file it has no layout for yet, where the first LAYOUTGET used to return the whole extent. Each LAYOUTGET is a round trip, and xfs_fs_map_blocks() takes the iolock exclusively and writes back and invalidates the page cache of the file for it. On three QEMU VMs (an NVMe/TCP target, the server with nfsd and XFS, and a client) running the same kernel without KASAN or lock debugging, a client doing O_DIRECT I/O over the block layout of NFSv4.2 for 30 seconds to a 1 GiB file of one written extent, in order unless noted and with an fsync every 16 MiB written, gets this many I/Os done (and LAYOUTGETs counted at the server), one run each: unpatched ENTIRE, no trim this patch 4 KiB reads 41207 (41207) 334931 (1) 343749 (1) 4 KiB random 36670 (34148) 259527 (1) 263829 (15) 4 KiB overwrite 38556 (38556) 325533 (1) 307105 (1) 64 KiB reads 70241 (16384) 80829 (1) 91196 (1) 1 MiB reads 6857 (1024) 6759 (1) 6706 (1) "ENTIRE, no trim" is a test kernel that maps with XFS_BMAPI_ENTIRE and does not trim. The random reads need a LAYOUTGET each time they go before the lowest offset read so far, as the part of the extent before the offset asked for is not mapped. 1 MiB overwrites and writes to an unwritten extent also go from 1024 LAYOUTGETs to 1, with no clear change in I/Os done. Appending to a new file needs a LAYOUTGET per 1 MiB appended either way, as XFS allocates only the range asked for on a filesystem without a stripe unit or an extent size hint. The overlap fixed by that commit comes from XFS_BMAPI_ENTIRE reaching back. nfsd4_block_proc_layoutget() calls ->map_blocks once per extent of a LAYOUTGET, each time for the range left after the previous extent. An allocation in one call can merge the extent that the next call starts in with the extents before it, and the whole extent then starts before the offset of that call and overlaps extents already in the layout. The Linux client rejects such a layout (verify_extent() returns -EIO), and the I/O that needed it fails. In the thread of that commit, Christoph Hellwig asked for XFS_BMAPI_ENTIRE to be dropped to stop the overlap, Darrick J. Wong agreed, and it was said that the flag makes no difference on the first call, which is for the whole range the client asked for. The difference is past that range: the Linux client asks for the range of each O_DIRECT I/O and uses the rest of a longer layout for the I/Os that follow, which RFC 8881 allows (Table 22 sets only a minimum length). A client could ask for more for a read layout, but for a write layout xfs_fs_map_blocks() allocates any hole in the range asked for. Dave Chinner suggested keeping the flag for the first call and trimming the mappings of the calls that follow. ->map_blocks cannot tell the first call from the others, and Christoph preferred to keep such a choice out of that interface, so trim every mapping to start at the offset asked for instead. No mapping can then overlap the one before it, since each call starts where the previous extent ended. Unlike Dave's suggestion, the first mapping loses the part of the extent before the offset, and the last mapping keeps the part past the end of the range, which the loop in nfsd4_block_proc_layoutget() already handles. Trimming in that loop instead would keep his suggestion exactly, but would change nfsd as well, while trimming in XFS keeps every mapping it returns free of overlap whatever the caller does. Unlike before that commit, don't let the mapping reach past EOF beyond the range asked for. On an inode without XFS_DIFLAG_PREALLOC or XFS_DIFLAG_APPEND, xfs_free_eofblocks() can free blocks past EOF, such as speculative preallocation, without breaking the layout, so a client that did not ask for them should not get them. What a client gets for a range past EOF that it asks for does not change. The aio group, the fsx tests and generic/013 (fsstress) of fstests over the block layout, and the fsx tests and generic/013 over the SCSI layout, give the same results with and without this patch. generic/091 and 263 fail with the ENTIRE, no trim kernel and pass with this patch, and so does the pynfs test BLOCK5, which checks a write layout over a hole between two allocated blocks against three rules of RFC 5663 section 2.3.1. Fixes: 36ca6f11424a ("xfs: fix overlapping extents returned for pNFS LAYOUTGET") Cc: stable@vger.kernel.org Suggested-by: Dave Chinner Link: https://lore.kernel.org/r/ageSguSyf2kBY33a@dread Link: https://lore.kernel.org/r/agwDhixPAAA0-cTa@infradead.org Link: https://lore.kernel.org/r/agqfBPRWXQDR2ImG@infradead.org Signed-off-by: Daejun Park Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1ba1937de005e261a8858f45bfef5da7458df94c Author: Abdifatah Suruur Date: Thu Oct 22 06:53:29 2026 +0300 smb: client: validate the data area in SMB2_read() commit 2ec9cdf469dd32bcf33073aeb30c08e9356e0ca1 upstream. SMB2_read() copies le32_to_cpu(rsp->DataLength) bytes from (char *)rsp + rsp->DataOffset without checking that the range lies within the response actually received. A READ response with DataOffset == 0 makes smb2_get_data_area_len() zero the data length, so smb2_check_message() accepts a frame as short as the fixed response, while SMB2_read() still uses the server-supplied DataLength, capped only by CIFS_MAX_MSGSIZE and the caller's length. A malicious server can answer the synchronous read used by the mfsymlinks (or SFU) symlink parser with an 81-byte READ response carrying DataOffset 0 and DataLength 1067, making the client copy 1067 bytes from a 448-byte receive object (KASAN slab-out-of-bounds; up to 16 KiB in the general case). Clamp a zero (or header-overlapping) DataOffset to read_rsp_size, as handle_read_data() does for the asynchronous path, and reject the response unless DataOffset + DataLength fits within rsp_iov.iov_len. The SMB1 helper was fixed the same way in 5be5bdda5863. Fixes: d8e050398d23 ("CIFS: Add readpage support for SMB2") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8eec99e61b79bb5f698754dda8e8a1ff7e4ed7ff Author: Ratnaker Gautam Date: Sat Oct 24 12:36:14 2026 +0000 smb: client: validate SMB1 EA list bounds before parsing commit ddc7a7e1eeb116ccaf010a6f1fb6ab927f3f888d upstream. CIFSSMBQAllEAs() checks the server-provided EA list length by adding it to the response pointer. On 32-bit systems, a positive length can wrap the pointer and pass the comparison. The parser then walks outside the received response while reading the next FEA header. A response with a list length of 0x40000000 reproduces this as a native i386 page fault and kernel panic from listxattr() against an SMB1 server. Check that the EA list starts within the SMB byte area before reading its header. Keep its length unsigned and compare it with the bytes left in the response without pointer addition. SMB1 is not negotiated by default and requires an explicit vers=1.0 mount. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ratnaker Gautam Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit d55c0c19b0d1f5c0101f9aa3b60534b6d6e11052 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 e505c266c31581b8bec159c65ab1aef0c714bd40 Author: Paulo Alcantara Date: Tue Oct 13 10:33:41 2026 -0300 smb: client: require stable pages for SMB compression commit 8667061cf99394526dd9c0ea2662e6bbc7ae7848 upstream. Like signing, SMB compression builds the write payload from the pagecache folios: should_compress() lets a write request through and smb_compress() compresses those folios on the way to the socket. If a buffered write mutates a folio while a write subrequest is still in flight, the compressed bytes no longer correspond to a consistent view of the data, and the server silently stores corrupted contents - worse than the signed case, which at least fails loudly with STATUS_ACCESS_DENIED. Mark the mapping for stable writes when a write may be compressed, i.e. the same condition should_compress() tests (compression negotiated and the share allows compressed data), so netfs_perform_write() waits for writeback to complete before modifying an in-flight folio. Fixes: f046d71e84e1 ("smb: client: insert compression check/call on write requests") Suggested-by: David Howells Signed-off-by: Paulo Alcantara Reviewed-by: 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 df63e01933886153e40706483b9635b2456ad91f Author: Abdifatah Suruur Date: Thu Oct 22 06:53:14 2026 +0300 smb: client: reject short SESSION_SETUP responses commit 4d8930afa3446041358a7db33e7b23a0bb9459b5 upstream. smb2_check_message() accepts frames shorter than struct smb2_pdu when the SMB2 status is non-zero, before the minimum-PDU check added by b4694f269e66d. A 64-byte STATUS_MORE_PROCESSING_REQUIRED SESSION_SETUP response is therefore accepted even though it cannot contain the SecurityBufferOffset and SecurityBufferLength fields. The parser then reads those fields from stale bytes left in the reused receive buffer by an earlier frame. With a long stale SecurityBufferLength, decode_ntlmssp_challenge() copies up to about 64 KB from beyond the receive object and sends the data back to the server in the NTLMv2 AUTHENTICATE target info. Reject short MPR SESSION_SETUP responses before the short-error path, and validate SecurityBufferOffset + SecurityBufferLength against the received response length before decoding the challenge. The ordering bypass is not new: the short-error early return predates b4694f269e66d, and the unvalidated SecurityBufferLength read predates the 2016 raw NTLMSSP split in 166cea4dc3a4, so all supported stable trees are affected. Reproduced on 6.6.87.2; the path is unchanged on mainline. Fixes: 5478f9ba9a34 ("CIFS: Add session setup/logoff capability for SMB2") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 1374082f0897c95610190dfacce463904ec11ea2 Author: Diego Oliva Date: Tue Sep 29 10:16:35 2026 +0100 smb: client: reject short or out-of-range FIND response parameters commit 531aa4239b0d80d7146b102b98f7aa7da989ccdd upstream. CIFSFindFirst() and CIFSFindNext() read the SearchHandle, SearchCount, EndofSearch and LastNameOffset of a TRANS2_FIND_FIRST2 or TRANS2_FIND_NEXT2 response at ParameterOffset. validate_t2() bounds the offset at 1024 and ParameterCount below 512, and nothing compares them with the number of bytes SendReceive() copied into the buffer or with the size of the response parameters. smb_init() places the request and the response in the same cifs_request allocation and cifs_buf_get() clears only the start of it, so a short response with a ParameterOffset past its end has the search handle, the entry count, the end-of-search flag and the last-entry offset read out of the request that was just sent, or out of whatever the allocation held before, and a ParameterCount smaller than the parameters has them read past the end of the parameter block. The reads stay inside the allocation, but what they return is not part of the response, and CIFSFindFirst() then hands back a search handle the server never sent. That handle is sent back to the server in the next FIND_NEXT2 or FIND_CLOSE2, so two bytes of the buffer leak at an offset the server picks. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Reject a response whose parameter area is smaller than the response parameters or extends past the received length, returning smb_EIO2() with a new smb_eio_traces value for each of the two responses, like the other response checks this file gained since v6.19. Backports to trees before v6.19 need smb_EIO2() replaced with -EINVAL and the trace.h hunk dropped. A conforming server is not affected. The parameter block of a transaction response is part of the SMB, so ParameterOffset + ParameterCount cannot exceed the smbCalcSize() bytes that SendReceive() copies, and the response parameters are 10 bytes for FIND_FIRST2 and 8 bytes for FIND_NEXT2, which is what T2_FFIRST_RSP_PARMS and T2_FNEXT_RSP_PARMS hold. This patch depends on "smb: client: reject FIND data areas that run past the received response", whose declarations it extends. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # 6.19.x 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 4dfc78e53f419834d99e626fc27083799e2ea4c1 Author: Diego Oliva Date: Tue Sep 29 10:16:34 2026 +0100 smb: client: reject FIND data areas that run past the received response commit 29bd6773187cb5c1bbbdf90d677c6add7d58af26 upstream. CIFSFindFirst() and CIFSFindNext() take the directory entries of a TRANS2_FIND_FIRST2 or TRANS2_FIND_NEXT2 response from DataOffset for DataCount bytes. validate_t2() bounds DataOffset at 1024 and ParameterCount + DataCount by the byte count, and nothing compares DataOffset + DataCount with the number of bytes SendReceive() copied into the buffer. smb_init() places the request and the response in the same cifs_request allocation and cifs_buf_get() clears only the start of it, so a short response whose data area extends past its end has srch_entries_start point at bytes of the request that was just sent, or at whatever the allocation held before, and those bytes are parsed as directory entries. cifs_readdir() and find_cifs_entry() walk the entries with nxt_dir_entry(), which checks every entry but the first of a response against the end of the SMB; cifs_query_path_info() and cifs_backup_query_path_info() read the first entry with no check at all. Those reads stay inside the allocation, but what they return is not part of the response. The last entry, which LastNameOffset locates relative to the data area, is bounded against the received response by an earlier patch of this series, as is every entry that cifs_fill_dirent() parses; the walk itself and the two query functions are not. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Reject a response whose data area extends past the received length, with the -EINVAL that validate_t2() returns for the other malformed transaction responses. cifs_query_path_info() and cifs_backup_query_path_info() still read a whole entry from a data area that may be smaller than one; that is not changed here. A conforming server is not affected. The data block of a transaction response is part of the SMB, so DataOffset + DataCount cannot exceed the smbCalcSize() bytes that SendReceive() copies; coalesce_t2() appends each secondary response to the data area and adds its length to both DataCount and the byte count, which keeps that relation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") 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 b3f511aa7f45ff9ab1abc38d133e05b919563aaf Author: Paulo Alcantara Date: Thu Oct 15 15:53:32 2026 -0300 smb: client: reclaim credits for decrypted reads with no matching mid commit 78f73985846465a25a7bd1d89904053661f3ca92 upstream. When a decrypted SMB2 READ response carries a MessageId that matches no outstanding request, both the inline receive_encrypted_read() and the offloaded smb2_decrypt_offload() paths drop the frame without accounting the credits the server granted in it. The plaintext unknown-frame path in cifs_demultiplex_thread() already reclaims them with smb2_add_credits_from_hdr(), so encrypted reads leak credits that the plaintext path would not. This also happens for legitimate frames - e.g. a reply that arrives after the client has timed out and dropped the mid - so over a long-lived connection the client's credit count drifts down and can eventually starve it of the ability to issue requests. The frame is AEAD-authenticated, so the granted credits in the decrypted header come from the real server and are safe to apply. Reclaim the credits from the decrypted header before dropping the frame, and export smb2_add_credits_from_hdr() so the SMB2 receive paths can use it. Fixes: c42a6abe3012 ("CIFS: Add capability to decrypt big read responses") Fixes: 35cf94a39728 ("smb3: allow parallelizing decryption of reads") Signed-off-by: Paulo Alcantara Reviewed-by: 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 be1bcc9147facd85dc2ebe48688afde6d5590f10 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 9615d78d537db9e7599f55b8ad1f061e29ed1f11 Author: Diego Oliva Date: Tue Sep 29 10:16:33 2026 +0100 smb: client: fix OOB read in the SMB_FIND_FILE_UNIX name scan commit fa0c2f082946917c3f07d2475c8ce73a8c96d0e2 upstream. cifs_fill_dirent_unix() finds the length of an SMB_FIND_FILE_UNIX entry name by scanning for its terminating NUL, over up to PATH_MAX + 1 UTF-16 units in cifs_unicode_bytelen() or PATH_MAX bytes in strnlen(). Neither scan knows where the response ends. cifs_fill_dirent() only requires the fixed part of the entry to fit, so the name can start exactly at the end of the received data, and a name that holds no terminator is then scanned for 8194 bytes, or 4096 bytes without unicode, past the end of the received data. SendReceive() copies at most 16468 bytes into the 16588-byte cifs_request allocation, so for a response of that length up to 8074 of the bytes scanned lie past the end of the allocation. Before the preceding patches bounded where the entry starts, the entry itself could start up to 820 bytes past the end of the allocation at the default CIFSMaxBufSize, and its name 928 bytes past it, so all 8194 scanned bytes would lie outside. cifs_fill_dirent() rejects the name afterwards because it extends past the end of the response, so nothing of what was read is used, but the out-of-bounds read itself remains. SMB_FIND_FILE_UNIX is only used with SMB1 servers that offer the Unix extensions; SMB1 is not negotiated by default and requires an explicit vers=1.0 mount. Before the preceding patches, an entry placed past the buffer left the scan out of bounds from its first read. They bound where the entry starts, but nothing bounds the scan, so a name that holds no terminator still runs off the end of the allocation. Reproduced on the unpatched tree with KASAN enabled, for an entry that starts inside the response, which is the case the preceding patches leave open: ================================================================== BUG: KASAN: slab-out-of-bounds in cifs_save_resume_key.isra.0+0x75c/0x7f0 Read of size 2 at addr ffff88807ee640cc by task ls/84 CPU: 0 UID: 0 PID: 84 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+0x75c/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 84 on cpu 1 at 15.751078s: cifs_buf_get+0x36/0x90 smb_init+0x4f/0x110 CIFSFindNext+0xf7/0x14c0 cifs_readdir+0xf51/0x29c0 The buggy address belongs to the object at ffff88807ee60000 which belongs to the cache cifs_request of size 16588 The buggy address is located 0 bytes to the right of allocated 16588-byte region [ffff88807ee60000, ffff88807ee640cc) ================================================================== The two bytes read there are one UTF-16 unit of the scan, at the first byte past the end of the object. The scan carries on from there, reported again 2, 4 and 6 bytes to the right. Pass the number of bytes that follow the fixed part of the entry to cifs_fill_dirent_unix() and stop both scans there. A scan that reaches the end of the response without finding a terminator now fails: it returns a name that ends exactly at the end of the response and would otherwise pass the bound, so cifs_fill_dirent() requires the position of the terminator of an SMB_FIND_FILE_UNIX name to lie inside the response as well. Accepting such a name truncated at the end of the response would turn a malformed entry into a directory entry, or a resume name, that no server sent. A name longer than the PATH_MAX cap of the scans is still truncated there, as before, when the response extends past the cap. The message cifs_unicode_bytelen() logs when it finds no terminator now covers both limits. This patch depends on "smb: client: fix OOB read of the resume name sent in TRANS2_FIND_NEXT2", which adds the end argument of cifs_fill_dirent() and the length it derives from it; the backport note in that patch applies to this one as well. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") 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 7141cde58f9dc15cf0869529ba2cb09fb0f082e5 Author: Diego Oliva Date: Tue Sep 29 10:16:32 2026 +0100 smb: client: fix OOB read of the resume name sent in TRANS2_FIND_NEXT2 commit f8171804a39ee89a11cd462f67862899de9c6b10 upstream. cifs_fill_dirent() reads the fixed part of a directory entry and the name length it holds, or for SMB_FIND_FILE_UNIX scans the name for its terminating NUL, without knowing where the response ends. cifs_save_resume_key() calls it for the entry at the LastNameOffset the server chose, after every FindNext and after the FindFirst of a search rewind, and records the name it returns as the resume name of the search without bounding it; the next CIFSFindNext() copies up to PATH_MAX - 1 bytes from that name into its request and sends them to the server. cifs_filldir() bounds the name against the end of the response since commit f8cf09a53a0d ("smb: client: bound dirent name against end of SMB response in cifs_filldir"), but only after cifs_fill_dirent() has read the entry, and nxt_dir_entry() checks the entries it walks only against sizeof(FILE_DIRECTORY_INFO), for every level but SMB_FIND_FILE_INFO_STANDARD, and never sees the first entry of a response. Bounding where last_entry starts, as the preceding patch does, does not bound the read. A last entry that starts within the final bytes of the response still has its fixed part read past the end of the received data, and the name length it declares, a __le32 for every level but SMB_FIND_FILE_INFO_STANDARD and SMB_FIND_FILE_UNIX, is recorded without being checked against anything. CIFSFindNext() rejects only a length of PATH_MAX or more, then copies the name, up to 4095 bytes, into its request and sends it, and as the report below shows that copy can run past the end of the cifs_request allocation that holds the response. For SMB_FIND_FILE_UNIX the name is in addition scanned for its terminating NUL over up to PATH_MAX + 1 UTF-16 units, or PATH_MAX bytes, before any check. The FindNext that carries the name is only sent by the SMB1 dialect, which is not negotiated by default; reaching it requires an explicit vers=1.0 mount. With KASAN enabled, a response whose last entry declares a name longer than the bytes that follow it gives: ================================================================== BUG: KASAN: slab-out-of-bounds in CIFSFindNext+0x8ca/0x14c0 Read of size 4080 at addr ffff88807c823f98 by task ls/83 CPU: 0 UID: 0 PID: 83 Comm: ls Not tainted 7.3.0-rc4-00457-gf14572c203d5 #69 PREEMPT(lazy) 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 The buggy address belongs to the object at ffff88807c820000 which belongs to the cache cifs_request of size 16588 The buggy address is located 16280 bytes inside of allocated 16588-byte region [ffff88807c820000, ffff88807c8240cc) ================================================================== The read is the memcpy() that copies the recorded name into the next request, so those bytes go to the server. Pass the end of the response to cifs_fill_dirent() and have it reject an entry whose fixed part does not fit or whose name extends past the end, before either is used, so that both callers are covered; cifs_save_resume_key() computes the end the same way cifs_readdir() does. The name bound compares the bytes left between the name and the end with the name length rather than adding the length to the name pointer, since the length is a 32-bit value taken from the entry and the sum could wrap on 32-bit systems. cifs_fill_dirent() is also used on the SMB2 readdir path; there smb2_parse_query_directory() has already checked every entry against the end of the response, so a valid SMB2 response is not rejected by the new checks. The check cifs_filldir() applies after the parse is left in place. The NUL scan for SMB_FIND_FILE_UNIX names is capped by a separate patch. An entry and its name lie inside the data area of the response, so a server that points LastNameOffset at the entry is not affected. One that points it at the file name, as MS-CIFS 2.2.6.2.2 describes, has its last entry rejected here; the listing is unaffected, because cifs_readdir() records the resume name from an entry it emitted, and before this series such a response could instead end the listing early, since a name length read from the wrong place is usually PATH_MAX or more, which CIFSFindNext() rejects with -EINVAL. On trees before v6.19 the type for the level 0x105 fixed part is spelled SEARCH_ID_FULL_DIR_INFO; adjust when backporting. Fixes: 0752f1522a91 ("[CIFS] make sure we have the right resume info before calling CIFSFindNext") Cc: stable@vger.kernel.org # 6.1.x: f8cf09a53a0d: smb: client: bound dirent name against end of SMB response in cifs_filldir 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 31f6dbb29fe17fa9595c7e8b19fd92915b03a4ca 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 d26f7fbca42532c6c79efdceb4bd5198e1849314 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 ed62849db326dc166aa18496e40f27a44b2c7ad0 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 d5993c6146ad74a3dab2d9cbd09106d644d761cb Author: Ratnaker Gautam Date: Sun Oct 18 00:49:33 2026 +0200 smb: client: bound POSIX lock data area by response length commit 8fc9af68c57156ff64769f30e831553cd03b3000 upstream. CIFSSMBPosixLock() receives a TRANS2 response whose server-provided DataOffset and DataCount are not required by validate_t2() to describe an interval inside the response. A server can therefore make the client read a cifs_posix_lock beyond the response buffer and return those kernel bytes through F_GETLK. Use smbCalcSize() to obtain the full response length after any multipart TRANS2 reassembly, then reject data areas that extend past it before dereferencing them. Fixes: fc94cdb94462 ("[CIFS] Fix new POSIX Locking for setting lock_type correctly on unlock") Reported-by: Ratnaker Gautam 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 956968544ae647aa9a9534b58735f47922c85d44 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 Signed-off-by: Greg Kroah-Hartman commit c8a4c381fd68895bbb077df9b5322c8987b31cf5 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 2d20d6246e964cda8e099c30d1a4af47e7362155 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 a056fd70150db8458c2ee12caaa55ac7f70bc735 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 2d3b089c3a61aff755e84947b3c1e166040c67a3 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 8732d928601fddd039ff27a234b0582e8257b785 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 381cf36c19ef0438b877eb44a0dc982ff8f9804e 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 73b25554d38f0494433fa3a853b4f6d086ae81d5 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 7aa055259d47853ab8f8b1f23b4d690fb6b7ac68 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 1576a107cea54790f4c66f3020a2cd917a5ac8ab 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 ccf4fa942caa9273c074393d63c0abf68887b0fd 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 696ef990e101edb4489782301f5a39cfc496bb9d 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 4fe6d43988e98c25e592b560b63d055c01a0046d 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 2a2854c0b5b0682e9eee78bbc9af99e2d5aef2c4 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 10fead7a6e6ec8ed9e2f749012163b19afc5b445 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 0f58d3e918d200b9943d94284fb1d1f86c6725cb 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 c7313e113412e6759db36cb6d68d8c9b67b4ea0f 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 2242470913ebf60ed43fb6010641a88905982b75 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 666e40ff71d87a76d48f57b16bf2cab1fc1eaaca 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 471e4ae43cc5f931430f7701df45ce82c8afc05d 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 cfbb7114e80e6ebafaddcb907ef071821357b09f 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 7de12ac7521055890cc32c3149c6cacda64b0105 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 1faee6fac8cb907c6066f22af6669db0396faa3f 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 79e681c2d6fba2d30592cb423241a04c4e6599ca 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 fac22ce28f83d99a5f932d531cd529d42734cdb6 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 01ceebca4a21e662aca50818f5eac733aad5776d 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 bb29f3c85f00a12c35d8ceea97aaf31e4f7fd17b 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 e2768e65a5f2f942c831e3df3b06ad7332d423e6 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 229c4478a35663582893916250ebcdfc7b845b85 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 aa1cd2a9e5cedb6cfca6b842b0f84fddacb54f8a 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 07108a934ff02368927c53e64920623caed186c4 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 194dfc48a109d5a4411ba2e86c349d2a25e09109 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 2430132937e9ce5c6144db0de27439c31d189229 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 b5e9a2ca76372796cc352aa2d668a9ada363e021 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 afc2caf20937668936ea9d7cff2a9a37e2c9a1a4 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 0a5959bdd18b0a4785069a1a0baf41d2a120e3d8 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 c554aa3ff6340e2e0e065348b751c04c27191f4e 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 1481b4644cd640f0a603d97ced300a1fbd7d3a94 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 c5c34a0a5a80ecd8fea9fff960907b2924d18cd9 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 c88682ce55ec6522f121d3663b267cc32a808a26 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 05064c66ecfd82d3e555f803b62b046acfba19e8 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 ee636421740bc47e9d9e612ca7c9fa7dc5d17be1 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 e81a69d22ae06c1cbb211f3301641f332d74f83e 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 f38839a20269d6c9f0d9bfdba75567a6996355e6 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 e5ae64394e87f1100c48929bf411faa44f152308 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 78c2c67d04d6703d7544a0df96481fed6872564f 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 074552c68a767e42b270fcf261353525cbac3a67 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 aa186263329717e33f52615c243e57a669486d26 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 db77cc2d232a2a2a1c6364c9ef3131f0e8445315 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 86598d7f4b0ebbca905f650f3a0ba74de957a9ee 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 a66dacc7854740304f5e423dccfe82e9ee27de98 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 01f15dc261e1a881924801accd3c0e993ffc8c74 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 be6f30fb71876c1f842aedb72d924b22938cbbfc 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 a9ff42a6247352077816d79b8c61bb73acd847bd 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 7322bbd8660abc3bbad7431d88245c38c6d7c2e7 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 7dd8e5cced0b0b8570fa42f2b91bd1f9da23e147 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 a463a9fe659db4be1a336b2f3fb56daa3042a9ec 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 1e2d0332e619b75bb4d675400bf450db80b41431 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 d69bf84e316c496e3941b89b151a0172c65bc8f1 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 95c96e9695b8310f91edef38fd9a3e1ceb0f2c77 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 1ff7b0bdabce80428ecfdd7b691fe01ae4d81128 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 1a00d111c2532b40ce1638ec4c3921eed997db11 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 a32c9a7f0ddaac6cb6d4bfb89d26000ab5367a66 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 a6de88e800a37671ad4f5306b9c4557d502727cc 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 18c2ab78f10c65b63ddd4f4a2b340678197d843f 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 62136be2c4fb78522d3da1769fa2d2acb1d499db 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 65a65a295935045cb9084e4c96aadf4c369b20c4 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 5ff42c585d3437bc710f7704d62678b46212302d 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 45e05c784eee04fb78d8eb80d6635bd85482644a 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 d46e7803780d5f1a7bbb889f54ab400c30508f09 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 1e94102db79c3460410b55c21ce7165d5055a7ed 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 4fe8b75e3917113da8ae9d69a08ba9257e97b7c1 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 ef23fa3a55ede5903aba5e2028e68910b3ab8f91 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 88a78147d88e7bb9f6b327e4c69b9b8e20f2d2a5 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 9f9521c7a9e5c32e953d8e82e1e27213b715f04e 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 ad832ef85e5eb9c4b35bca86f1c16e3668b92087 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 fdb2fbf39aa5ba67fc0fd14b34b9c821cc643dc0 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 9cd32a16634dc95d5e3ceb5438f6282b458a6271 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 f46a6fdbe8ccc4f64e2e8a8d8cd3a6bd753552be 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 3d92153206cebe95dc873a4b2b3d506ddf2271e7 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 125789d6336ce7d3bc66e88534748f6c0b989908 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 ffe508adf85acdd57db01a234161e795b7403062 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 859d56d1356030d34c9c8b104278766468bad3a7 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 7b2150d4dd5ff2ec48d8fa1adc3850d2d6770f09 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 Signed-off-by: Greg Kroah-Hartman commit 0aa08f8f07872b9f67ab20d4c51e0cf6fc924714 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 e35c3b1dc69b8c8efe3d751fafb9b50a85f0e2f7 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 0defa3e443bbdd38628f0b594809c52295836dec Author: Chris Mason Date: Wed Oct 7 11:00:06 2026 +0000 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 Signed-off-by: Greg Kroah-Hartman commit d3cd02c8c6917f36f635d82575a9b206531bbfea 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 3bf6fda63259692331d21392c3f7c0c02594dae5 Author: Chris Mason Date: Wed Oct 7 10:15:11 2026 +0000 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 Signed-off-by: Greg Kroah-Hartman commit 5ccb1e71dfea95a9789967c34d68a2b7c048303e 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 77c9b481faacf46b9d9282ffaa71afbac7acf819 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 b2d4777172bea58a521358f7d9b871cffe4d5751 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 ea5327a9228bfd1609e54f1fca50786e8f963da5 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 73aae2a6b5b34b4ee5dbc7b008fc658c2a16fcea Author: Chris Mason Date: Wed Oct 7 10:53:10 2026 +0000 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 Signed-off-by: Greg Kroah-Hartman commit 558cb79cb242ce7ca8b32c4b39412d125879e8f2 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 20a2fb9842ca504ce8d877ee04fb850a1af5ef73 Author: Eduard Zateev Date: Tue Oct 20 21:45:45 2026 +0200 smb: client: hold server info until cifsd exits commit 482c117c6dbeee382790168af10959810450ab09 upstream. The last session reference can be dropped while the cifsd demultiplex thread is still running clean_demultiplex_info(). That thread frees TCP_Server_Info there, racing with cifs_put_tcp_session() as it releases the server crypto state. syzbot reported a KASAN use-after-free in cifs_crypto_secmech_release(). Keep an object reference for the cifsd thread. Defer final crypto, session-key, network namespace, string, and structure cleanup until both the last session reference and the thread reference are dropped. Drop the thread reference after clean_demultiplex_info() has finished using the server. Build-tested with ARCH=arm64 and W=1 for fs/smb/client/connect.o. The KASAN reproducer was not run on the patched kernel. Fixes: a5c3e1c725af ("Revert "cifs: No need to send SIGKILL to demux_thread during umount"") Reported-by: syzbot+5c3ed2a0de3270efc921@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5c3ed2a0de3270efc921 Reported-by: syzbot+c2ec61adfbcb24e5ec20@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=c2ec61adfbcb24e5ec20 Assisted-by: LLM OpenAI Codex Signed-off-by: Eduard Zateev Cc: stable@vger.kernel.org Tested-by: Michail Andreas Michalopoulos Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit d6074ea8379b4bee953883f3bfa684cbc284eeeb 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 d2052367cbdad321d131e6280f41c4be5a1b5c96 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 2d9e864c234469dc7f56ea974f8269d251441e6a 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 5778be09eab716b7d37f653d72c2c34a25f6ba05 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 cd3119eb1ebf8ea7631f68069addf109d4e77159 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 574aa7782c780b130463e1d7c0605a9e617880d1 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 0eb7cd1641695c5de549516661c9b90ba20f943d 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 7294ec25a13c20fe31c543589466d26cf24207a4 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 d2d69a681cf8b73bbfa7fc867d7bd937661df25b 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 341e2ba83d23b169808b8ccf29d41aee899148fd 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 46607d55c3f29b687731f4eb9904b3b8e4916fa5 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 ba90c13e3347d6765d00544280cff0401027d22a 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 7df669eab2abcb141f43cab1e558c401a1093b37 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 9a9c8607260a4c4903fd59064c6800dd22376a7b Author: Sean Young Date: Fri Jul 17 13:36:31 2026 +0100 media: rc: Fix race condition during rc_register_device() commit ec7cb49871e5c4f85d57290320c50ee0bae4db84 upstream. Device drivers can call ir_raw_event_store() or ir_raw_event_handle() right after rc_allocate_device(). This means that while rc_register_device() is being called, those functions can be called from e.g. interrupt handlers. Currently dev->raw is being allocated and populated by ir_raw_event_prepare() which is called from rc_register_device(). This is not done in a safe way, e.g. dev->raw is being set before the raw members are populated. Call ir_raw_event_prepare() from rc_allocate_device() instead. Fixes: a3572c34da8d ("V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8e0ca5ea8320132377a9177fb582c142254652ac 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 0b7c968ec9b9d53734cc102260cc211b55ae0d8c 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 7a6e8c9726dfd1cb284708f7b179a6bc9bcd6e0e 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 1a565b81f8ddb01d0b43a9060106dcc88cb3c636 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 35f55810ee2410815d687ff00fb8412d63ab2899 Author: Jérémy Jean Date: Sat Oct 3 21:01:55 2026 +0000 nvmet-auth: serialize access to DH-HMAC-CHAP state to fix UAF commit 53f6efe00cea0c0cf7bd99debe3cdac8567170b5 upstream. A REPLY AUTH_SEND command can derive a dhchap_skey key while a concurrent AUTH_RECEIVE command observing this REPLY state executes the failure path and frees that key. The REPLY command then continues and writes into freed memory, causing a use-after-free. KASAN reports it as: BUG: KASAN: slab-use-after-free in __sha256_final Write of size 4 at addr ffff88800359c540 ... nvmet_auth_sq_free (drivers/nvme/target/auth.c:237) nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:621) Add a mutex to each submission queue to serialize authentication commands and timeout handling. Unlock the mutex before completing requests and ignore outdated timeout callbacks. Limit timeout delays to prevent immediate expiry on 32-bit kernels. Fixes: 7a277c37d352 ("nvmet-auth: Diffie-Hellman key exchange support") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Christoph Hellwig Signed-off-by: Jérémy Jean Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 91895cfc28aed7c5daad13475c68588a844843d8 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 ea2aaf6bda6ba90e92abe3aeaff426bba082c0eb Author: Danish Khateeb Date: Tue Sep 29 07:49:35 2026 -0500 pps: generators: don't use the driver's info after unregister commit 4e8063cae337cb7328e6856235cf4de5d165516e upstream. A file that was opened before pps_gen_unregister_source() keeps pps_gen, and with it the pointer to the driver's pps_gen_source_info. PPS_GEN_SETENABLE and PPS_GEN_USESYSTEMCLOCK keep using that pointer after the driver has gone: - pps_gen_tio allocates its info with devm_kzalloc(), so after an unbind both ioctls read freed memory, and SETENABLE calls the driver's enable() with its freed private data. - pps_gen-dummy does not set info->owner, so it can be unloaded while the file is open, and the ioctls then read the unloaded module's data and call its code. TIO can't probe in a VM, as it needs ART. A test driver that registers its info in devm memory like TIO does, unbound while /dev/pps-gen0 is open, gives: BUG: KASAN: slab-use-after-free in pps_gen_cdev_ioctl+0x4c1/0x580 Read of size 1 at addr ffff88800e647f38 by task ppsgen64/145 ... Freed by task 146: kfree+0x25a/0x6d0 release_nodes+0xd1/0x140 devres_release_all+0x10e/0x1a0 device_unbind_cleanup+0x71/0x250 device_release_driver_internal+0x41b/0x570 unbind_store+0xd9/0x100 and unloading pps_gen-dummy while its file is open oopses: BUG: unable to handle page fault for address: ffffffffa0203040 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pps_gen_cdev_ioctl+0x372/0x580 Protect info in the ioctl handler with a mutex, and clear it under the mutex on unregister, so that unregister waits for the ioctls using it and later ones fail with -ENODEV. PPS_KC_BIND does the same for a removed PPS device since commit 3649f9a6b897 ("pps: don't allow PPS_KC_BIND on removed devices"). The sysfs attributes need nothing new: they are removed, and their callbacks drained, before info is cleared. 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-3-danishkhateeb03@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 190a92be785336a03c36450af560a79a631b192d 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 2a3ac39a7a260895d794e0a175e9b9a8d2acd207 Author: Myeonghun Pak Date: Sun Oct 4 00:37:28 2026 -0400 power: supply: pf1550: drain IRQ work before unregistering supplies commit 4856b49317ccd4ce96a0e8970df7d13ce8975a02 upstream. The VBUS work calls power_supply_changed(), but its managed cancellation is registered before the supplies. Cleanup can therefore unregister a supply while IRQ-triggered work is still pending. Commit 838767f50747 ("power: supply: pf1550: Fix use-after-free in power_supply_changed()") moved IRQ requests after supply registration, but left work cancellation before the supplies. That change protects the direct IRQ callbacks, while this fix drains the work they queue. Register the three work items after both supplies and before the IRQs. Cleanup then frees the IRQ producers, drains the work, and unregisters the supplies. The teardown ordering issue was found by static analysis. Fixes: 4b6b6433a97d ("power: supply: pf1550: add battery charger support") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20261004043728.1140015-1-mhun512@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 8a9f16b5237eb5690cc109d37a545f034afa81de 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 6cfde28fca86aedb7084ba3dc669153f32ffda83 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 d858330e288a7818cf6d52ed1bd62153f4cd35c0 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 ac2859c61ecf52a9e39b44b35c981dbfeb8ad54b 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 adb693d0369cd7f08f9424588fdd1f613c22d43b 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 a2942b3abb5bddd1bac418abd61fb5f0616ab897 Author: Andrea Parri Date: Thu Oct 15 10:19:34 2026 +0200 vfio/nvgrace-gpu: Use a core-only open_device in fallback mode commit 9c48b994b66d7b585698f9aaee8ff559a7755c0a upstream. When the ACPI memory properties are missing or the C2C link is down, the device is exposed through nvgrace_gpu_pci_core_ops. That table opens through nvgrace_gpu_open_device() but closes through vfio_pci_core_close_device(), so open and close are not symmetric. nvgrace_gpu_open_device() registers nvdev->usemem for poison handling unconditionally. In fallback mode usemem.memlength is zero, and register_pfn_address_space() inserts a node covering [0, ULONG_MAX]. Nothing removes it: a second open fails with -EBUSY, and once the device is unbound the node outlives the nvdev that contains it. The next open after a rebind reports: BUG: KASAN: slab-use-after-free in interval_tree_iter_first+0x209/0x310 Read of size 8 at addr ffff88800894aa30 by task nvgrace_repro/203 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x153/0x4c6 kasan_report+0xe4/0x1a0 interval_tree_iter_first+0x209/0x310 register_pfn_address_space+0x97/0x100 nvgrace_gpu_open_device+0x21c/0x730 vfio_df_open+0x213/0x520 vfio_df_ioctl_bind_iommufd+0x3e8/0x6e0 vfio_device_fops_unl_ioctl+0x782/0x1570 __x64_sys_ioctl+0x13c/0x1c0 do_syscall_64+0x106/0x630 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 188: ... _vfio_alloc_device+0x3a/0x500 nvgrace_gpu_probe+0xcb/0x660 local_pci_probe+0xcf/0x170 ... Freed by task 188: ... kfree+0x20d/0x600 device_release+0xcf/0x250 kobject_put+0x152/0x2f0 pci_device_remove+0xb0/0x1c0 device_release_driver_internal+0x38d/0x540 unbind_store+0xde/0x100 ... Give the fallback table its own open_device that only calls vfio_pci_core_enable() and vfio_pci_core_finish_enable(), the counterpart of vfio_pci_core_close_device(). Fallback mode then never touches the nvgrace memory regions, as Alex suggested. This should be safe because the fallback table uses the vfio-pci core read, write and mmap handlers, so nothing there uses the state nvgrace_gpu_open_device() sets up. The one visible difference is that a fallback open no longer fails when BAR0 cannot be mapped, which matches vfio-pci. Fixes: e5f19b619fa0 ("vfio/nvgrace-gpu: register device memory for poison handling") Cc: stable@vger.kernel.org Suggested-by: Alex Williamson Assisted-by: LLM Signed-off-by: Andrea Parri Reviewed-by: Ankit Agrawal Link: https://lore.kernel.org/r/20261015081937.405320-2-parri.andrea@gmail.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 3f4c7168ee28e582314249d86833bd515b945196 Author: Weiming Shi Date: Sat Oct 17 04:42:38 2026 -0700 virtio_net: atomically disable rx mode work commit 1234707482053f1d1ac7c5756207d2c29057974c upstream. virtio-net uses a boolean to gate rx_mode_work during device teardown. The flag is changed under RTNL, but ndo_set_rx_mode checks it under the address-list lock. A callback can therefore pass the check and enqueue work after teardown has flushed it. The work is also enabled before late probe operations that can fail, allowing probe unwind to free the netdev with work still queued. KASAN reports the worker using a virtqueue that probe unwind already freed: BUG: KASAN: slab-use-after-free in virtqueue_add_split Workqueue: events virtnet_rx_mode_work Call Trace: virtqueue_add_split (drivers/virtio/virtio_ring.c:706) virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2839) virtnet_send_command_reply (drivers/net/virtio_net.c:3565) virtnet_rx_mode_work (drivers/net/virtio_net.c:3833) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405) Freed by task 119: kfree (mm/slub.c:6625) vp_del_vq.isra.0 (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtnet_probe (drivers/net/virtio_net.c:7129) Use the workqueue disable mechanism to atomically reject new queue attempts and drain running work. Keep work disabled until probe succeeds or restore has reattached the netdev, then enable it and replay receive-mode state for a running interface. Disable it before resource teardown in freeze and remove. Fixes: b9f7425239a0 ("virtio-net: convert rx mode setting to use workqueue") Cc: stable@vger.kernel.org Reported-by: Assisted-by: LLM Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20261017114237.2786302-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 40e3d300cc7e27b12e3307099247d6c5cc1fa009 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 6609261ccf32e95b67b7c762ff23ddd7788114d2 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 5f4b2debc87b6f86b56c6e1f5d97007a330d6aac 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 b0e79d0ed03ee2e2b9bc0b637fcb87567ff46112 Author: Tianchu Chen Date: Wed Sep 9 08:06:26 2026 +0000 staging: rtl8723bs: fix protected RX frame validation in decrypt path commit 495cb31c791bdf3f9efef255a9587b05b0526c9d upstream. The RX software decrypt path mishandles crafted protected frames from a malicious AP in two ways: 1) decryptor() never checks that a protected frame is long enough to hold the 802.11 header plus the per-cipher trailer. All of rtw_wep_decrypt(), rtw_tkip_decrypt() and rtw_aes_decrypt() compute length = hdr.len - hdrlen - iv_len; and act on the result, and recvframe_chkmic() similarly computes datalen = hdr.len - hdrlen - iv_len - icv_len - 8; for TKIP (the 8-byte Michael MIC is not accounted for in icv_len). A frame shorter than hdrlen + iv_len + icv_len (+ 8 for TKIP) underflows these unsigned subtractions, turning into a ~4 GiB iteration count in aes_decipher()/arc4_crypt()/rtw_seccalctkipmic() or a ~4 GiB crc32_le() length, causing out-of-bounds reads/writes of up to ~4 GiB starting from the rx skb. Reject such frames in decryptor() before touching the IV; this covers all three ciphers and the TKIP MIC check, and also keeps the unconditional iv[3] access within the frame. 2) validate_80211w_mgmt() keeps using the frame - two memcpys through the stale rx_data pointer and a pkt_len update - before checking whether decryptor() returned NULL. On decrypt failure (e.g. a unicast protected deauth/disassoc/action frame with a bad MIC, which this path always software-decrypts) the skb has already been freed, so this is a use-after-free read/write, and the caller's error path frees the frame a second time, drifting free_recvframe_cnt. Bail out immediately when decryptor() fails, freeing the temporary mgmt_DATA buffer first. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/8ee3bdd1c45034200cb1aa9a7e9b575b9584643a@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 928335263daf58e8c0e14d860091e57791693ea0 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 bd04acf9b9d589d93823bfeeea9932cd9ce4ee48 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 34500fda2384be9301d1bdda1cd9c8b49f51f7e0 Author: Kyle Zeng Date: Fri Oct 23 16:02:56 2026 -0400 net: sched: prevent scheduling deactivated qdiscs commit d6f81fd6abe209f9803d8f74ce9ec69b8126bad3 upstream. TAPRIO can schedule a deactivated qdisc after some_qdisc_is_busy() has reported it idle. Commit 47e8dbb6e763 ("net/sched: do not reset queues in graft operations") made graft deactivation skip queue reset, leaving TAPRIO's timer armed. A late callback schedules NET_TX softirq work, whose dequeue path can race the unlocked child-queue reset in taprio_reset(). The same skb can be queued for deferred freeing by RTNL and dequeued for transmission. In the reproducer, the TAP reader frees it before __rtnl_unlock() reads its next pointer. KASAN reports a slab-use-after-free in __rtnl_unlock+0xa3/0xd0, with a read of size 8 from the freed skb. Reject deactivated qdiscs in __netif_schedule(). Callers' RCU protection lets the existing grace period join earlier scheduling calls before the busy check. Restart nonempty transmit queues on reactivation so suppressed scheduling does not strand packets. Fixes: 47e8dbb6e763 ("net/sched: do not reset queues in graft operations") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netdev/20260805102514.740834-1-david.lee@trailofbits.com/ Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Signed-off-by: Dave Miller Signed-off-by: Greg Kroah-Hartman commit d6bb100e3febf5d0c6c6bed4d4edc5ff7ac0937a Author: Harshit Mogalapalli Date: Fri Sep 25 05:55:45 2026 -0700 mtd: virt-concat: unlink discarded items before freeing commit 112a666bd82e96e4a01e0cd8a0fb9c88dd0bce38 upstream. mtd_virt_concat_destroy_items() frees each item without removing it from concat_node_list. list_for_each_entry_safe() protects the current traversal, but concat_node_list still points to the freed items afterward. The function also unwinds errors from mtd_virt_concat_node_create(). A later initialization can traverse a freed item in mtd_is_part_concat(), causing a use-after-free. Unlink each item before freeing it. Fixes: 43db6366fc2d ("mtd: Add driver for concatenating devices") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6, smatch Signed-off-by: Harshit Mogalapalli Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 6c3c09d54a4316ea9f3340cf960f962882d0bfa2 Author: Harshit Mogalapalli Date: Fri Sep 25 05:55:44 2026 -0700 mtd: virt-concat: unlink concat node before freeing it commit 532caaa2f445b22b74b88b4023a810426772db54 upstream. mtd_virt_concat_create_item() links each new mtd_virt_concat_node to concat_node_list. mtd_virt_concat_destroy() later frees the node after destroying its concatenated MTD device, but fails to unlink it. A later list traversal dereferences the freed node, causing a use-after-free. Remove the node from concat_node_list before freeing it. Fixes: 43db6366fc2d ("mtd: Add driver for concatenating devices") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6, smatch Signed-off-by: Harshit Mogalapalli Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit ce2b83e47af491f4b7f0f286367b34cdc57e17e9 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Mon Oct 19 17:43:48 2026 +0900 mshv_vtl: detach poll waiter on POLLFREE commit efc5dc4c15713fdd6e87882686a26ed1deb22dab upstream. MSHV_SET_POLL_FILE keeps a poll wait entry after the ioctl returns. A file reference does not always pin the registered waitqueue: signalfd_poll() uses current->sighand->signalfd_wqh, whose lifetime is tied to the task. signalfd_cleanup() sends POLLFREE before the sighand is freed. The MSHV callback currently leaves its entry linked, so __wake_up_pollfree() warns and a later replacement calls remove_wait_queue() through a stale wqh pointer. A source-equivalent KASAN run reproduced: BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave _raw_spin_lock_irqsave remove_wait_queue harness_ioctl [mshv_pollfree_harness] The object belonged to sighand_cache and had been released through slab_free_after_rcu_debug() after __cleanup_sighand(). On POLLFREE, unlink the entry under the provider waitqueue lock. Preserve the existing CPU cancellation before publishing a NULL wqh, since a NULL load lets a racing replacement reuse the persistent poll state. Use a matching acquire load under RCU when removing a normal registration. The callback takes no mutex and does not sleep, so the existing mutex-to-waitqueue-lock order is unchanged. An LLM assisted the source audit, fix development, and validation of this issue. Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver") Cc: stable@vger.kernel.org Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Naman Jain Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit aff16e324463d31add9312b171ea96a309cbe4e3 Author: Ruide Cao Date: Tue Oct 13 16:29:21 2026 +0200 mptcp: hold MP_JOIN msk ref when cloning reqsk commit c9c90cf437a9e6597611b6d3aad6e255fad22867 upstream. TCP request migration clones pending request sockets with inet_reqsk_clone(). For MPTCP MP_JOIN requests this byte-copies subflow_req->msk, but the clone does not own a reference. The original and cloned requests can consequently drop the same msk reference, leaving one request with a dangling pointer. This manifests as a KASAN slab-use-after-free in subflow_req_destructor(): BUG: KASAN: slab-use-after-free in subflow_req_destructor (net/mptcp/subflow.c:45) Write of size 4 at addr ff1100010e008d40 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5-00353-gc27e36054537 #10 PREEMPT(full) Call Trace: subflow_req_destructor (net/mptcp/subflow.c:45) subflow_v4_req_destructor (net/mptcp/subflow.c:694) __reqsk_free (net/ipv4/inet_connection_sock.c:906) reqsk_timer_handler (include/net/request_sock.h:137 net/ipv4/inet_connection_sock.c:1147) Allocated by task 10014: sk_prot_alloc (net/core/sock.c:2246) sk_clone (net/core/sock.c:2488) mptcp_sk_clone_init (include/net/sock.h:1848 net/mptcp/protocol.c:3564) subflow_syn_recv_sock (net/mptcp/subflow.c:883) tcp_check_req (net/ipv4/tcp_minisocks.c:934) Freed by task 0: slab_free_after_rcu_debug (include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6439) rcu_core (kernel/rcu/tree.c:2645 kernel/rcu/tree.c:2897) Last potentially related work creation: kmem_cache_free (mm/slub.c:2638 mm/slub.c:6377 mm/slub.c:6504) __sk_destruct (net/core/sock.c:2289 net/core/sock.c:2391) sk_destruct (net/core/sock.c:2419) __sk_free (net/core/sock.c:2430) sk_free (net/core/sock.c:2441) mptcp_close (include/net/sock.h:2020 net/mptcp/protocol.c:3399) inet_release (net/ipv4/af_inet.c:442) The buggy address belongs to the cache MPTCP of size 2968 The buggy address is 128 bytes inside a freed 2968-byte region A non-NULL subflow_req->msk means that the request owns one reference. The third ACK can concurrently transfer the original request reference to the child and release it, so taking an unconditional hold on the copied pointer is unsafe. MPTCP sockets use SLAB_TYPESAFE_BY_RCU and all current inet_reqsk_clone() callers run in an RCU read-side critical section. Document and lockdep-check that calling-context requirement. Read the pointer from the original request and acquire a reference only if it is still live. Use refcount_inc_not_zero_acquire() so the subsequent ownership validation cannot be reordered before the try-get, then re-read the original request to verify that it still owns the same msk. If either check fails, clear the clone pointer; otherwise its normal destructor balances the new reference. Mark the ownership-transfer store with WRITE_ONCE() to match the lockless reads. The following patch completes the clone fixup for MP_CAPABLE token ownership. Both patches carry the same Fixes tag and are required for stable backports. Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.") Cc: stable@vger.kernel.org Reported-by: Kyle Zeng Reported-by: David Lee Reported-by: Vega Closes: https://lore.kernel.org/all/20260804095051.715355-1-david.lee@trailofbits.com/ Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20261013-net-mptcp-misc-fixes-7-3-rc8-v1-3-932c9b182fc7@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9efc8d0c9c81094cfa99667154f5682d487e9b63 Author: Vernon Yang Date: Wed Sep 9 10:58:01 2026 +0800 mm: khugepaged: fix swap entry value to folio_pfn() commit 942c8ec27aa4ffc587511650718349964e1696e6 upstream. Patch series "mm: khugepaged: fix tracepoint UAF", v5. The khugepaged tracepoints take a folio pointer and call folio_pfn(), but by then the folio may no longer be valid: freed after folio_put(), folio_unlock() or pte_unmap_unlock(), or not a folio at all but an xarray-encoded swap entry. On classic SPARSEMEM, dereferencing it oopses khugepaged as soon as the trace event is enabled; on other memory models it merely prints a bogus pfn. Pass the pfn to the tracepoints directly, captured while the folio is still pinned, closing the use-after-free windows in mm_khugepaged_scan_file(), mm_khugepaged_scan_pmd() and mm_khugepaged_collapse_file(). This patch (of 3): When the swap entries found exceed max_ptes_swap, the loop is left via break with folio still holding the xarray value that encodes the swap entry, not valid folio pointer. That value is passed to trace_mm_khugepaged_scan_file(), which feeds it to folio_pfn(). On FLATMEM and SPARSEMEM_VMEMMAP, the page_to_pfn() is plain pointer arithmetic, so the trace event merely prints bogus scan_pfn. On classic SPARSEMEM, the page_to_pfn() reads page->flags, dereferencing the tiny encoded integer and oopsing khugepaged whenever the trace event is enabled. So when folio is the swap entry value, simply set pfn to -1, just like exhausted scan naturally. And the folio_put() has maybe dropped the last reference of folio. The trace_mm_khugepaged_scan_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-1-vernon2gm@gmail.com Link: https://lore.kernel.org/20260909025804.3233645-2-vernon2gm@gmail.com Fixes: d41fd2016ed0 ("mm/khugepaged: add tracepoint to hpage_collapse_scan_file()") Signed-off-by: Vernon Yang Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Lorenzo Stoakes Cc: Ryan Roberts Cc: Zach O'Keefe Cc: Signed-off-by: Greg Kroah-Hartman commit 6bfd20c1f7ef92417ff4efd878ca52f9ac51f9d0 Author: Vernon Yang Date: Wed Sep 9 10:58:02 2026 +0800 mm: khugepaged: fix folio is used after pte_unmap_unlock() commit ba2f1f92ddfabd340c9248fd2380104f717ee8b1 upstream. After the page table lock has dropped, the folio can be freed concurrently. The trace_mm_khugepaged_scan_pmd() is left with a dangling folio pointer. So using the folio_pfn() before dropping the page table lock, closing use-after-free window. And other pre-existing bug, When the `for (i = 0; i < HPAGE_PMD_NR; i++)` iteration to terminate and the folio operation preceding is normal, but pfn will be incorrect. so we really only trace the PFN if it really was problematic. Link: https://lore.kernel.org/20260909025804.3233645-3-vernon2gm@gmail.com Fixes: 7d2eba0557c1 ("mm: add tracepoint for scanning pages") 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 0ff1c54374e97f6a1ebe240389e22fb44dbbeaf0 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 863ecacdae9ebac39e25a3e90e6cec3e86bc856a Author: Zhang Yi Date: Mon Sep 28 20:08:31 2026 +0800 mm/truncate: look up the end-edge straddler by index commit f47dee903b9f0f1e4e7181e8a398a7678cabf0a5 upstream. In truncate_inode_partial_folio(), after the first split at the start edge, folio_split() unlocks and drops the refcount of the after-split sub-folios. The sub-folio straddling the end of the truncation range is therefore unlocked and only transiently ref'd in the page cache while the code still derives it from a page pointer inside the original folio. Between the first split finishing and page_folio() resolving split_at2, that tail page can be reclaimed, freed and reallocated as a new large folio in the same mapping at a different file offset. folio2 then points at a folio that does not cover the end boundary, yet folio2->mapping == folio->mapping still holds, so the stale pointer passes the mapping check and folio_split_or_unmap() splits a folio at a wrong position (or, with a transient refcount, a use-after-free window opens between try_get and the split). __folio_split()'s own folio != page_folio(split_at) check cannot catch this either since split_at2 has been reallocated as part of the new folio, so page_folio(split_at2) resolves back to folio2. Look the straddler up by its page index instead. __filemap_get_folio() returns the folio currently covering the boundary, ref'd and locked, with the mapping validated under the lock, so the split target is always the real folio at the end edge. Link: https://lore.kernel.org/20260928120833.3440834-3-yi.zhang@huaweicloud.com Link: https://lore.kernel.org/linux-mm/DLGXT0ERY79Z.3C5DYVJVX6S9Z@nvidia.com/ Fixes: 7460b470a131 ("mm/truncate: use folio_split() in truncate operation") Signed-off-by: Zhang Yi Signed-off-by: Andrew Morton Reported-by: Sashiko Closes: https://sashiko.dev/#/message/20260916094500.C30061F00893%40smtp.kernel.org Suggested-by: Jan Kara Suggested-by: Zi Yan Reviewed-by: Jan Kara Reviewed-by: Brian Foster Acked-by: Zi Yan Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Hugh Dickins Cc: Baolin Wang Cc: Matthew Wilcox (Oracle) Cc: Joanne Koong Cc: Darrick J. Wong Cc: Cc: Yang Erkun Cc: Zhihao Cheng Cc: Kefeng Wang Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 93c839762ea9fa7339722ec815b9e32597858ed5 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 b8c683bd548268453d50e933aab2e7d50a7ac2be 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: Greg Kroah-Hartman commit b81d7da262d9c13b3997966536fa73b9a8252832 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 e0e12b25b102e22f17ec3d0c00eb22ef7b792489 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 f402682026d589474209816ef37dbeb945ebdb62 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 e7dd17ce3190dd6f60e2d0153d8df15562347947 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 71de8e33596c9c8b3e20e51e18883e6c5f25f7a4 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 9e393784a902bb4eb00a21e46d389a32c7ea61b0 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 f6b21af3e32f142bf3e591dbb10044c60472f716 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 47b32af13359e1bf859a449daa7a1b389bd93cb9 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 c3d0261c4fae2cc36dcf9f4e247552498232caff 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 fabc002f6396202b5ad7ad4ceec24d27aad90f3f Author: David Woodhouse Date: Mon Aug 31 22:26:43 2026 +0100 KVM: pfncache: use a dedicated invalidation sequence for cache refresh commit da260bcb56feeb6489a83f310308453a0a7de25e upstream. The gfn_to_pfn_cache refresh path guards against mmu notifier invalidations which complete while it has dropped gpc->lock for the HVA->PFN lookup: hva_to_pfn_retry() samples kvm->mmu_invalidate_seq and retries if it changed, or if mn_active_invalidate_count is still elevated. That is insufficient for HVA-based caches. mmu_invalidate_seq is only advanced by kvm_mmu_invalidate_end() when the invalidated range overlaps a memslot, and an HVA-based cache (e.g. the Xen shared_info page mapped with KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA) need not be backed by any memslot at all. An invalidation of the cached HVA which starts and ends entirely within the lookup window is thus invisible to the retry check: mn_active_invalidate_count is back to zero and the sequence never moved. The refresh then publishes a mapping of a page which has already been freed, and the next reader dereferences it: BUG: KASAN: use-after-free in kvm_xen_shared_info_init+0x3c6/0x440 Read of size 4 at addr ffff8880599c2900 by task syz.2.383/7257 Since gfn_to_pfn_cache_invalidate_start() deliberately skips caches which are not currently valid (including one whose refresh is in progress, as the refresh clears the valid flag before dropping the lock), the retry check is the only line of defence, and it must fire for *any* invalidation, not just those hitting a memslot. Add a dedicated kvm->gpc_invalidate_seq, incremented by every kvm_mmu_notifier_invalidate_range_end() under mn_invalidate_lock before mn_active_invalidate_count is decremented, and check it in hva_to_pfn_retry() instead of mmu_invalidate_seq. Incrementing in range_end() in the same critical section as the in-progress count also closes the variant where the cache is activated with the contested HVA only after invalidate_range_start() has run. The same bug is also reachable through the per-vCPU vcpu_info cache (KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO_HVA), where the stale mapping is then dereferenced by kvm_setup_guest_pvclock() on the next KVM_RUN: BUG: KASAN: use-after-free in kvm_setup_guest_pvclock+0x5bf/0x660 This intentionally makes refresh retry on *unrelated* mmu notifier events; restoring precision (and reworking the GPC locking more generally) is left for a subsequent series. Reproducers: https://david.woodhou.se/xen_shinfo_race.c https://david.woodhou.se/vcpu_info_race.c Suggested-by: Sean Christopherson Reported-by: syzbot+0948c82180d475ad24e2@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a0c5f2c.a00a0220.2c7954.0000.GAE@google.com/ Tested-by: syzbot+0948c82180d475ad24e2@syzkaller.appspotmail.com Reported-by: syzbot+fb7c2dd166d3ea63df2a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a426dd2.854d4ab9.360e1d.0008.GAE@google.com/ Fixes: b9220d32799a ("KVM: x86/xen: allow shared_info to be mapped by fixed HVA") 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-13-dwmw2@infradead.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2fa83c615f8dbb240b262265e788b120b6384e7b Author: Sean Christopherson Date: Mon Sep 21 17:13:27 2026 -0700 KVM: guest_memfd: Gracefully handle xarray errors when binding a memslot commit e6ecb88711d93b9e014532f17d3d29b57e80932c upstream. If inserting a memslot into a guest_memfd's bindings xarray fails, propagate the error back to the caller, i.e. fail memslot creation as well. Signalling success and continuing on with memslot creation results in use-after-free, as the guest_memfd instance will remain reachable via the memslot after the file is freed (kvm_gmem_release() won't nullify the file pointer due to lack of a valid binding). Opportunistically WARN and reject binding if KVM_MEMSLOT_GMEM_ONLY is already set, partly to guard against goofs elsewhere, but mostly so that KVM doesn't need to worry about clobbering flags when unwinding on failure. Regarding the unwind, the slot must be fully prepared before inserting it into the bindings, at which point the slot becomes reachable. I.e. waiting to update the slot in order to avoid the ugly unwind isn't an option. And as part of the unwind, explicitly nullify the relevant bindings, as xarray can store a subset of entries when populating a range. Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Reported-by: Dennis Tighe Reported-by: Sashiko Bot Closes: https://lore.kernel.org/all/20260823135031.4F6DC1F000E9%40smtp.kernel.org Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Ackerley Tng Link: https://patch.msgid.link/20260922001332.1121266-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 73a1e1bfe3dbf5efe3d0e21e2ec9ea73fe110f4f 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 212557010f57ae2b2b376e09dc2de1880f56dbc9 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 11239f2b509cd09d76c564b5fe262c70bad8ea3c 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 f214e9fe86a0aba6deb4a0b31b9998fb2b6879b5 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 62fa0acd3bd87d6d9a59bbbef101c6fbf3db297d 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 08aaea3e62b2ddc69a65d52609a5924559d05af2 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 10c13801ea38e4ced23c59052ce45acb07c5deda Author: Eric Biggers Date: Sun Oct 25 13:48:07 2026 -0700 fsverity: Set S_VERITY only after rollback is no longer possible commit c349b233d6ab0fc3517401a1e2d36f5f90eb8c9b upstream. Commit f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info") changed the implementation of FS_IOC_ENABLE_VERITY to make concurrent reads start going through fsverity verification slightly earlier than they did before. Instead of it happening when enable_verity() calls fsverity_set_info(), it now happens when ->end_enable_verity() sets S_VERITY. However, ext4 and btrfs can roll back verity after they set S_VERITY, causing a use-after-free. Fix that by making ext4 and btrfs set S_VERITY only after rollback is no longer possible. On failure, don't roll back S_VERITY, but do roll back the filesystem-specific verity flag. Also update enable_verity() to handle any future instances of this bug more safely by warning and *not* freeing the fsverity_info. Finally, tweak some comments. Clarify one, and move information from another to its proper place in the comment for ->end_enable_verity(). Fixes: f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20261025204807.122875-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 14a853bf3e6f0dd62ff479a36613411237dec24c 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 a6e222f1d75bce8de430ba4d0f8c6a1e923f9acd Author: Zhao Gongyi Date: Fri Oct 23 19:12:50 2026 +0800 filelock: keep superblock active through delegation wait commit c206cdfee6c037b829178bb7e17e6e37ddc9aa35 upstream. A caller may drop its path after try_break_deleg() returns a delegated inode but before break_deleg_wait() finishes. The extra inode reference held in struct delegated_inode does not keep the superblock active. After a lazy unmount, closing the delegation holder can release the last mount reference and shut down the superblock while another task waits for the delegation break. The waiter's final iput() can then enter the filesystem's eviction code after its superblock-private state was freed. This has been observed as a KASAN use-after-free in shmem_evict_inode(). When try_break_deleg() saves a delegated inode, take an active reference to its superblock while the caller still pins the mount. Keep that reference through break_deleg_wait() and the final iput(), then release it with deactivate_super(). This protects every caller of the helpers, including the mknod, mkdir, symlink and rmdir paths that drop their path before waiting. Fixes: e12d203b8c88 ("vfs: allow mkdir to wait for delegation break on parent") Fixes: 4fa76319cd0c ("vfs: allow rmdir to wait for delegation break on parent") Fixes: c826229c6a82 ("vfs: make vfs_create break delegations on parent directory") Fixes: e8960c1b2ee9 ("vfs: make vfs_mknod break delegations on parent directory") Fixes: 92bf53577f01 ("vfs: make vfs_symlink break delegations on parent dir") Link: https://lore.kernel.org/r/20261016093421.90725-1-zhaogongyi@bytedance.com Cc: stable@vger.kernel.org Signed-off-by: Zhao Gongyi Link: https://patch.msgid.link/20261023111250.17696-1-zhaogongyi@bytedance.com Reviewed-by: Jeff Layton Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 4bc608af98a3da0fa0b17af67a64d0d11d625a1d 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 f099d5adad31609a6de64aea12a8609734570b00 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 4fa318e637dc83ed621073b058bcf404a2ff0845 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 19502449eeeafbf48ad1626cc356d178d549fcc0 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 01ab732291bb05cc60952cbb365f4523b747ccfb 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 76319a56f069bb950d9cebbc1a291cbfa94a1c1f 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 fb5ae914176d7252c9bd6aee7ab94a64a41ebf3b 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 aa7e5d71f90cb0048c0143ccdb6199acc2a6f66d 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 35003a3a2221207ded92ca4c60a54c2f83136473 Author: Eva Crystal <0xiviel@gmail.com> Date: Mon Sep 14 09:31:55 2026 +1200 accel/amdxdna: clear the mailbox channel pointer when starting it fails commit 2117e3d96a4fd1ee13fa28b31494ff5f5db6ccf4 upstream. aie2_create_context() allocates a mailbox channel, starts it, and on a failed start frees it again: hwctx->priv->mbox_chann = xdna_mailbox_alloc_channel(ndev->mbox); ... ret = xdna_mailbox_start_channel(hwctx->priv->mbox_chann, ...); if (ret) goto free_channel; ... free_channel: xdna_mailbox_free_channel(hwctx->priv->mbox_chann); hwctx->priv->mbox_chann keeps pointing at the freed channel. That pointer is the driver's own test for whether a hardware context has a usable channel: aie2_destroy_context() returns early on NULL, aie2_sched_job_run() refuses to run a job on NULL, and the message helpers return -ENODEV on NULL. A stale pointer passes all of them. It matters on the restart path. aie2_hwctx_restart() calls aie2_create_context() again on a hardware context that is already live, after aie2_hwctx_stop() has torn its channel down, and the context survives a failure there: aie2_sched_job_timedout() discards the return value entirely, and aie2_hwctx_resume() only propagates it. What is left is a live hardware context holding a freed channel, and every later user of it takes the non-NULL branch: - the next job submitted reaches xdna_mailbox_send_msg() on the freed channel, via the !mbox_chann guard in aie2_sched_job_run(), - a second command timeout reaches aie2_hwctx_stop() -> aie2_destroy_context(), - closing the device reaches aie2_hwctx_fini() -> aie2_release_resource() -> xrs_release_resource() -> aie2_xrs_unload() -> aie2_destroy_context(), and aie2_destroy_context() then calls xdna_mailbox_stop_channel() followed by xdna_mailbox_free_channel() on memory that was already freed: a use-after-free, and a second free of the same channel. The AIE4 management channel already does this correctly - aie4_mailbox_start() clears ndev->aie.mgmt_chann right after freeing it. Do the same here. The create path itself is not affected: when aie2_xrs_load() fails, xrs_allocate_resource() removes the solver node without calling ->unload, and aie2_hwctx_init() frees hwctx->priv, so the stale pointer never outlives the structure holding it. Starting a channel can fail today without this patch: the ring buffer sizes firmware reports are rejected unless both are powers of two, and request_irq() can fail. Fixes: d5b8b0347fa8 ("accel/amdxdna: Split mailbox channel create function") Cc: stable@vger.kernel.org Signed-off-by: Eva Crystal <0xiviel@gmail.com> Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/2fcf0eca215090dbbd95cb86e1bf5076056d3818.1789334558.git.0xiviel@gmail.com Signed-off-by: Greg Kroah-Hartman commit 64112b14e30cd1f799c7fd60b9de4aa270bcf049 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 3eba9d12ef59739fdd211f1f4773776de404a12a Author: Priya Bala Govindasamy Date: Wed Sep 23 20:31:45 2026 +0000 rust: module_param: Fix potentially incorrect access of `SetOnce` commit 2e8bac09ed6d7aa2ad4e8a9a6cba67e5835865c2 upstream. The `set_param` function casts `kernel_param.arg` to `*const SetOnce` But the Rust module macro in rust/macros/module.rs initializes `arg` with `#param_name.as_void_ptr()`, and `#param_name` is a `ModuleParamAccess`, not a `SetOnce`. ModuleParamAccess has default Rust layout but `set_param` accesses its first field SetOnce assuming it to be at offset 0. This is not guaranteed by Rust and could cause type confusion leading to data corruption. Fix this by casting `kernel_param.arg` to `ModuleParamAccess` and then accessing the `value: SetOnce` field. Fixes: 0b08fc292842 ("rust: introduce module_param module") Cc: stable@vger.kernel.org Reported-by: Dylan Zueck Assisted-by: LLM Suggested-by: Andreas Hindborg Signed-off-by: Priya Bala Govindasamy Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman commit 13d0556da30faeae6bd28584fc5258967bd5ea49 Author: Alice Ryhl Date: Tue Oct 20 08:28:37 2026 +0000 rust: fwctl: declare cfi_encoding for fwctl_rpc_scope commit bc6f2a284c63313e789d8cd294531e1cc2dc8c99 upstream. Currently, VTable::fw_rpc_callback() takes scope as a u32, whereas C calls fwctl_ops::fw_rpc with enum fwctl_rpc_scope. With kCFI enabled, enum types are encoded distinctly from integers, causing every fw_rpc indirect call into a Rust fwctl driver to trip a CFI failure. Thus, generate fwctl_rpc_scope as a newtype with a cfi_encoding attribute and use it in fw_rpc_callback(). Link: https://patch.msgid.link/r/20261020-fwctl-cfi-encoding-v1-1-ebb30d1500df@google.com Cc: stable@vger.kernel.org Fixes: e052daab94ee ("rust: introduce abstractions for fwctl") Signed-off-by: Alice Ryhl Reviewed-by: Zhi Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit b6ef73666dc4c5922f23e69ad4d126739f626b86 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 b91e8d8c2ed97b49a2fd6c2c9516586a8f2aa3c0 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 84bbe321c4c345d6ea8af56bfb8138afb8957eae Author: FUJITA Tomonori Date: Fri Oct 2 19:45:50 2026 +0900 rust: bug: update the SAFETY comment for warn_slowpath_fmt() on UML commit 5c94956f2bfb87025c1eaded6c51d5841d38d333 upstream. The SAFETY comment says that it is always safe to call `warn_slowpath_fmt()` with a valid null-terminated string. This is not true. The taint argument must also be a valid taint number. Commit 951d09ca450c ("rust: bug: pass TAINT_WARN to warn_slowpath_fmt() on UML") fixed a bug where it was not. List each condition that the call meets: the file name, the taint number, and the null `fmt`. Suggested-by: Miguel Ojeda Signed-off-by: FUJITA Tomonori Link: https://patch.msgid.link/20261002104550.2877930-1-tomo@flapping.org Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit e05c740e7536fbd5dd85b437eea50f39e45fc87d Author: FUJITA Tomonori Date: Thu Oct 1 21:31:03 2026 +0900 rust: bug: pass TAINT_WARN to warn_slowpath_fmt() on UML commit 951d09ca450ca76a695016ea76c3fa653bd20439 upstream. On UML, `warn_flags!` calls `warn_slowpath_fmt()` directly. Its third argument is a taint number, but `warn_on!` passes its bug flags there. As a result, `add_taint()` gets 2304 instead of 9 (`TAINT_WARN`). The warning is not recorded: `/proc/sys/kernel/tainted` stays 0 after `warn_on!` fires, where it should be 512. It also causes an out-of-bounds write in `add_taint()`. Pass `TAINT_WARN` directly, as C does on UML. Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori Link: https://patch.msgid.link/20261001123103.2198104-1-tomo@flapping.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 9c64b4a95500229d923d9c00d46b687ff326d2d8 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 acb67dcaf7c5a39ddb132c56df043fa29be4ce4c 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 0d1415d4f6147f93bbc323215cfa3b5261ceadb3 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 5628b545fda23e392e11158fabd3019126013f8a Author: Lorenzo Stoakes Date: Tue Jan 13 19:29:49 2026 +0000 rust: bindings: fix VM_MAYSHARE value commit 7b5ba47d845f35b04937748a191a1772ffc1f288 upstream. Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") added a number of overrides to the rust bindings helper as the change performed in the commit caused rust bindgen to not be able to automatically determine values of VMA flags. However a typo was introduced leaving VM_MAYSHARE to be incorrectly interpreted as VM_MAYEXEC in rust code. This patch fixes the typo. Fixes: 2b6a3f061f11 ("mm: declare VMA flags by bit") Reported-by: Chris Mason Closes: https://lore.kernel.org/all/20260113185142.254821-1-clm@meta.com/ Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Alice Ryhl Reviewed-by: wang lian Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260113192949.689834-1-lorenzo.stoakes@oracle.com [ Reworded to improve title and to fix typo. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit c49e6b77a65baaf8e0eca9d301c0c1904d34d145 Author: Miguel Ojeda Date: Wed Sep 30 14:36:45 2026 +0200 rust: bindings: fix `VM_MAYSHARE` blocklist entry commit f9a6960c7b27c03becd50a2a7620273d80e4040d upstream. Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") added constant helpers for the VMA flags and blocklist entries to suppress their direct bindings. However, it listed `VM_MAYEXEC` twice and omitted `VM_MAYSHARE`. Thus fix it. Fixes: 2b6a3f061f11 ("mm: declare VMA flags by bit") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Alice Ryhl Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Vishal Moola (Fractile) Link: https://patch.msgid.link/20260930123645.302318-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit eb826c12c094481d127776a9231f7183b204ce36 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 7d3df012573523cb2f38a65e3e00125d9869b390 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 dfba346a73fba0962eca9c9c786e45b1a412380f 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 b17e2a13af7c3bb8a5f41203f2cb6007cc068de2 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 f1fb9f9087c76bca6de81aa38e1e9c820dc54744 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 8e56f274d61a21e7aa0bf4000f839f34dd721fe5 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 4e1bf2f5fe28cb8719aee7ca9d99ea529224ed1f 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 9970418ce814d13396778694a5170073449dcd34 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 6d10563bdbbaaf9d0cd6a5f0186202312970ebe2 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 47597992e6c20a298cec03016ebba669f0e17484 Author: Harald Freudenberger Date: Tue Oct 6 17:46:02 2026 +0200 s390/zcrypt: Guard domain index uses against speculative bypass commit 7b88e8b6d714cd1b2b6185e2963c8ec4d98542d0 upstream. The previous array_index_nospec() placement only covered the admin permission check, leaving ap_test_config_usage_domain() and ap_test_config_ctrl_domain() in the CCA path exposed to speculative execution. Move the sanitization to before all permission and config checks in both the CCA and EP11 paths. Hold the sanitized domain value in another variable so that the later use can choose to use either the original value (subject to speculative execution) or the sanitized value (which may in case of AUTOSEL_DOM reflect the wrong value). Before that, check the domain value to be either AUTOSEL_DOM or in range 0...AP_DOMAINS-1 and return with -EINVAL in case this check does not pass. Fixes: e935cd525af4 ("s390/zcrypt: Close speculative mem read possibility") 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 21268907891d5496e495ca17511aff11d8f99731 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 0f0aa2b560a6eca76778083b0c6f155bb458b56f Author: Harald Freudenberger Date: Fri Oct 2 12:52:36 2026 +0200 s390/zcrypt: Fix and improve zcrypt reply message verification checks commit 5e9b339f323216d71f3ede8a0a427abf7859c486 upstream. Add or improve checks related to buffer sizes and reply sizes to the handling of replies from the crypto cards for CCA, EP11 (AP message type 6) and ICA (AP type 50) messages. The verification code related to reply field length was not designed well and thus firmware deficiencies could lead to unexpected behavior in the zcrypt device driver. Thus improve the code to more closely inspect especially length fields at message replies. Add length validation before accessing reply message structures in zcrypt_msgtype6_receive(), zcrypt_msgtype6_receive_ep11(), and zcrypt_msgtype50_receive() to prevent out-of-bounds reads and potential kernel memory disclosure. Also rework these three functions to validate reply lengths more carefully before copying data back into the request buffer. Use size_t for length calculations, reject inconsistent reply sizes, and add defensive handling for short invalid replies. For XCRB replies, validate both reply segments and derive the effective message length from the covered range instead of trusting only the second segment. Additionally improve some of the later invoked evaluation functions which further check the payload. Add comments about length assumptions and for the type50 processing rework the payload processing completely with removing a misplaced BUG_ON(). Fixes: 5e55a488c87a ("s390/zcrypt: Separate msgtype implementation from card modules.") 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 1653ab681d830fcc20d69334f36808765b4de3fd Author: Christian Borntraeger Date: Tue Sep 29 15:58:29 2026 +0200 s390/vmcp: Initialize full session info to zero commit f63eb4ee4a30fc5d8de07a229d92310e3c8d560c upstream. The cma_alloc bit as well as the response can contain old data. cma_release will not free the kmalloced memory in that case and the response code might leak kernel stack data to CAP_SYS_ADMIN users. Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 7ababff2091426b9bf955d8c25814cedff7182bd 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 e3d89fe35617477806a65d0f5769efb237dfb6ef 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 641040939ef86fd149e90f3cd4025607afcf160d 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 47cbef6070391b1ebc2b28cbf728f20b0847b9f2 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 0bd89971c20e20eb2ebfc300142ff06842f0ce7d 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 3ec7ced89d2c2e1ab919183544a518d5ea6bfa98 Author: Tobias Schumacher Date: Fri Oct 9 08:15:52 2026 +0200 s390/pci: Add error cleanup in zpci_directed_irq_init() commit 769f66f595c11185c66913ea5d96420504bfebc3 upstream. If per-CPU airq_iv allocation fails in the loop, previously allocated vectors and arrays leak. Add proper error path to release all resources on failure. The error path frees zpci_sbv, but SIC_IRQ_MODE_DIRECT has already programmed its address into the hardware. Set the directed interrupt mode only after all allocations have succeeded, so a failed init leaves no freed memory registered with the hardware. Fixes: e979ce7bced2 ("s390/pci: provide support for CPU directed interrupts") Cc: stable@vger.kernel.org Signed-off-by: Tobias Schumacher Reviewed-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit da15d34d6cb9cdca309c59d1ae0f155da31ed2c2 Author: Tobias Schumacher Date: Fri Oct 9 08:15:51 2026 +0200 s390/pci: Fix use-after-free race in zpci floating interrupt cleanup commit 422d75ad5bc96b8eb9cb3cfd9d68fc685a0a9b75 upstream. zpci_clear_irq() stops the adapter from raising new interrupts for the function, but a zpci_floating_irq_handler() already running on another CPU can still be scanning zdev->aibv when zpci_msi_teardown_floating() releases it. Clear the zpci_ibv[] entry so no further handler picks the vector up, then wait for a grace period before releasing it. The handler runs inside the rcu_read_lock() section that do_airq_interrupt() holds across airq->handler(), so synchronize_rcu() drains any handler still in flight. Release the vector and free the summary bit only after the grace period, so neither can be reused while a reader still holds the old pointer. zpci_ibv served both delivery modes, indexed by function under FLOATING and by cpu under DIRECTED. Only the floating vectors are published to and torn down under the interrupt handler, so split the directed vectors out into zpci_dibv and annotate zpci_ibv __rcu, which lets sparse check the accessors above. Fixes: f770950a4709 ("s390/pci: Migrate s390 IRQ logic to IRQ domain API") Cc: stable@vger.kernel.org Signed-off-by: Tobias Schumacher Reviewed-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 5c1096d6d24aa595decdb229542cf772a7a9e21e Author: Tobias Schumacher Date: Fri Oct 9 08:15:49 2026 +0200 s390/pci: Fix resource leak in zpci MSI setup commit 4a185d99179a307d856dc43610cfe72395d0c42a upstream. If airq_iv_create() fails in __alloc_airq(), the zpci_sbv bit allocated by airq_iv_alloc_bit() is never freed. This permanently leaks one of the ZPCI_NR_DEVICES summary bits, reducing system capacity with each failed device hotplug. In systems with repeated device insertion failures or under memory pressure, all summary bits can be exhausted, preventing new PCI devices from being added until reboot. Add proper error handling to free the zpci_sbv bit and reset zdev->aisb if the AIBV creation fails. Fixes: f770950a4709 ("s390/pci: Migrate s390 IRQ logic to IRQ domain API") Cc: stable@vger.kernel.org Reviewed-by: Niklas Schnelle Signed-off-by: Tobias Schumacher Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit b4d2ce74ee1270abd89c39bdf26116902549b46c Author: Tobias Schumacher Date: Fri Oct 9 08:15:50 2026 +0200 s390/pci: Fix MSI directed-mode teardown IRQ bit count commit 1844913582fec337c54b54fdd3c92ce225930515 upstream. On s390 with directed interrupts enabled, zpci_msi_teardown_directed() frees the platform's maximum number of MSI bits (zdev->max_msi) instead of the actual allocated count (zdev->msi_nr_irqs). This corrupts the shared IRQ bitmap used by all PCI functions, causing lost interrupts and heap corruption. Fix zpci_msi_teardown_directed() to only free the actual allocated IRQ bit count. Fixes: f770950a4709 ("s390/pci: Migrate s390 IRQ logic to IRQ domain API") Cc: stable@vger.kernel.org Reviewed-by: Niklas Schnelle Signed-off-by: Tobias Schumacher Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 5259b258f234cca127651cd983ea879a7ad4ea8c Author: Tobias Schumacher Date: Fri Oct 9 08:15:48 2026 +0200 s390/pci: Fix double-free and NULL deref in zpci MSI domain cleanup commit 31c66bd273303590fe69fad370e72a12faa0bf76 upstream. zpci_remove_parent_msi_domain() dereferences zbus->msi_parent_domain unconditionally and does not clear it afterwards. zpci_bus_create_pci_bus() removes the domain when pci_create_root_bus() fails, then zpci_bus_release() removes it again on the last kref_put(), reading ->fwnode from the freed irq_domain and freeing it twice. If zpci_alloc_domain() or zpci_create_parent_msi_domain() fails, no domain is created at all; zbus is kzalloc'd, so the same release path dereferences NULL. Return early when there is no domain, and clear the pointer after removing one. Fixes: f770950a4709 ("s390/pci: Migrate s390 IRQ logic to IRQ domain API") Cc: stable@vger.kernel.org Reviewed-by: Niklas Schnelle Signed-off-by: Tobias Schumacher Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit a1fe31028ad6ddad4fa0ee086317fc1b00fbada1 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 9d9d62dfef3609f664c60f6fe61528a2e876a64b 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 85db2c35fd93bc6604e4d7abe4701d6587bc15a3 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 8db1a8614b4f8f3da11c568e2b5af4fe56eef360 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 51b21515bdac0a60efac142dbfa44481e4206f28 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 83798e46a01c3139273cddcc634e96dfee980c42 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 adf422b7587bff1c9069406ce7a6c5a1f0e70193 Author: Yibo Tan Date: Mon Sep 7 06:43:50 2026 +0800 media: ipu-bridge: Fix use-after-free in IVSC error path commit 3d42d1c82717f0853379b516a7fab54b636e09cc upstream. 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 Signed-off-by: Greg Kroah-Hartman commit a7962198ab367f732a8ced1682f2738d712ad473 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 ba097d24c56bc3c57a1173506c3c5a42d0f94988 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 544b575ba44d566cfd4f82e3d8faee5db01addf5 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 5e30e92df3a0fb3985f3686536065219c28dd65d 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 25d0baa6adb4a0b3f6889d42033ce8df3232bea7 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 f79a0195db1f2568fd82999fd814af071b2dbca7 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 3e0bb6b07a95f730a36f65d959708606ca0d78ce 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 5ee2e99021c5ec3e89aa6dc2fc1ad5ed46446523 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 fd7843365a9e73f6ee32c30487c21cb62b84c0a2 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 02b63c0227a3694b89133e3f17342a4ed083a348 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 465f3074762ad943370881d7b6f096e70d9a5a5a Author: Denis Benato Date: Tue Sep 15 17:26:07 2026 +0000 platform/x86: asus-wmi: fix use-after-free unregistering kbd_led led commit 639bc2254816b7c4e7a9801a7b3aa71bfa3f915c upstream. kbd_led_update_all() registers asus->kbd_led with devm_led_classdev_register() on the platform device, but kbd_led is embedded in struct asus_wmi, which asus_wmi_remove() frees at its end. The driver core calls .remove() before devres_release_all(), so the deferred devres release runs led_classdev_unregister() on memory that has already been freed. Whether that faults depends on whether the slab has been reused in between, which makes the crash on module unload intermittent and silently corrupts the led classdev state in the remaining runs. Unregister the led classdev explicitly in asus_wmi_led_exit(), after the led workqueue has been destroyed: kbd_led_work can then neither run nor be queued anymore, since asus_ref.asus is NULL too, so kbd_led_registered is stable and the classdev can be released while the memory embedding it is still alive. devm_led_classdev_unregister() also drops the devres entry, leaving nothing to run at unbind cleanup time; it warns when no devres entry exists, hence the kbd_led_registered check. Fixes: fac55d29581f ("platform/x86: asus-wmi: Add support for multiple kbd led handlers") Closes: https://lore.kernel.org/all/CAO84+x+P2_xyHP89+nGVSMV6bL+dy0P9=vyEEfZGnFhv0hBNWw@mail.gmail.com Reported-by: Hugo Baigue Tested-by: Hugo Baigue Cc: stable@vger.kernel.org Assisted-by: zcode:glm-5.3-flash Signed-off-by: Denis Benato Link: https://patch.msgid.link/20260915172608.14234-1-denis.benato@linux.dev Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit a3b57ce3e95d338a9a24eb760171aa16f742f008 Author: Fan Wu Date: Tue Sep 22 08:10:52 2026 +0000 PM: EM: Fix use-after-free of perf domain in netlink doit handlers commit f58dacfbadb7be7c7dbb2b95e9341ad56710849e upstream. The doit handlers dropped em_pd_list_mutex before dereferencing the perf domain, so a concurrent device unregister could free it while the reply was being built. Encode the reply from em_perf_domain_for_id() callbacks, which run under the mutex, and allocate the skb outside of it, like the dumpit path already does. This issue was found by an in-house static analysis tool. Fixes: 380ff27af25e ("PM: EM: Add dump to get-perf-domains in the EM YNL spec") Fixes: f2d2946eaa5c ("PM: EM: Implement em_nl_get_pd_table_doit()") Cc: All applicable Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260922081052.321581-1-fanwu01@zju.edu.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3c94478114384d97795029160ceb539ade38cc43 Author: Danish Khateeb Date: Tue Sep 29 07:49:34 2026 -0500 pps: generators: fix use-after-free when closing a removed device commit d19552611cb2eb6329826871565e5309bec2f288 upstream. 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: Greg Kroah-Hartman commit a0aaf59e7a86312c0272e36f19fb507f91405209 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 47eb0ec18f7bbd40cf1f1d261f15ef3c03e4c8d6 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 0b6d8b41af154b1137efb578afb8c8fc39d136aa Author: Deep Shah Date: Thu Oct 15 08:36:37 2026 +0000 RDMA/uverbs: Fix DMABUF use-after-free during ufile cleanup commit 2854f9025d4ef6c4566f71e52d7f496d9a0f5737 upstream. The DMABUF release can race with ufile cleanup. When the cleanup holds hw_destroy_rwsem for write, uverbs_uobject_release() fails its trylock and leaves the uobject on the ufile list, but the dma_buf is freed as soon as the release returns. The cleanup then destroys the uobject and uses the freed dma_buf: BUG: KASAN: slab-use-after-free in uverbs_dmabuf_fd_destroy_uobj+0x46/0x200 Read of size 8 at addr ff11000109cf14b0 by task repro/435 Call Trace: uverbs_dmabuf_fd_destroy_uobj+0x46/0x200 destroy_hw_fd_uobject+0x3f/0x50 uverbs_destroy_uobject+0xc5/0x380 __uverbs_cleanup_ufile+0x1a8/0x260 uverbs_destroy_ufile_hw+0x54/0x160 ib_uverbs_close+0x34/0x110 Allocated by task 435: dma_buf_export+0x1b5/0x530 ib_uverbs_handler_UVERBS_METHOD_DMABUF_ALLOC+0x223/0x3f0 Freed by task 436: kfree+0x301/0x530 dentry_kill+0x14c/0x560 __fput+0x23a/0x4a0 rdma_user_mmap_entry_remove() dereferences the same pointer. Protect the stored dma_buf pointer with a mutex and clear it before release returns. Use a shared revoke helper so uobject destruction and mmap entry removal both skip a cleared pointer. Hold a temporary uobject reference across uverbs_uobject_release() and the pointer update. Use a separate mutex because uobject destruction can free the mmap entry before release finishes. Map and unmap use attachment->dmabuf directly, so they do not need to take the new mutex while holding the reservation lock. Fixes: 0ac6f4056c4a ("RDMA/uverbs: Add DMABUF object type and operations") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Deep Shah Link: https://patch.msgid.link/20261015083637.200958-3-deepshah146@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 0b5282963734a51b6dad978ccfe0fa22c4d4fb17 Author: Tejun Heo Date: Thu Oct 15 07:18:05 2026 -1000 sched_ext: Fix use-after-free of a local reenq node left on an inactive cpu commit 43e1ef14a47257ebf7e3bb3ab9a6df9c6f817c5f upstream. A local DSQ reenq is queued on the rq through a per-sched node and run from deferred work. When the reenq is requested from dispatch, the work is a balance callback queued once dispatch is done. A cpu going down installs balance push early in its teardown, and queue_balance_callback() refuses new callbacks from then on. ops.dispatch() keeps running on that cpu until the rq goes offline after an RCU grace period, so a reenq it requests in that window may never run. The IMMED handling in dispatch_one() requests one the same way. A reenq requested from elsewhere for a cpu that is already offline goes through irq_work_queue_on(), which warns, and its work doesn't run until the cpu comes back. Either way the node stays on the rq's list. When the scheduler is freed, scx_sched_free_rcu_work() warns and frees the pcpu with the node still linked, and the list is walked again once the cpu comes back. An inactive cpu's local DSQ holds only tasks that are bound to it or are being moved off, so the reenq is pointless. Ignore reenqs of an inactive cpu's local DSQ. The test is lockless. The hotplug thread of a cpu going down runs on that cpu, and it marks the cpu inactive before it installs balance push. A dispatch on the cpu runs to completion before that thread can run there, so a dispatch that saw the cpu active has queued its callback by then. Requests from outside dispatch run from the wakeup path or through irq_work, which balance push doesn't affect. The grace period after the cpu goes inactive waits for any requester that saw it active, so that irq_work is queued while the cpu is online. Fixes: 238eba8c210d ("sched_ext: Use schedule_deferred_locked() in schedule_dsq_reenq()") Fixes: 76edc2761ab8 ("sched_ext: Use irq_work_queue_on() in schedule_deferred()") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Tested-by: Andrea Righi Signed-off-by: Greg Kroah-Hartman commit 72367dacb5c9d8bd486b2fcaf56b6d3086d57250 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 a3481ed0aea2fc41a6d892a586b6eb7a97662034 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 5653608781a660485d5e9be48a1d06025c4b97cf 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 75120454474be7bc62b77af12bd591a339be27e1 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 f6a3ccfc8d6f6d0fb8a20bfb49ede223f151b8e8 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 13610241843ccd928d83c6d51b5e044e4faf56c8 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 d78de077d45e8746d37e2af2e6d428da731ecf8a 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 8c5f62dd9a0b61e0082d419796e0743e820bd002 Author: Dairui Zhang Date: Tue Sep 29 22:30:00 2026 +0800 ksmbd: verify transform SessionId matches the decrypted header commit 798214e6fafcdcc29f5ba2661a473232b5e70cfb upstream. 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 Signed-off-by: Greg Kroah-Hartman commit e14b640498c4c5dae35ee1c605a76527f01fdc8b 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 896ecf714703f6801af43b6d3db4b824d8a12286 Author: Sung Byeongchan Date: Thu Oct 8 17:24:44 2026 +0900 ksmbd: validate AppInstanceId takeover target commit e0386cd6498b9c63f8c6d10b3e08670b92c0f3f1 upstream. AppInstanceId lookup currently selects the first open with the matching identifier. CREATE for an unrelated share or path can therefore force-close another session's open before authorization of the new target. Matching only the base path also conflates alternate data streams with the unnamed stream. MS-SMB2 requires the old open to match the share and path, belong to a different ClientGuid, and be closed only when the requester has GENERIC_READ access. Search all opens with the ID and match share, resolved path, stream, and the current connection's client GUID. Retain a share configuration reference in ksmbd_file and reuse its name instead of allocating a name for every open. This keeps matching safe during tree connection teardown and preserves name-based matching across configuration updates. Refresh the share reference on durable reconnect and restore the old reference if reopening fails. Serialize connection and share comparisons with durable disconnect/reconnect, and recheck the target before closing it. Keep the original ClientGuid for durable replay and lease checks. Check AppInstanceVersion before querying access, even when GENERIC_READ is absent, and before disconnected delete-on-close cleanup. Rejected CREATE must leave other durable opens untouched. Calculate maximal access on the matched open's referenced path so a rename cannot substitute another file's authorization. Require read access with the effective VFS credentials as well as the NT DACL before takeover. Access denial only skips takeover and leaves CREATE to its normal access checks. Restore filesystem credentials before returning a takeover error. Handle takeover before checking FILE_CREATE collisions, and re-resolve the path after closing the old open. This lets delete-on-close remove the old file before a new one is created. Include SYNCHRONIZE in the baseline maximal-access mask so read-only files report GENERIC_READ correctly. Fixes: 16c30649709d ("ksmbd: handle durable v2 app instance id") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Sung Byeongchan Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 98701475f3b358fda5cdc2a808e760bbdfaee0b9 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 74d241547a772e16c12a02b59e91807ac81d1a44 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 caee6342acfabb0dc3b2d85a8b830aab76e03a34 Author: Michail Andreas Michalopoulos Date: Wed Oct 21 13:54:00 2026 +0200 ksmbd: restore Kerberos logins with released ksmbd-tools commit 0fec4c24e1979032d7b7c159d9e5c45c7444e0f2 upstream. Commit a47634cd729b ("ksmbd: expire SMB sessions when Kerberos tickets expire") added a __u64 session_expiry field to struct ksmbd_spnego_authen_response, growing it from 156 to 168 bytes. ipc_validate_msg() requires the response to have exactly that size, so the 156-byte response of every released ksmbd-tools, up to 3.5.7, is dropped and Kerberos session setup fails with STATUS_LOGON_FAILURE. The other way round, kernels without that commit, including the stable trees, drop the 168-byte response of current ksmbd-tools master, and ksmbd-tools has no way to tell which layout a kernel expects. Pass the expiry in the reserved area of the embedded struct ksmbd_login_response instead. ksmbd-tools releases with that area (3.4.4 and later) allocate the response zeroed and never write to it, so they send an expiry of 0, which ksmbd already treats as no expiry. The response is 156 bytes again, so it works with those releases, and every kernel also accepts a response that sets the expiry. Use two __u32 halves, as the reserved area is only 4-byte aligned. Fixes: a47634cd729b ("ksmbd: expire SMB sessions when Kerberos tickets expire") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/CAO+rqLhpPvY0NLrAnZjFXz0gOXnA6zsXxK8xCgtA42XUkSsAeg@mail.gmail.com/ Assisted-by: LLM Signed-off-by: Michail Andreas Michalopoulos Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 0e64f89563164719ceb1aa33f2a8bfd6391fa340 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 1767a5e45dbf6a3b12105196dda4fb0ef80b9698 Author: Namjae Jeon Date: Sat Oct 17 02:06:25 2026 +0900 ksmbd: reclaim ended sessions on logoff and expiration commit 26534ef335e92b028eb58e44d98d46a0e26af0ec upstream. LOGOFF and previous-session replacement leave sessions Expired with a zero credential expiry. Ended sessions can retain their memory and connection slots when no further setup arrives on the owning connection. Unpublish a logged-off session while the request reference keeps its response signing and encryption keys alive. Remove its procfs entry before dropping the table reference so a reader cannot remove its own entry on the last put. Clear proc_entry after removal to avoid removing it twice. Reclaim ended sessions from the global table in the existing expiration worker before it acquires conn_list_lock. Only select Expired sessions with zero credential expiry and no references beyond the table reference. Keep sessions whose Kerberos credentials expired available for reauthentication. Unlink the session from its setup connection and all channel connections, so SMB2 sessions and sessions with only secondary SMB3 channels are covered. The session already holds connection references, and sessions_table_lock prevents concurrent channel removal. Queue sessions on a separate disposal list, leaving their hash nodes unhashed, and remove procfs entries and drop table references outside the locks. Keep the pending setup check before allocating a new session so abandoned InProgress sessions can release their slots even at the connection limit. Retain the timeout and reference checks and dispose of those sessions outside the locks. Leave ended Expired sessions to the expiration worker. Fixes: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Cc: stable@vger.kernel.org Reported-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 97d489f68b85a5b64496e01d4cb3c0e092aa817e Author: Namjae Jeon Date: Mon Sep 7 13:35:51 2026 +0900 ksmbd: prevent stale data from being written by SMB2 WRITE requests commit bc0e0f5ac1d7b044d403f859406b4b66d4b1ce9b upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 1f8945d2eb20a135b4e22e6fe2348a0191be208a Author: Namjae Jeon Date: Fri Oct 23 08:53:57 2026 +0900 ksmbd: prevent share root removal through empty paths commit 9fd1fcbbf84986a7bcf601a2b90540899069d263 upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 4f148586c9cb18ad47b5f41153139d0fefa596d3 Author: Namjae Jeon Date: Mon Oct 26 13:13:56 2026 +0900 ksmbd: prevent session binding in compound requests commit 19f8fd6b5ced33b02a083759e6901f9d6e8076df upstream. A failed multichannel binding can retain its target session on the work item so that the error response can be signed. Subsequent compound commands can then use that session together with a tree connection left over from an earlier command. Limit binding SESSION_SETUP requests to standalone messages during message validation, before smb2_sess_setup() can replace work->sess. Check both NextCommand and the current request offset to cover binding in the first, middle and last positions of a compound. The existing validation error path returns STATUS_INVALID_PARAMETER and stops processing the remaining commands. This intentionally limits support for compounded binding. It is not a protocol requirement that binding be standalone. Standalone binding and non-binding compounds retain their existing behavior, without changing session, tree or response encryption handling. Fixes: 4b706360ffb7 ("ksmbd: fix multichannel binding and enforce channel limit") Cc: stable@vger.kernel.org Reported-by: Zeng Adolph Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 4cdee894f9bcebe0093df90cf28dc732d38418da 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 94f8462fc9d5332bc54e91605003c17381e9171a Author: Namjae Jeon Date: Sat Oct 17 00:18:02 2026 +0900 ksmbd: limit sessions on each connection commit dc6aa1ba8b7fff8800ad9bf143f17d308e02ec68 upstream. The pending setup limit only counts InProgress sessions. A client can complete authentication repeatedly and retain an unbounded number of Valid sessions on one connection. Reserve a connection slot before allocating a session and retain a connection reference while authentication is in progress. The first SMB3 channel takes over that reservation; binding to another connection reserves one slot there. Reauthentication and authentication continuation reuse the existing reservation. Return slots on allocation or insertion failure, channel removal, and final session destruction. Accept max_sessions_per_connection in reserved startup-request space and default to 64 when older tools leave it zero. Keep the request size and existing field offsets unchanged. Expose the configured limit in procfs. The existing connection limits bound the aggregate number of sessions without a separate global session allocation limit. Fixes: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Cc: stable@vger.kernel.org Reported-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit ddbcb0fe1b4ae5fd2c85fba5be61af1a554fce3b 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 4b333aed69cfc2c8687b86b6a4364a0dffc16dd8 Author: Namjae Jeon Date: Fri Oct 16 23:17:58 2026 +0900 ksmbd: hold a connection reference for each session channel commit add8d7fb04efe564193df73581889c62fc0016f1 upstream. ksmbd_session_unregister() removes a session from the global and per- connection tables before dropping the table reference. A concurrent reference holder can keep the session and its channel list alive after those removals. Connection cleanup can no longer find the unpublished session to remove its channels. Since a channel only stores a raw conn pointer, the connection can be freed while another session reference holder is still accessing it, for example during SMB3.1.1 binding or a procfs read. Take a connection reference when registering a channel and release it on insertion failure, channel removal, or final session destruction. Keep the channels and signing keys until the session is destroyed so a response can still be signed after the session has been unregistered. Fixes: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Cc: stable@vger.kernel.org Reported-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit db30f8f330fc73304edfe595dc5a6f5e17ba97f2 Author: Ian Bridges Date: Tue Oct 27 10:21:35 2026 -0500 ksmbd: fix session reference leak on compounded SESSION_SETUP commit 03bd8f5279e490e15e0c0f0fa388ffbd2fbacd65 upstream. 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 Signed-off-by: Greg Kroah-Hartman commit b62ef8cfec9351662e42cbf7da2d743068699bba 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 d1e92aa651caa352261fb3b78460b7722357835c 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 828c02c65e2b0541f0cce403e336b978f92b6dfa 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 e0e394d7379558bd5eb4ac95a87a41e3ceb7bfb2 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 6789f0983f8e85ce3a5ed8c50fc05d613ead9c2c Author: Namjae Jeon Date: Sat Oct 17 21:43:37 2026 +0900 ksmbd: drain session procfs readers before dropping table references commit 1c087cf7d5386c708d8984b263280b42b3daada0 upstream. Session registration failure and connection cleanup can drop the table reference while the per-session procfs entry is still accessible. If a reader holds the last remaining reference, its final put calls proc_remove() from its own callback and waits for that callback to finish. Remove the procfs entry before dropping the table reference in the registration failure path. Queue sessions removed during connection cleanup and drain their procfs readers after releasing both session locks, then return their table references. Keep the global hash node unhashed while a session is queued so a concurrent unregister cannot drop the reference again. Previous-session replacement also destroys the file table before the session is finally freed. Detach the idr under the lock used by procfs file counters, and report zero files after it has been detached. This prevents a reader from accessing the idr during or after its destruction. Fixes: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Cc: stable@vger.kernel.org Reported-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit be67941493114d1145d16088938bf589e34f111b Author: Aamir Ahmed Date: Wed Sep 16 11:49:27 2026 +0100 ksmbd: deny access for an empty DACL instead of granting the request commit de0cffef897c1c232ed973f89928cd6c93d0b1e3 upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 4e4e8b38994a0b0fc23f00ca6698b469a41abe70 Author: Namjae Jeon Date: Fri Oct 16 23:17:36 2026 +0900 ksmbd: defer connection scavenging while session locks are busy commit b4bae7af1154089be87c7475218264fcbfd16d10 upstream. The expiration worker holds conn_list_lock for reading while checking for authenticated sessions. Without this change, the check can wait for conn->session_lock or sessions_table_lock. In destroy_previous_session(), the status updates after ksmbd_conn_wait_idle_sess() run with both session locks held for writing. Both the KSMBD_SESS_GOOD error path and the KSMBD_SESS_NEED_SETUP success path call ksmbd_all_conn_set_status(), which takes conn_list_lock for reading. A writer queued on conn_list_lock can block these new read acquisitions. The worker then waits for a session lock held by destroy_previous_session(), which waits behind the writer. The writer cannot proceed until the worker releases conn_list_lock. Try both session locks instead of waiting in the scavenging check. Keep the connection when either lock is busy and let the periodic worker retry later. Fixes: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Cc: stable@vger.kernel.org Reported-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d82d8a248f615f99575167a8b2310b5aaadbee19 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 ab5c9662b8802617e5c9aa5e29e58c8023e43a9b 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 bb0d418853658646657517450ea7018a88189aec 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 6170378712385dc329bf70ea1da6e9cd87b46f32 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 a1f4944f6f79bc4d9e44203a797d62b2b645d8f6 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 17f98aed6617b506f62ffd9da3123c9973dd67fa 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 1611ce4dc6cbace75f27db6a559af8d391a06118 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 16da5d271322e0947ecce0edc54daa248cf8101e Author: Mario Peter Date: Wed Oct 14 15:31:09 2026 +0200 driver core: take parent lock in async device attach commit 187a62f99da29b1a55602b0d401a783d8dc86161 upstream. 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: Greg Kroah-Hartman commit 6ad5071fbef6e65beb33c099e282dc89f0e2f716 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 c2c7c95e789e86420766c39f5cc4aaebe30c5524 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 444dd434b508e98bfe2e0f3ab04332faa2f9963f 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 b7bca38440a33bac784d0e60aba52dda78ed091b 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 6b850585b41a1d881062d9671cb6fb2f90bd49e7 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 2702ae318630787c640ec0d0403ffd9d95c43e9e 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 04bc5e44895eb83693e42b67b49bcb6707408fda 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 0cc691a899a43e8ecbddfe657198b3f6935122f0 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 c20b24907eb1b56fa1e1918698276a2a98fc6a2c 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 97fb3f1597cc8da7a957e1f908b4a4ece4f175d9 Author: Hengyu Liang Date: Fri Oct 9 23:46:16 2026 -0400 serial: core: fix TIOCSSERIAL and TIOCSERCONFIG on uninitialised ports [ Upstream commit e1f46a09df93650288babb23de6e34bff73e80e6 ] Commit 8ca59f7baee7 ("serial: fix ioctl hangup race") made uart_set_info() and uart_do_autoconfig() return -EIO when TTY_IO_ERROR is set, so that they do not run on a port that has been hung up. However, TTY_IO_ERROR is also set on a port that could not be started, for example because its type is unknown, and by uart_shutdown(), which both functions call. As of now, setserial cannot configure a port that the kernel did not detect, and an autoconfig that follows a port, irq or type change in the same setserial call fails on any port. The issue can be reproduced with setserial (busybox) on a port without a detected UART, for example ttyS3 of a QEMU guest: setserial /dev/ttyS3 uart 16550A setserial -g /dev/ttyS3 Before commit 8ca59f7baee7 ("serial: fix ioctl hangup race"), the result is: /dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3 After that commit, the result is: setserial: can't set serial info: Input/output error /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3 This patch will check tty_port_active() in these two functions instead. uart_hangup() clears it under the port mutex, and it stays set on an open port that could not be started. Fixes: 8ca59f7baee7 ("serial: fix ioctl hangup race") Cc: stable@kernel.org Signed-off-by: Hengyu Liang Tested-by: Johan Hovold Reviewed-by: Johan Hovold Link: https://patch.msgid.link/20261010034616.3915864-1-hengyul@cs.unc.edu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b48a7e8bbb0a15d89b32fd0085d44b7f3e70cc14 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 54a83cb2ac80d5e6433a34b15e0890402dad591a 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 70a197fa961f26ab85b51901882e34a3123a481d 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 8ca05d997cdac21afbc33c0882dd8d7609218477 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 f022984a4a1c18aa9c506790eb47da000dce95a7 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 e45356d83adce72fd99f57763eb3456c7c560857 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 31209411c4f98158b41508b7f90583e8cf5d6076 Author: Fredric Cover Date: Thu Oct 22 21:55:06 2026 +0000 smb: client: fix early procfs exposure race commit 7b1afb631395c958993cda4631002258ef4151ea upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 4bf4fb7f323402df1c57982365c8ac2498b89d10 Author: Zikang Gao <2715417602@qq.com> Date: Wed Oct 14 04:19:44 2026 -0400 smb: client: do not pass a NULL buf to is_oplock_break() commit 2225ab306575e424b3dad2ee1be2521c89249d15 upstream. 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 Signed-off-by: Greg Kroah-Hartman commit cb5303cfe9bc86237f84660994b503c1b9faffb0 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 625bbfa9c160ca9d4128acddb15fd7da3ea66c17 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 ef1a59804c07e2e17885cd6c723c4638489cf58a 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 57a474ce387bd68f77b470bba7c0ce10bdb62dfa 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 7f6a52f076d4ebbd91868b06e9546ada829cf101 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 6af7578840bde82e6cd5de3235502c116bcc196c 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 b8111914eb7cb1d269c1dec4a4958468ac7e17a4 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 5f4bd9eebdd2c79603ed74e25da7345bcf63345e Author: Aleksandr Nogikh Date: Mon Aug 17 14:09:49 2026 +0000 media: usbtv: fix null-pointer dereference on disconnect commit cb705f75d03e946a4514488beb9e3bac9bcdb2e6 upstream. 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: Greg Kroah-Hartman commit 5d17cf3d380d56018a5ae8ef03af8df12ed910e9 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 e282da1201f16ff75b95f85cc0b0c1de7ff59731 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 e10b88635c819aa411abbd4a30a337a71f6dfde4 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 be9fa57665efae4060d17ab21675c1c033d54a80 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 2a4b6ae380a9f5175f002c1921cf9cbc7ca536ba Author: Yongjun Gwon Date: Fri Oct 23 02:38:32 2026 +0900 ksmbd: serialize directory emptiness checks with readdir commit 7220980b2423d06a0604516129bfa4cec8a697ae upstream. 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 Signed-off-by: Greg Kroah-Hartman commit 57f36ae23e6b3b47fd785278d5e3735074536160 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 63700a2a8df0fafbed1b2aa747821219c1cda29e 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 10a58bf0107a02854584ed79281d05a84d62d900 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 d129cfc783b5ff091f5edcccf8129608ec50c000 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 11e9f0c8b30a7cf3ba0869ecea7bf784c3f81dab 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 8602ec8effb019d7db38d3c234d9d7305ee429a5 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 3c287de98388c3746d8b884de9fd8c3e83f41c04 Author: ck.chang Date: Wed Aug 5 17:24:09 2026 +0800 wifi: mt76: mt7925: fix reset panic caused by the WM2 rx irq mask commit c182bfe944eb275f7526cc326f81229b0e974a0c upstream. mt7925_irq_map sets wm2_complete_mask, but mt7925_dma_layout has no tx done ring, so the MT_RXQ_MCU_WA queue and its NAPI are never set up. On a chip reset, mt7925e_mac_reset() calls napi_disable() on that NAPI and crashes: BUG: kernel NULL pointer dereference, address: 0000000000000a40 Workqueue: mt76 mt7925_mac_reset_work [mt7925_common] RIP: 0010:mutex_lock+0x1c/0x50 Call Trace: napi_disable+0x1d/0x50 mt7925e_mac_reset+0x327/0x420 [mt7925e] mt7925_mac_reset_work+0x9a/0x1a0 [mt7925_common] Remove the WM2 mask from mt7925_irq_map and from MT7925_INT_RX_DONE_ALL. Fixes: c4edf9e3e0e5 ("wifi: mt76: mt7925: replace shared rx irq masks with per-chip definitions") Signed-off-by: ck.chang Link: https://patch.msgid.link/20260805092409.1489401-1-eason.lai@mediatek.com Signed-off-by: Felix Fietkau Cc: Chris Marshall Signed-off-by: Greg Kroah-Hartman commit 934dd36b19d7a4d05fa5b3131a5db1598fcc9bdf Author: Radek Podgorny Date: Wed Sep 9 00:29:36 2026 +0200 Bluetooth: forget a peer's RPA once it advertises its identity address commit 3889a5fcd091d2154861c19e9c581f9f04aabd0e upstream. hci_connect_le() dials the RPA cached in the peer's IRK whenever one is set, on the assumption that a peer holding an IRK is on air with a resolvable private address. A peer that stops using privacy breaks that assumption: it advertises its identity address, the cached RPA keeps the value it had before the change, and the host aims at an address the peer has abandoned. Nothing clears the cache. hci_find_irk_by_rpa() refreshes irk->rpa each time an advertisement resolves, so it tracks rotation, but a peer that stops sending RPAs stops producing the reports that would update it, and the stale address then survives until the adapter is powered off. On the path that creates the connection object this is currently masked: __hci_conn_add() resolves the cached RPA back to the identity address, so that is what goes on air. It is not masked on the reuse branch, which copies the swapped address straight into an existing conn->dst, and the next patch removes the conversion for the case where the controller cannot translate an identity address, so the stale RPA would be dialled there too. Clear the cached RPA when the peer is seen on its identity address. hci_find_irk_by_addr() only matches public and static random addresses, so an unresolved RPA belonging to some other device cannot reach this path. Assisted-by: Claude:claude-opus-5 Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 22c82f33ff0b68d37041adf1dea5533a5863cd31 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 2d9f3c97c407a5c2f7f65245fb82500de3183842 Author: Biju Das Date: Mon Sep 14 17:50:23 2026 +0100 clk: renesas: r9a08g046: Propagate clk rate for ETH TX mux clocks commit e018c27e6052ec58de3c1e7b340521ef162a8b81 upstream. Add CLK_SET_RATE_PARENT flag to the sel_eth0_tx and sel_eth1_tx mux clocks so that rate-setting requests on these clocks propagate up to their parent clocks. Without this flag, a clk_set_rate() call on the downstream GBETH clocks has no effect on the actual PLL/divider chain feeding the TX clock, leaving the requested rate unapplied. Fixes: d55a0dfec40b ("clk: renesas: r9a08g046: Add GBETH clocks and resets") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260914165026.184612-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 026aa32c00b0b3ea849d0ae98313274c9d3c7e21 Author: Christian Brauner Date: Wed Oct 28 12:55:31 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 Signed-off-by: Greg Kroah-Hartman commit 0e8cff375cd6fd12064547abaa868c8bc856f88c Author: Christian Brauner Date: Wed Oct 28 12:55:30 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 Signed-off-by: Greg Kroah-Hartman commit ababac26fb49681f52fface992269005d72572c9 Author: Christian Brauner Date: Wed Oct 28 14:35:25 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 Signed-off-by: Greg Kroah-Hartman commit f293f53f59c10e6cf0e18c6096f6677a518613e5 Author: Jens Axboe Date: Thu Oct 15 16:38:45 2026 -0600 io_uring/timeout: don't lose a cancel as io-wq arms a timeout [ Upstream commit 89f193dc3ef462059387e9691bf6af4b1808379a ] An IORING_OP_TIMEOUT run by io-wq, because of IOSQE_ASYNC, has the same problem as poll, futex and waitid. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain, while the worker then adds the request and starts the timer: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() adds the request to ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again, and the timeout runs its course. At ring exit, io_uring_try_cancel_requests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout. Look at the flag under ->timeout_lock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list. Fixes: ce35a47a3a02 ("io_uring: add IOSQE_ASYNC") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c5e3cfa344dd7d58d63f0b51caf62d91b3394e66 Author: Jens Axboe Date: Thu Oct 15 14:25:00 2026 -0600 io_uring/timeout: don't flush with the sequence behind the last flush [ Upstream commit 85f85d573ffa7772e1ad4504d0cec5113a5c5cf1 ] io_flush_timeouts() measures the events since the last flush as the distance of the current sequence from ->cq_last_tm_flush. A fired timeout bumps ->cq_timeouts before its CQE is posted, so until it is the sequence can be behind the last flush, and the distance wraps: last flush: seq 100, cq_last_tm_flush = 100 Y: IORING_OP_TIMEOUT, off 50, target_seq 150 pure timeout A fires, cq_timeouts = 1 task_work posts A's CQE, cached_cq_tail = 101 pure timeout B fires before the flush, cq_timeouts = 2 io_flush_timeouts(): seq = 99, events_got = 0xffffffff Y, and every sequence timeout behind it, is ended with -ETIME although no event happened. Two timeouts expiring close together is all it takes, a completion with IOSQE_CQE_SKIP_SUCCESS after a single one does it too. Nothing but those in flight CQEs separates the two, so count from the last flush when the sequence is behind it, as io_timeout() does. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 484a60bf6ae49a2c9cce0486f629125f4fc7b843 Author: Jens Axboe Date: Thu Oct 15 14:18:22 2026 -0600 io_uring/timeout: don't put a sequence target behind the last flush [ Upstream commit fdfce905a58edea053ee7b68b5bd4348dd1b36e0 ] io_timeout_fn() and io_kill_timeout() bump ->cq_timeouts when a timeout fires, but its CQE is only posted later from task_work. Until then the sequence io_timeout() computes is one below the last flush per fired timeout. Now that ->cq_last_tm_flush is kept while sequence timeouts are pending, a timeout armed in that window with a small offset gets a target behind the base. Its distance from the base wraps, and it's never completed by events, only by its timer. With DEFER_TASKRUN that window is as wide as the application makes it, as submission runs before the local task_work. Nothing but those in flight CQEs separates the two, so use the last flush as the base for the target when the sequence is behind it. Fixes: c6c0b3eba88c ("io_uring/timeout: don't skip over reached sequences") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4db3e79955e8027848a7abf64eac420bdeb12aba Author: Josef Bacik Date: Thu Oct 15 19:31:07 2026 +0000 io_uring: look up the file before queueing to io-wq [ Upstream commit 98bc044d5a5374f8d3605fe55a8e2df6d6fc3f82 ] io_prep_async_work() decides by the file of a request what kind of work it is for io-wq. I/O on regular files and block devices is bounded work, limited to min(SQ entries, 4 * CPUs) workers, for anything else that may block indefinitely the limit is RLIMIT_NPROC. Writes to a regular file are hashed by the inode, so that they are run one after the other instead of having a bunch of workers fight for the inode lock. Since the file is only assigned when a request is issued, a request that is queued without an attempt to issue it, REQ_F_FORCE_ASYNC, doesn't have one at that point. io_prep_async_work() takes that for "not a regular file or block device": - Reads and writes end up as unbound work. 32 reads with IOSQE_ASYNC from a slow block device on a ring with 4 SQ entries get 32 workers, not 4. - Writes aren't hashed. Four buffered writes to one file get four workers, three of which do nothing but wait for the lock. The late assignment is for the benefit of links, where a request may use a fixed file that one of its predecessors installs. By the time a request gets to io_queue_iowq() these are done, it is as good as issued. Assign the file there. io_assign_file() moves up and is forced inline. With a third caller the compiler may stop inlining it, and every request that is issued would pay for a call. IORING_OP_SPLICE is left as it is, unbound and not hashed. The file of the request is where it writes to, which says nothing about how long it takes: a splice from an empty pipe or a socket into a regular file waits for its input. As bounded work, four of these on a ring with 4 SQ entries keep all other bounded work of the task from running, and as hashed work one of them blocks all writes to that file. REQ_F_FORCE_ASYNC is not only set for IOSQE_ASYNC. What changes, and brings back what was the case before the file assignment was deferred: - Requests with IOSQE_ASYNC or IOSQE_IO_DRAIN, and all requests that are submitted while a drain is active: reads and writes on regular files and block devices count against the limit for bounded workers, including the one set with IORING_REGISTER_IOWQ_MAX_WORKERS, so fewer of them run at the same time. - Of these, writes to one regular file are run one at a time, unless they are O_DIRECT and the filesystem has FOP_DIO_PARALLEL_WRITE. - IORING_OP_FALLOCATE and IORING_OP_FTRUNCATE, which always go to io-wq, are run one at a time per file, and in turn with these writes. - The descriptor or the fixed file slot is looked up when the request is queued, not when a worker gets around to it, so closing or replacing it in between no longer has an effect on the request. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-43-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a49dbba641210823cb08904032ef2bc7ae9b930f Author: Josef Bacik Date: Thu Oct 15 19:31:06 2026 +0000 io_uring/timeout: don't end a linked timeout with 1 [ Upstream commit c74193430febdd120e35936dda3e5aeec3a54405 ] A linked timeout that fires cancels the request it is linked to, and completes with -ETIME if that worked out: ret = io_try_cancel(req->tctx, &cd, 0); ... io_req_set_res(req, ret ?: -ETIME, 0); io_try_cancel() returns 0 or an error, except for requests that are parked on ->futex_list or ->waitid_list. io_futex_cancel() and io_waitid_cancel() return the number of requests that they have cancelled, and io_try_cancel() hands it on. So the linked timeout of an IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV or IORING_OP_WAITID that it has cancelled completes with 1, each time. The waitid test of liburing checks for that 1, and has to be changed to expect -ETIME, which is what the linked timeout of any other request completes with. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-42-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit efbe2c7f664873ca624503fd4ef1c9119c4a5ba7 Author: Josef Bacik Date: Thu Oct 15 19:31:05 2026 +0000 io_uring/timeout: no ABS update of multishot timeouts [ Upstream commit b088ae34d4da730dc647261b893a6eb622fe5e1f ] IORING_TIMEOUT_MULTISHOT can't be combined with IORING_TIMEOUT_ABS, prep rejects that, as the request is armed again with the same value each time it fires. IORING_TIMEOUT_UPDATE doesn't check and takes an absolute time for a multishot timeout. The first expiry is as asked for, but io_timeout_complete() then arms the timer with ->mode of the original request, i.e. it uses the absolute time as the interval. With CLOCK_MONOTONIC the next expiry is an uptime away, with CLOCK_REALTIME more than fifty years. Fail such an update with -EINVAL, and do so before the timeout is touched. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-41-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8d8c471fd3891d1adb5b108604b04e6e935b4039 Author: Josef Bacik Date: Thu Oct 15 19:31:04 2026 +0000 io_uring/net: don't retry recv on uncommitted buffers [ Upstream commit 8444de681a179e41a4eb92d5bbe770a0677074a6 ] Commit 41b70df5b38b ("io_uring/net: commit partial buffers on retry") commits ring provided buffers when a receive is going to be retried after a partial transfer, so that another request using the same buffer group can't be handed the memory the first one keeps receiving into. It commits the number of bytes received so far. That does the job for a single buffer which is consumed as a whole, but the request hangs on to all it has mapped: - For a buffer ring with IOU_PBUF_RING_INC only these bytes are consumed. The rest of the buffer stays at the head of the ring. - For a bundle only the buffers which hold these bytes are consumed, the others that were peeked stay in the ring. In both cases the next receive with that buffer group gets memory that the retried request is still going to write to, and whoever comes last overwrites the data of the other. What the retry fills isn't committed at all, as the buffer list isn't known any more at that point. So the kernel hands it out again later on, while the CQE tells the application that it was used, and for an incremental buffer that it is done with. The remainder can't be committed in advance: if the request ends up receiving less, there is no way to tell the application that more was consumed than the CQE accounts for. Complete the request with what it has got instead of retrying it. MSG_WAITALL is no longer honoured for receives into incremental buffers or multi buffer bundles, they can return a short count, with the request marked as failed like for other short MSG_WAITALL transfers. Fixes: 41b70df5b38b ("io_uring/net: commit partial buffers on retry") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-40-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e98168889a21d35f2efa78ad45a1a0a09825935e Author: Josef Bacik Date: Thu Oct 15 19:31:03 2026 +0000 io_uring: don't pass restart error codes to userspace [ Upstream commit e1a64bc64897f4c2fe460922c345f2ed8f889b5f ] -ERESTARTSYS and friends are instructions for the system call exit code, which either restarts the call or turns them into -EINTR. They are not supposed to be seen by applications. A request isn't a system call, nobody looks at what it returns before that is put into a CQE. The read/write and the networking opcodes convert these codes to -EINTR by hand. The others don't. An io-wq worker that is blocked in the open of a FIFO, a tty or some other device, or in a splice from an empty pipe, and that gets interrupted because the request is cancelled, completes it with -512: IORING_OP_OPENAT, IOSQE_ASYNC // FIFO without a writer IORING_OP_ASYNC_CANCEL // -EALREADY, worker is signalled CQE of the open: res == -512 There are more candidates, like whatever a file system or driver returns from ->flush(), ->fsync(), ->fallocate() or ->uring_cmd(), or breaking a lease or delegation. Take care of it in io_issue_sqe(), which all of them go through. The helper is moved from rw.c as is. The cost is a compare and a branch that is not taken per request. Fixes: 15b71abe7b52 ("io_uring: add support for IORING_OP_OPENAT") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-39-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 56f0c2b9f8f799ff69dae284d860076974359ef3 Author: Josef Bacik Date: Thu Oct 15 19:31:02 2026 +0000 io_uring/openclose: keep the lock in io_pipe_fixed() [ Upstream commit a3d7ee11289f657aa9af826d8f0844221292a27a ] io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots. If the request is run by io-wq the lock really is dropped in between, and the slots are visible to everybody else. By the time the error path gets to them, they may have been closed and reused, by IORING_OP_CLOSE and a direct open or accept, or by IORING_REGISTER_FILES_UPDATE. Then a file is removed from the table that has nothing to do with the failed request. Do the copy with the lock held. Faulting in user memory under ->uring_lock is fine, the registration paths do it all the time. Fixes: 53db8a71ecb4 ("io_uring: add support for IORING_OP_PIPE") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-38-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2e3a64edeb79372f20b7001e345a867510fc708c Author: Josef Bacik Date: Thu Oct 15 19:31:01 2026 +0000 io_uring/sqpoll: let the thread sleep on disabled rings [ Upstream commit d492dcbb3b81c1c2d0aabef41fa1307093f3a556 ] __io_sq_thread() doesn't submit anything as long as the ring has IORING_SETUP_R_DISABLED set. The check that keeps the SQPOLL thread from going to sleep while the SQ ring holds entries doesn't know about that. If an application fills in SQEs first and enables the ring later, the thread finds that there is work each time it is about to sleep, goes around, doesn't submit it, and so on. It uses up a CPU until the ring gets enabled. Entries in the SQ ring of a disabled ring are no reason to stay awake. io_register_enable_rings() clears the flag and then wakes the thread, and the flag is looked at after prepare_to_wait(), so the thread can't miss that. Fixes: 0298ef969a11 ("io_uring: clean R_DISABLED startup mess") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-37-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1989bc6b6657538446dbbc2c4787b689c1d47ed9 Author: Josef Bacik Date: Thu Oct 15 19:31:00 2026 +0000 io_uring/kbuf: handle index wrap in last buffer check [ Upstream commit 6e773b5161506a4d0e739eb3aa4667d28f20219c ] io_ring_buffer_select() flags the request with REQ_F_BL_EMPTY if it takes the last buffer of the ring. Head and tail are 16-bit counters, but "head + 1" is computed as an int. If head is 65535 and tail has wrapped to 0, that compares 65536 to 0 and the flag isn't set. A bundle receive relies on the flag to tell that there is no point in trying to get more data. Without it, it goes for another round, 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: c3f9109dbc9e ("io_uring/kbuf: flag request if buffer pool is empty after buffer pick") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-36-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3affc16f42419f4387174ffc9a5b43198d9b9d73 Author: Josef Bacik Date: Thu Oct 15 19:30:59 2026 +0000 io_uring/zcrx: fix buffer offsets in areas above 4GB [ Upstream commit ab4536bf2e5617b04f2d9396f06393c7bbfb071d ] io_zcrx_queue_cqe() computes the offset of the buffer in its area from net_iov_idx(), which is an unsigned int, so the shift is done in 32 bits and only the result is widened to the u64 that goes into the CQE. An area can be up to 1TB in size. For every niov beyond the first 4GB the CQE points the application at a buffer 4GB, or a multiple of that, below the one which has the data. It reads the wrong data, and then returns a buffer it doesn't own via the refill queue while the real one is never given back. Fixes: 11ed914bbf94 ("io_uring/zcrx: add io_recvzc request") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-35-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit be062d346246cee17f2a3b8e981ddc009b24d876 Author: Josef Bacik Date: Thu Oct 15 19:30:58 2026 +0000 io_uring/napi: don't busy poll past an expired timeout [ Upstream commit 21ed976c12f6b77d7ea028a4fe9a08e69a56179f ] __io_napi_busy_loop() caps the busy poll time to what is left until the timeout of the wait. The difference is negative if the timeout has passed already, which is what an application gets if it uses IORING_ENTER_ABS_TIMER with a time that isn't in the future any more. The min_t(u64, ...) turns that into a huge value, so the cap has no effect and the wait, which should return right away, spins for the full busy poll time first. Fixes: d5cce407e4f5 ("io_uring/napi: postpone napi timeout adjustment") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-34-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ee771a45df5cc122da4926a949570fd4ca31d05b Author: Josef Bacik Date: Thu Oct 15 19:30:57 2026 +0000 io_uring/napi: make stale entries time out after 60s [ Upstream commit 9c151648780d89e5446e5f89f3fa2e416c3bb911 ] With dynamic tracking a NAPI id that hasn't been seen for a minute is meant to be dropped from the list the ring busy polls. The timeout is added to jiffies, but it is defined as 60 * SEC_CONVERSION, and SEC_CONVERSION isn't the number of jiffies in a second. It is the internal factor of __timespec64_to_jiffies(), HZ scaled up by SEC_JIFFIE_SC bits. For HZ=1000 that is 1000 << 22, which puts the timeout at about eight years. On 32-bit the multiplication overflows. So entries are never removed, and every id that a socket of the ring ever had keeps being polled on each wait. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-33-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 67f3cb72d0b647c1540aecdd59e4b226d4f4ab4b Author: Josef Bacik Date: Thu Oct 15 19:30:56 2026 +0000 io_uring/wait: no early -ETIME if min_wait finds work [ Upstream commit 83cce67298ab1f4d2e9205a49f56975475cdb154 ] When the min wait time is over and there is work to run, which for DEFER_TASKRUN includes task_work that was queued lazily and didn't wake the waiter, io_cqring_min_timer_wakeup() ends the wait via io_cqring_timer_wakeup(). That flags it as timed out. io_cqring_wait() runs the work, leaves the loop, and returns 0 if the CQ ring holds something. Running task_work doesn't have to result in a CQE, though. A poll wake up can turn out to be spurious, for instance if somebody else has read the data by the time the request is retried. The application then gets -ETIME once the min wait time has passed, no matter how far away the timeout it asked for is. Wake the task without declaring a timeout. From now on a single CQE satisfies the wait, like in the case where the timer is switched over to the normal timeout. If running the work doesn't post one, the loop in io_cqring_wait() goes back to sleep with the normal timeout. Fixes: 1100c4a2656d ("io_uring: add support for batch wait timeout") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-32-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit efe5d500ad36d58fa61025330fee2452f9df7e01 Author: Josef Bacik Date: Thu Oct 15 19:30:55 2026 +0000 io_uring/timeout: use the right clock for ABS updates [ Upstream commit dad82eb1805d76c555224e4030319e3844642b64 ] io_parse_user_time() converts an absolute time from the time namespace of the caller to the host's view, for the clock given by the flags. The flags of IORING_TIMEOUT_UPDATE and IORING_LINK_TIMEOUT_UPDATE can't name a clock, the updated timer keeps running on the clock the timeout was set up with. So the time is always converted as if it was CLOCK_MONOTONIC. In a time namespace with a monotonic offset, that moves the new expiry of a CLOCK_REALTIME timeout by that offset, although the clock isn't affected by time namespaces at all, and the one of a CLOCK_BOOTTIME timeout by the difference between the two offsets. Do the conversion when the timeout has been looked up and its clock is known. The update is run by the submitter, its SQPOLL thread or one of its io-wq workers, all of which share the time namespace. Fixes: 9cc6bac1bebf ("io_uring/timeout: honour caller's time namespace for IORING_TIMEOUT_ABS") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-31-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8f7fb6e535f34d47729e1b358f38e7b266854205 Author: Josef Bacik Date: Thu Oct 15 19:30:54 2026 +0000 io_uring/timeout: keep repeat count on multishot update [ Upstream commit 3dc2a32cd356ee382aa4a8c7d844c53b2c0ad83b ] IORING_TIMEOUT_UPDATE clears ->off of the timeout it updates, to turn a timeout that waits for a number of completions into a pure one. For a multishot timeout ->off isn't a sequence though, it tells whether the number of repeats is limited: io_timeout_finish() only looks at ->repeats if ->off is set. A multishot timeout that was set up to fire N times hence fires forever once its interval has been updated. Leave ->off alone for those, they are never treated as sequence timeouts anyway. Fixes: ea97f6c8558e ("io_uring: add support for multishot timeouts") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-30-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8740aae303e6973aaaf482ba9c53ba6c61cd03ad Author: Josef Bacik Date: Thu Oct 15 19:30:53 2026 +0000 io_uring/timeout: don't skip over reached sequences [ Upstream commit c6c0b3eba88c3b13ca11ea112404982e86d58f7a ] io_flush_timeouts() copes with the wrap of the CQ sequence by looking at the distance from ->cq_last_tm_flush. That relies on the target of each pending timeout being at or ahead of the last flush. io_timeout() breaks that. It sets ->cq_last_tm_flush to the current sequence, on the assumption that nothing has been posted since the last flush. That isn't true. A multishot request posts its CQEs right when it is issued or retried, but they are committed, and the timeouts flushed, at the end of the submission or task_work run: X: IORING_OP_TIMEOUT, off == 1 target_seq == N + 1 io_submit_sqes() multishot recv, posts two CQEs sequence == N + 2 Y: IORING_OP_TIMEOUT, off == 100 ->cq_last_tm_flush = N + 2 io_flush_timeouts() X: events_needed = N + 1 - (N + 2) // 0xffffffff events_got = 0 // not yet X isn't completed although the completions it was waiting for have happened, only its timer can end it now. And as the list is sorted and the walk ends at the first timeout that isn't due, it gets in the way of the ones behind it. The insertion sort has the same problem, it measures the distance of the pending targets from the current sequence. ->cq_last_tm_flush only needs to be brought up to date if no timeout is waiting for a sequence, as io_flush_timeouts() isn't called before the first one is set up. Otherwise it is current enough. Timeouts with a sequence come first in the list, so looking at the first entry will do. Use the last flush as the base for the insertion sort as well. Fixes: f010505b78a4 ("io_uring: flush timeouts that should already have expired") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-29-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7b29df54ab00e63551e9a762b51b0c1b1f50b09d Author: Josef Bacik Date: Thu Oct 15 19:30:52 2026 +0000 io_uring/fdinfo: fix CQE dump of CQE32 rings Commit e4507a62c247081fffe299622c04c6f7c3d98e92 upstream. Since the CQ ring dump was changed to deal with IORING_SETUP_CQE_MIXED, a 32b CQE is taken to occupy two entries of the ring. That is how it works for mixed rings. With IORING_SETUP_CQE32 each entry has twice the size: head and tail count 32b CQEs, and entry n is found at cqes[n << 1]. For such rings the dump reads cqes[n], and skips every other entry. It shows half of the pending CQEs at best, and what it shows is taken from the wrong place unless the head happens to be at the start of the ring. The extra data of the last entry isn't shown at all, as the check that keeps the dump of a mixed ring from reading beyond the array is applied to these rings as well. [ 7.2: without the last-slot check, which 7.2 does not have ] Fixes: 82ceb7fcc5ff ("io_uring/fdinfo: handle mixed sized CQEs") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-28-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Co-Authored-By: Claude Fable 5.1 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39ce48e9b495e7a665e95d194b0fd19a5585a41c Author: Josef Bacik Date: Thu Oct 15 19:30:51 2026 +0000 io_uring/register: keep 128b SQEs intact on resize [ Upstream commit 0feb5bcd2d4261d656729892aef4d643461ea5ac ] On a ring with IORING_SETUP_SQE_MIXED a 128b SQE takes two entries that have to be contiguous in memory, io_init_req() fails it with -EINVAL if it starts on the last entry of the SQ ring. The entry a pending SQE ends up in after IORING_REGISTER_RESIZE_RINGS depends on the size of the new ring, and nothing takes care of that. With four entries instead of eight, a 128b SQE which was fine in entries 3 and 4 is split up between entry 3 and entry 0. The resize succeeds, and the request fails later on. If the ring has an SQ array, the second half is also taken from the wrong place unless the array happens to map the following index to the following entry. The submission side doesn't look at the array for the second half. Do what is done for 32b CQEs on IORING_SETUP_CQE_MIXED rings: fail the resize with -EOVERFLOW if a 128b SQE would wrap. And copy the second half from where it is. Fixes: 1cba30bf9fdd ("io_uring: add support for IORING_SETUP_SQE_MIXED") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-27-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6e979098da0ef396bb69d4d66b17fc48897fd798 Author: Josef Bacik Date: Thu Oct 15 19:30:50 2026 +0000 io_uring/register: handle index wrap when resizing [ Upstream commit e8dee8d5498c710a22a84076d8ecb661627032b4 ] The ring heads and tails are free running 32-bit counters. io_register_resize_rings() takes that into account when it checks whether the pending entries fit into the new rings, but then copies them with for (i = old_head; i < tail; i++) If the tail has wrapped and the head hasn't, that copies nothing. The new rings get the old head and tail, so the application finds whatever is in the freshly allocated memory, zeroes, in place of the CQEs it hasn't reaped yet, or the kernel in place of the SQEs that have not been submitted yet. A ring that completes a million requests per second gets there after little more than an hour. Loop until the tail is reached, the number of iterations has been bounded by the size of the new ring at that point. Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-26-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 933a6d48e216805caa2c05756d6e0956a78e30f1 Author: Josef Bacik Date: Thu Oct 15 19:30:49 2026 +0000 io_uring/register: don't wrap 32b CQEs when resizing [ Upstream commit 0edf1930b8ed3c398d3cbdbafd8f72dbd1a3d9e4 ] On an IORING_SETUP_CQE_MIXED ring, a 32b CQE uses two contiguous CQ entries and is never allowed to wrap the end of the ring. When posting, io_cqe_cache_refill() inserts a dummy IORING_CQE_F_SKIP entry if only one entry is left before the ring wraps, and the application relies on that to read a 32b CQE as one contiguous 32 byte slot. io_register_resize_rings() copies pending CQEs to the new ring one 16b entry at a time, placing entry i at i & (new_entries - 1). When the CQ ring is shrunk, a pending 32b CQE that was contiguous in the old ring can land with its first half on the last entry of the new ring and its second half on entry 0. For example, with 8 old entries, 4 new entries and a 32b CQE at index 3, the halves end up at entries 3 and 0. The application then reads the extra data of that CQE from past the end of the CQ array, and the CQE content it sees is wrong. This was found by code inspection and has not been reproduced. Fix by failing the resize with -EOVERFLOW if a pending 32b CQE would wrap the new ring, the same way the resize fails when the pending CQEs don't fit. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-25-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a84216f825816cf07e618de1f86d667ceeec49f4 Author: Josef Bacik Date: Thu Oct 15 19:30:48 2026 +0000 io_uring: don't split 128b SQEs at the SQPOLL cap [ Upstream commit 79956bb39b4d372eb146955ea159ecb6fba37f5b ] If an SQPOLL thread serves more than one ring, __io_sq_thread() submits no more than IORING_SQPOLL_CAP_ENTRIES_VALUE entries per ring and round, for fairness. On a ring with IORING_SETUP_SQE_MIXED the cap may fall between the two entries of a 128b SQE. io_init_req() finds that just one entry is left of what it was asked to submit and fails the request with -EINVAL, although the second entry is sitting in the SQ ring. In the next round the second entry is taken for an SQE of its own, so on top of the failed request the application gets whatever its payload amounts to when it is read as an SQE. The application has done nothing wrong, and it can't know where the cap is going to be applied. For SQPOLL, let the request have its second entry if the SQ ring holds it, in excess of the number of entries that were to be submitted. Fixes: 1cba30bf9fdd ("io_uring: add support for IORING_SETUP_SQE_MIXED") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-24-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a74e890ddfb271da554f8f9d898e53c9046d8099 Author: Josef Bacik Date: Thu Oct 15 19:30:47 2026 +0000 io_uring: drop the CQE cache if a refill fails [ Upstream commit 78f9c9cffef02a290b6e97672aaa9c75df0d21da ] ->cqe_cached and ->cqe_sentinel delimit the CQ entries which can be handed out without looking at the ring. io_get_cqe_overflow() only calls io_cqe_cache_refill() if that range is too small. Without IORING_SETUP_CQE_MIXED too small means empty. With it, a 32b CQE needs two entries, and one may be left. If the refill then fails, the entry stays in the cache, and the next 16b CQE gets it without any checks. That CQE overtakes the 32b one, which went to the overflow list. The test for IO_CHECK_CQ_OVERFLOW_BIT, which is there to prevent that, is part of the refill: CQ ring with 4 entries, head == 0 16b CQE, 32b CQE tail == 3, one entry cached 32b CQE no room, the CQE overflows 16b CQE written to entry 3, ahead of the 32b CQE Forget about the rest of the cache when it is refilled. Fixes: e26dca67fde1 ("io_uring: add support for IORING_SETUP_CQE_MIXED") Reported-by: Leonid Ovchinnikov Closes: https://lore.kernel.org/io-uring/CAECZYD5OMD9vMTzjteFMMP40Dn+SWKj9SFj=43U6uO3XMnxJbw@mail.gmail.com/ Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-23-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3b7aadb9a5a18dfd0c309933cf9ae368ce236941 Author: Josef Bacik Date: Thu Oct 15 19:30:46 2026 +0000 io_uring/futex: allocate private hash before waiting [ Upstream commit 3eff68bce25584cded3fb6ec033ff9a1c9913d04 ] The futex code relies on there being no private futex waiters by the time the first private hash of a mm is installed: __futex_pivot_hash() moves the waiters from the previous private hash to the new one, but it does not look for them in the global hash which is used as long as there is no private hash. That is why every clone(CLONE_VM) allocates it up front: a task which is alone in its mm cannot block in futex_wait() and create a thread or invoke prctl(PR_FUTEX_HASH) at the same time. IORING_OP_FUTEX_WAIT and IORING_OP_FUTEX_WAITV do not block the submitter though: io_uring_enter() io_futex_wait() futex_wait_setup() // no private hash: queued in the global hash pthread_create() futex_hash_allocate_default() __futex_pivot_hash() // first private hash, nothing is moved futex(FUTEX_WAKE_PRIVATE) futex_hash() // private hash: no waiter The wakeup is lost and the request only completes when it is cancelled. prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS, n) instead of pthread_create() has the same effect. Allocate the default private hash when a wait request on a private futex is prepared, which happens in the context of the submitter. This is a RCU protected pointer check once the hash exists. A failure to allocate it fails the request with -ENOMEM. Fixes: 80367ad01d93 ("futex: Add basic infrastructure for local task local hash") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-22-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2c92f10b4a7c1c471e12f36702ce38afe44b3a00 Author: Josef Bacik Date: Thu Oct 15 19:30:45 2026 +0000 io_uring/poll: drop stale double poll entry on rearm [ Upstream commit f2dbe87968a3aef74a11c025776d293b80964d3f ] A file that uses two wait queues for poll, e.g. a tty, gets a second io_poll entry, which IORING_OP_POLL_ADD keeps in ->async_data until the request is freed. io_poll_add() can run more than once for a request though: IORING_OP_POLL_REMOVE with one of the update flags disarms and rearms it, and io_poll_task_func() reissues it if a wake up turns out to be spurious. The second poll_wait() of the new round then finds *poll_ptr set, with ->head cleared by the disarm, and __io_queue_proc() fails what it takes for a third wait queue with -EINVAL. For an update that means that the poll request is completed with -ECANCELED, while the update itself reports success. For a spurious wake up, e.g. tcsetattr() on the polled tty, the poll request fails with -EINVAL. Free the old entry and clear the poll flags before arming, which is what io_arm_apoll() does for internal polling. All entries have been removed from their wait queues at that point. Fixes: b69de288e913 ("io_uring: allow events and user_data update of running poll requests") Fixes: 6e5aedb9324a ("io_uring/poll: attempt request issue after racy poll wakeup") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-21-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 975da1f9f1211d197c84e97f4a1c2a18d32bca60 Author: Josef Bacik Date: Thu Oct 15 19:30:44 2026 +0000 io_uring/wait: look at all CQ waiters on wake up [ Upstream commit 356f92f2412686f822383b784fa102924407457a ] io_wake_function() returns -1 if the waiter it is called for doesn't have enough events yet, which makes __wake_up_common() stop walking the wait queue. That assumes that the waiters behind it can't be satisfied either. Each waiter has its own target though, computed from the min_complete it passed in: thread A: io_uring_enter(GETEVENTS, min_complete = 10) // queued first thread B: io_uring_enter(GETEVENTS, min_complete = 1) one CQE is posted: A isn't woken, and B isn't even considered B keeps sleeping with the event it asked for sitting in the CQ ring, until A's demand is met or a timeout or signal ends the wait. Return 0 to carry on with the next waiter. Only waiters whose condition is met are woken, like before. Fixes: bda521624e75 ("io_uring: make CQ ring wakeups be more efficient") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-20-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e4ee479687556556934d775b6518c1fed89a5708 Author: Josef Bacik Date: Thu Oct 15 19:30:43 2026 +0000 io_uring: wake ring pollers for local task_work [ Upstream commit b88902d8745a701d24275d012f0830e3628e2a22 ] With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, io_uring_poll() reports EPOLLIN if local work is pending. That only helps if the work is there at the time of the call. When DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->poll_wq, and the wake up in io_req_local_work_add() was replaced by waking the submitter directly. Since then ->poll_wq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to: submitter completion poll(ring_fd) io_uring_poll() // nothing yet schedule() io_req_local_work_add() // ->cq_wait_nr: nobody waits // sleeps on Wake ->poll_wq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring. Fixes: 130bd686d9be ("io_uring: waitqueue-less cq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-19-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4a8ca109f0af43db0ea05a14266b9002f5ff539f Author: Josef Bacik Date: Thu Oct 15 19:30:42 2026 +0000 io_uring/cancel: let CANCEL_ALL find parked requests [ Upstream commit fe6ca13c98b1223f6005f32913ebd32e4df64b77 ] A cancellation with IORING_ASYNC_CANCEL_ALL or _ANY goes on until it finds nothing more. A request may stay where it was found for a while after it has been cancelled, so each one that matches is stamped with the sequence number of the cancellation, and is skipped from then on. io_cancel_cb() does so for io-wq work as well. There is no need to: pending work is taken off the list, and the workers are looked at once per call. And it does harm. A request that is run by io-wq may be parked while it still is the current work of the worker: poll gets armed for it, or it is put on ->futex_list or ->waitid_list. io-wq worker io_try_cancel() io_wq_submit_work() io_arm_poll_handler() io_poll_add_hash() io_async_cancel_one() io_cancel_cb() stamps the request sets IO_WQ_WORK_CANCEL = -EALREADY io_poll_cancel() skips the request = -ENOENT io_assign_current_work(NULL) The flag comes too late for the worker to see it, and the search that would have found the request takes it for done. The cancellation returns, and the request stays. With a multishot poll, IOSQE_ASYNC, and IORING_OP_ASYNC_CANCEL with IORING_ASYNC_CANCEL_ALL up to 63us later, that happens to 4 of 1,000 requests (4 CPUs, KVM). Take the stamp off again if the work matches. If the request is found on one of the lists it gets a new one, and io_cancel_cb() doesn't match it a second time. __io_async_cancel() tries the io-wq of the caller twice. So far the stamp has kept it from counting work that is running there the second time. Skip it instead, so that the number that is returned stays the same. Fixes: 8e29da69fead ("io_uring: add support for IORING_ASYNC_CANCEL_ALL") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-18-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fc5dd19ec1aabb25ffed6178becc410f447a387c Author: Josef Bacik Date: Thu Oct 15 19:30:41 2026 +0000 io_uring/cancel: recognize "no timeout" on 32-bit [ Upstream commit 3774e4d4c8533da2caae95556c4d635c7c4f45b8 ] IORING_REGISTER_SYNC_CANCEL waits without a limit if both fields of io_uring_sync_cancel_reg::timeout are -1. io_sync_cancel() compares them with -1UL. They are of type long long. With a long of 32 bits -1UL is 4294967295, which is what it stays when it is converted for the comparison, and the fields are never equal to it. So { -1, -1 } is taken for a timeout. ktime_set() takes the nanoseconds as an unsigned long, so what becomes of it is -1s + 4294967295ns = 3.29s. If the request is being run by io-wq and can't be interrupted, the call returns -ETIME after that time, rather than waiting for the request to be gone. On i386, with a buffered read from a null_blk device that takes 4s to complete a request, IOSQE_ASYNC, that is what each call does. Fixes: 78a861b94959 ("io_uring: add sync cancelation API through io_uring_register()") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-17-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4c86494493655499ccc74776a364e2c247e8e9bf Author: Josef Bacik Date: Thu Oct 15 19:30:40 2026 +0000 io_uring/cancel: don't forget that the work was running [ Upstream commit 8aa0e5db4845fb5ac11abe40d7b1cac0656c3ee3 ] If the request to be cancelled is being run by io-wq, io_async_cancel_one() flags the work, signals the worker and returns -EALREADY. Since commit ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") io_try_cancel() goes on regardless, as poll may be armed for the request. If it isn't, and nothing else turns up, the result is the -ENOENT of the last search. __io_async_cancel() makes up for that. On -ENOENT it tries the io-wq of every task that uses the ring, and that of the caller is one of them. So the work is found a second time, and the result is -EALREADY after all. Unless the worker is done with it by then. If the work is flagged before io_wq_submit_work() looks at IO_WQ_WORK_CANCEL, all the worker does is to queue the request to be failed by task work. Then it isn't anywhere to be found until the task work has run, and - IORING_REGISTER_SYNC_CANCEL returns -ENOENT, - IORING_OP_ASYNC_CANCEL completes with -ENOENT, for a request that they have just cancelled, and that completes with -ECANCELED. With a read of an empty pipe, IOSQE_ASYNC, and a sync cancel right behind it, 1 to 3 of 1,000,000 calls return -ENOENT, and 50 to 110 with IORING_SETUP_DEFER_TASKRUN (4 CPUs, KVM). Nothing is written to the pipe, and all of these reads end with -ECANCELED. Remember that the work was found. IORING_OP_ASYNC_CANCEL completes with -EALREADY, as it does if the worker is a bit slower. For IORING_REGISTER_SYNC_CANCEL it means to try again, which ends with 0. The result of a linked timeout, which calls io_try_cancel() by itself, and the number that is returned for IORING_ASYNC_CANCEL_ALL and _ANY don't change. Fixes: ccbf726171b7 ("io_uring: perform poll removal even if async work removal is successful") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-16-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 87468ed5d85d39e513d54d13a47361afe2552b23 Author: Josef Bacik Date: Thu Oct 15 19:30:39 2026 +0000 io_uring: don't lose a cancel as io-wq parks a request [ Upstream commit 5cb049d2203d7a81a1c1a737c8df4575e71078e3 ] IORING_OP_FUTEX_WAIT, IORING_OP_FUTEX_WAITV and IORING_OP_WAITID don't block. They put the request on a list of the ring, where a wake up or a cancellation finds it, and return IOU_ISSUE_SKIP_COMPLETE. They do so as well if they are run by io-wq, e.g. because of IOSQE_ASYNC. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request after that, and before it is on the list, finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY ... io_futex_cancel() = -ENOENT ... io_futex_wait() adds the request to ->futex_list = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again. IORING_OP_ASYNC_CANCEL returns -EALREADY and the request stays. It is the problem that "io_uring/poll: don't lose a cancel as io-wq arms poll" deals with for poll. Look at the flag once the request is on the list, and cancel it if it is set. The lists are searched and the requests are added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. What the canceller is told doesn't change, see the other patch, also for IORING_ASYNC_CANCEL_ALL and _ANY. Fixes: 194bb58c6090 ("io_uring: add support for futex wake and wait") Fixes: 8f350194d5cf ("io_uring: add support for vectored futex waits") Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-15-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 782d5aac194add333d10697e91408cff5d556086 Author: Josef Bacik Date: Thu Oct 15 19:30:38 2026 +0000 io_uring/poll: don't lose a cancel as io-wq arms poll [ Upstream commit 6d2d4c2530e95ff6ddeb98195d49d99dbca14369 ] A request on a pollable file that was forced to io-wq is issued without blocking there. If that ends in -EAGAIN, io_wq_submit_work() arms poll for it and returns. It looks at IO_WQ_WORK_CANCEL once, before it issues the request. Somebody who wants to cancel the request in between finds it running: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_issue_sqe() = -EAGAIN io_async_cancel_one() sets IO_WQ_WORK_CANCEL signals the worker = -EALREADY io_poll_cancel() = -ENOENT ... = -ENOENT io_arm_poll_handler() = IO_APOLL_OK return Nobody looks at the flag again, and the signal doesn't matter to a worker that doesn't sleep. The request is armed as if nothing had happened: - a linked timeout completes with -ENOENT, and the request it was meant to limit waits for as long as it takes. - IORING_OP_ASYNC_CANCEL returns -EALREADY, and the request stays. - IORING_REGISTER_SYNC_CANCEL waits for the request to complete if it gets -EALREADY. Since commit 5623eb1ed035 ("io_uring/tctx: add separate lock for list of tctx's in ctx") it doesn't sleep but spins, so its next attempt finds the armed poll. The same goes for a multishot poll, recv or accept that is armed from io-wq. With a read of an empty pipe, IOSQE_ASYNC, and a linked timeout of 5ms or a cancel in the same submission, in a guest that is slow enough (TCG, KASAN), the request is lost in 21 of 24 rounds of 40 or 100 attempts. While it arms poll from io-wq, __io_arm_poll_handler() owns the request. Look at the flag once the request is in the hash table. The table is searched and the request is added with ->uring_lock held, and the flag is set before the search. So either the search finds the request, or it came first and the flag is seen. With the request marked as cancelled, the task work that is queued, right away or because ownership can't be released, fails it with -ECANCELED. What the canceller is told doesn't change. In this window a linked timeout still completes with -ENOENT rather than -ETIME, a cancel request with -EALREADY, and one with IORING_ASYNC_CANCEL_ALL or _ANY with a count that doesn't include the request. But the request is cancelled, so what is new is a request that completes with -ECANCELED after such a result. This doesn't help in two cases: - IORING_ASYNC_CANCEL_ALL and _ANY, if the work is flagged after the test added here, while io-wq still has it as the current work of the worker. io_cancel_cb() stamps it with the sequence of the cancel, so the search of the hash table on behalf of the same cancel takes it for done and skips it. - requests that are parked elsewhere by io-wq, like IORING_OP_FUTEX_WAIT and IORING_OP_WAITID. They have the same problem. Fixes: 90fa02883f06 ("io_uring: implement async hybrid mode for pollable requests") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-14-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6fa54b56ea92d1512eae0079c3d3db25c2d6366f Author: Josef Bacik Date: Thu Oct 15 19:30:37 2026 +0000 io_uring/io-wq: let cancel find picked up hashed work [ Upstream commit e9efeb4fc97b0879512a3c3b995ed448f2487e12 ] io_get_next_work() takes all the work items that share a hash off the work list in one go, and the worker runs them one after the other. Only the one it is working on is visible as ->cur_work. The others are neither on the list nor current, so io_wq_cancel_cb() can't find them. IORING_OP_ASYNC_CANCEL and IORING_REGISTER_SYNC_CANCEL return -ENOENT for a request that has not even been started, e.g. a buffered write queued behind another write to the same file that is blocked, and the request is carried out. The cancellation done for a task or ring that goes away gets there in the end, as it keeps trying, but it has to wait for each item to become current. Keep a pointer to the remainder of the chain next to ->cur_work, and have io_wq_worker_cancel() look at it. The items on it belong to the worker, which needs ->lock to move on to the next one. Matching work is flagged with IO_WQ_WORK_CANCEL and fails with -ECANCELED when its turn comes. The worker isn't signalled for it, that would interrupt the unrelated work it is busy with. As the request isn't gone yet, it is reported like running work, with -EALREADY. Fixes: 86f3cd1b589a ("io-wq: handle hashed writes in chains") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-13-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f26d5232612206fa84ff7c4e46e0af2a3268c5dd Author: Josef Bacik Date: Thu Oct 15 19:30:36 2026 +0000 io_uring/io-wq: don't exit with a creation pending [ Upstream commit e231d2e8f80d3649ecd3851b7f2abdfbe606c04b ] A worker that is the last one to go to sleep while work is pending asks for another worker. io_wq_dec_running() bumps ->nr_running on behalf of the new worker and queues create_worker_cb() as task_work for the owner of the io-wq. Until that has run, everybody else takes it that a worker is running which is going to look after the work list: io_wq_enqueue() doesn't create one, and other workers that go to sleep don't find themselves to be the last. If the worker that made the request exits, io_worker_exit() cancels the task_work, and io_worker_cancel_cb() drops ->nr_running without a look at the work list: worker A worker B io_wq_enqueue() blocks, work is pending nr_running++ queues create_worker_cb() wakes, handles the work idle timeout, decides to exit picks up work 1 queues work 2 B is on the free list still: wakes B work 1 blocks nr_running 2 -> 1 io_worker_exit() io_worker_cancel_cb() nr_running 1 -> 0 Work 2 has to wait for work 1, although there is room for more workers. It takes an owner that doesn't get around to run its task_work for the time of the idle timeout, less if the worker exits because its affinity was changed or the io-wq is marked exit-on-idle. Let the worker stay around until its request has been dealt with. Only the worker itself sets ->create_state, so it can't be set behind its back once it has decided to leave. Fixes: 1d5f5ea7cb7d ("io-wq: remove worker to owner tw dependency") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-12-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5958704e872af2bab2dd6b776045ebb4ed47c656 Author: Josef Bacik Date: Thu Oct 15 19:30:35 2026 +0000 io_uring/io-wq: don't strand work when a worker exits [ Upstream commit ad41f325be1271b22d99353819c90f0d5e45acc8 ] A worker exits if its idle timeout fired and it isn't the last one, if its affinity was changed, or if the wq is marked exit-on-idle. It decides so after it found the work list empty, and until io_worker_exit() is through it stays on the free list and in ->nr_running: worker io_wq_enqueue() io_acct_run_queue() == false queues work io_acct_activate_free_worker() wake_up_process(worker) // found one, nothing to create acct->nr_workers-- break io_worker_exit() Nobody is going to look at the work. If other workers exist, it has to wait until one of them finishes what it is blocked on or hits its idle timeout. If not, which is possible for the affinity and the exit-on-idle case, it sits there until something else is queued. For exit-on-idle it takes a task that closes its last ring and sets up a new one while the workers are on their way out. Make the worker take itself off the free list when it gives up its ->nr_workers slot, then leave ->nr_running, and only then take the final look at the work list. That look and queueing work are both done under acct->lock, so either the worker sees the work and stays, or the enqueue side sees that the worker is gone and wakes or creates another one. If it wants to stay and finds that its slot has been taken, a worker has been created in its place, which is going to look at the work list, and it can leave after all. Fixes: 38aa434ab933 ("io_uring/io-wq: add exit-on-idle state") Fixes: 05c5f4ee4da7 ("io-wq: get rid of FIXED worker flag") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-11-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6e39f9728ae68648883cbde955104e620ea2896d Author: Josef Bacik Date: Thu Oct 15 19:30:34 2026 +0000 io_uring/io-wq: don't go to sleep on pending work [ Upstream commit f19c38feb96802ee53a99649d740d2bf630bcce7 ] io_wq_enqueue() wakes a worker off the free list. If there is none it creates one, unless ->nr_running says that a worker is running. That relies on whoever takes ->nr_running to zero to check for pending work, which io_wq_dec_running() no longer does for a worker without ->cur_work, on the grounds that an idle worker is either woken right away or someone else has created a worker. Neither has to be the case: worker A (idle) worker B (idle) io_wq_enqueue() woken for work 1 woken (e.g. timeout) takes work 1 work list is empty queues work 2 B is first on the free list: wake_up_process(B) leaves the free list work 1 blocks nr_running 2 -> 1 schedule_timeout() nr_running 1 -> 0 ->cur_work == NULL Work 2 isn't looked at until work 1 is done or A's idle timeout fires, five seconds later. ->cur_work is also NULL while a worker blocks on ->uring_lock in io_wq_put_work(), with the same result if it was the only one running. Let the idle worker leave ->nr_running by itself before it takes its last look at the work list. Both that and queueing work are done under acct->lock, so either the worker sees the work, or the enqueue side sees that it can't count on this worker. This doesn't bring back the request for a new worker which the check was meant to avoid, and as idle workers don't get to io_wq_dec_running() any more, the check can go. Fixes: 8343cae362e1 ("io_uring/io-wq: ignore non-busy worker going to sleep") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-10-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 96835abbb4c175fec4fcd8feaa16ca0323ac7098 Author: Josef Bacik Date: Thu Oct 15 19:30:33 2026 +0000 io_uring/mpscq: disable preemption while pushing [ Upstream commit 68a95c3968895cd198f42baadb23e635fecc5a66 ] A push makes the node the new tail, and then links it to its predecessor. In between the queue isn't empty, but mpscq_pop() can't get at the node. The consumers deal with that by trying again, with a cond_resched() in the loop to give a preempted producer the chance to finish. cond_resched() doesn't do that if the consumer has a higher priority than the producer and both have to use the same CPU: producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) io_cqring_wait() __io_run_local_work() again: cond_resched() // nothing to do mpscq_pop() // NULL // work pending, no events yet goto again The producer can be any task that is able to queue task_work for the ring: an io-wq worker, or somebody who sends a message with IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the scheduler takes pity on the fair class, which takes about a second with the default settings of the fair server, and forever without it. The loops in tctx_task_work_run() and io_cancel_local_task_work() have the same problem. Don't allow preemption between the two steps. That bounds the time the window is open on the CPU of the producer by what interrupts take, and a consumer that waits for that is on another CPU. The cost is a preempt_disable()/preempt_enable() pair per push. Fixes: 50cb44bd0d5f ("io_uring/mpscq: add lockless multi-producer, single-consumer FIFO queue") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-9-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 58ddf0ec707093206a5fe814581ec5aefac8b08a Author: Josef Bacik Date: Thu Oct 15 19:30:32 2026 +0000 io_uring/cancel: rearm local work wake up before sleep [ Upstream commit 76a82c666abf155ad52d5f41043eac77dd3e41d8 ] io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run. Fixes: d46ab2c98aba ("io_uring: switch local task_work to a mpscq") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-8-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 581ab347a5d5103c585a546f64581e88edb1cc07 Author: Josef Bacik Date: Thu Oct 15 19:30:31 2026 +0000 io_uring: don't lose the DEFER_TASKRUN wake up [ Upstream commit 8257f6ec45ee07c6ed933c59d8982b03cc7bc1ca ] Since local task_work moved to the mpscq, ->cq_wait_nr is a credit: the add that counts it down to zero, or exchanges it for IO_CQ_WAKE_INIT, issues the only wake up of the wait cycle, and every later add returns early as the count is <= 0. An add looks at the count after it has queued its entry, so an add that gets delayed in between can take the credit of a later cycle. That was assumed to cause an early wake up at worst, but the waiter publishes the count before it changes its task state: CPU0 (submitter, io_cqring_wait) CPU1 (io_req_local_work_add) mpscq_push(req A) io_run_local_work() // runs req A atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 atomic_xchg(.., IO_CQ_WAKE_INIT) wake_up_state(.., TASK_INTERRUPTIBLE) // still TASK_RUNNING, no-op set_current_state(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return The task now sleeps with req B queued, until a signal or a timeout ends the wait. Set the task state first and only then make the count visible, so that whoever takes the credit finds a task it can wake. The full barrier that orders the count against the check of the work list is kept. Do the same for the wait of the BPF driven loop, which copied the sequence. Fixes: d46ab2c98aba ("io_uring: switch local task_work to a mpscq") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-7-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f334e79a11e084713e82402b1a7a0e321526992a Author: Josef Bacik Date: Thu Oct 15 19:30:30 2026 +0000 io_uring: don't flood a cancelling task with task_work [ Upstream commit 22e643e61b9b6299b42ff7d88bab48bccada8a5d ] io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round. Fixes: d56d938b4bef ("io_uring: do ctx initiated file note removal") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-6-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 59e45f44c3cea9f4b2d099171c3cec1d25c5b638 Author: Josef Bacik Date: Thu Oct 15 19:30:29 2026 +0000 io_uring/io-wq: don't hide a link from cancellations [ Upstream commit 436d48a2ed13112d2d27085325838e5bce6b4507 ] A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two. Fixes: 768134d4f481 ("io_uring: don't do flush cancel under inflight_lock") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-5-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7df9a3b5eda51c512d3dd138e3b7daa525071757 Author: Josef Bacik Date: Thu Oct 15 19:30:28 2026 +0000 io_uring/io-wq: don't lose the signal that ends work [ Upstream commit 63c103279a95e82280092f2f4232e91e8117a252 ] When a thread exits, only its tracked requests are cancelled. Then its io-wq is torn down. io_wq_exit_workers() signals every worker, to get it out of an interruptible sleep, and waits for all of them to exit. Before they do, they go through the work that is left. Unbounded work is cancelled. Bounded work is run, as it is expected to end by itself. Not all of it does. An open has no file yet, so it counts as bounded, and the open of a FIFO waits for the other end. That is what the signal is for. But the workers are signalled once, and a worker that hasn't started the work by then loses the signal: io_wq_exit_workers() io_worker_handle_work() io_wq_worker_wake() set TIF_NOTIFY_SIGNAL io_assign_current_work() io_run_task_work() clear TIF_NOTIFY_SIGNAL io_wq_submit_work() fifo_open() wait_for_partner() wait_for_completion_timeout() The thread never gets out of do_exit(): IORING_OP_OPENAT of a FIFO without a writer, IOSQE_ASYNC exit of the thread that has submitted it hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is killed. Set TIF_NOTIFY_SIGNAL for bounded work that is started with IO_WQ_BIT_EXIT set. The bit is set before the workers are signalled, and it is tested after the flag has been cleared, with clear_notify_signal() providing the barrier. So either the flag stays, or the bit is seen. Work that is started while the io-wq exits is treated like work that is being run at that time: it isn't interrupted unless it waits interruptibly. Fixes: afcc4015d1bf ("io-wq: provide an io_wq_put_and_exit() helper") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-4-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 340944e27b4bb218ed0ee66d0947ac70faefa05a Author: Josef Bacik Date: Thu Oct 15 19:30:27 2026 +0000 io_uring/wait: don't spin on a stuck overflow list [ Upstream commit 34f5a664c34d3cb62f6bec7f4156754594a7d25b ] As long as IO_CHECK_CQ_OVERFLOW_BIT is set, io_cqring_wait_schedule() returns right away, before it gets to look at signals or arms the timeout, for io_cqring_wait() to flush the overflow list. If that doesn't empty the list, and the CQ ring doesn't hold the number of events the caller wants, the loop starts over, with the same result. The task spins in the kernel, and can't be killed. The assumption is that this can't happen: if CQEs can't be flushed, the ring is full, and min_events is capped to the size of the ring. But: - With IORING_SETUP_CQE_MIXED a 32b CQE needs two contiguous entries. It is stuck on the list if a single one is free, and then the ring holds less than cq_entries events. A single threaded application that asks for as many events as the ring has entries never gets out of io_uring_enter(). - Whether the ring is full is up to the CQ head, which the application can write to. While one thread waits for events on an empty ring, another one can move the head back so that the ring looks full and have a CQE overflow. The waiter can't be stopped any more, not even by SIGKILL. Only the application can make room in the CQ ring. Return to it if the list could not be flushed. Fixes: 3fcf19d592d5 ("io_uring: parse check_cq out of wq waiting") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-3-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4fe1024b2f3f40f8010591a0c0ad541e2883eda Author: Josef Bacik Date: Thu Oct 15 19:30:26 2026 +0000 io_uring/cmd: don't leave list poison in ->hash_node [ Upstream commit 4c83e39f4d1944d7146fd06094f2c8053238d55c ] io_uring_cmd_del_cancelable() uses hlist_del() to take a command off ->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in ->hash_node. Requests are recycled through the request cache without being reinitialised, and not every user of ->hash_node sets it up before it is used: If a vectored futex wait is woken while futex_wait_multiple_setup() is still queueing the futexes, io_futexv_wait() doesn't add the request to ->futex_list, and leaves the completion to the task_work queued by the wake up. io_futexv_complete() ends in __io_futex_complete(), whose hlist_del_init() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through LIST_POISON2: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...] RIP: 0010:io_futexv_complete+0x219/0x420 Call Trace: tctx_task_work_run+0x804/0x950 tctx_task_work+0x71/0xa0 task_work_run+0x118/0x200 Leave the node unhashed. Fixes: 93b8cc60c37b ("io_uring: cancelable uring_cmd") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-2-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6e11ce129b34fb9a43b2bbe838df49ea52878d5c Author: Josef Bacik Date: Thu Oct 15 19:30:25 2026 +0000 io_uring/waitid: own the request before clearing ->head [ Upstream commit c254eec4364b9f4b4cbdce43be3fb4df5a651a70 ] io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless. Fixes: ab673c1bcaf2 ("io_uring/waitid: use io_waitid_remove_wq() consistently") Assisted-by: LLM Signed-off-by: Josef Bacik Link: https://patch.msgid.link/20261015-b4-io-uring-fixes-v1-1-c1556f5d7bf5@toxicpanda.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5e2e67801f1852e7c307b9d78f786c8e0886f6e8 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 77afbe74dc5b7d704559d2036ac96d3dfb98e5ca Author: Pavankumar Nandeshwar Date: Wed Oct 7 14:53:33 2026 +0530 wifi: ath12k: Increase RXDMA buffer ring size for default memory profile [ Upstream commit 15f7603b69a83a0acc7fcc8992ecbea6110f9424 ] The default RXDMA buffer ring size of 4096 entries can become a bottleneck under high RX traffic load, resulting in reduced receive throughput due to limited buffer availability. Increase the RXDMA buffer ring size to 8192 entries for the default memory profile to provide additional RX buffering and improve RX packet processing efficiency. This increases memory consumption by approximately 9-10 MiB and improves RX throughput by ~20% with the default memory profile (ATH12K_QMI_MEMORY_MODE_DEFAULT). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1 Signed-off-by: Pavankumar Nandeshwar Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20261007-mpp_ws-v1-2-739b1fb87d24@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 7a4092ea607e409534381ded4ef6a13be1a12fd0 Author: Aaradhana Sahu Date: Wed Oct 7 14:53:32 2026 +0530 wifi: ath12k: Make RXDMA buffer ring size configurable per memory profile [ Upstream commit 643f0bf936176c114d5631da7547e991b5d99f10 ] Currently, the RXDMA buffer ring size is hardcoded to 4096 and shared across all memory profiles. This prevents individual profiles from tuning the ring size based on their memory and performance requirements. Add the RXDMA buffer ring size to the memory profile configuration and implement ath12k_dp_rxdma_buf_ring_size() static inline function to access the configured value. This allows different memory profiles to select an appropriate ring size based on available system resources. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20261007-mpp_ws-v1-1-739b1fb87d24@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3310ab2f3d52eaa5d839aa70d0d2cca72ecc9a46 Author: Aaradhana Sahu Date: Thu Aug 20 11:18:04 2026 +0530 wifi: ath12k: convert DP_RX_RELEASE_RING_SIZE to inline helper [ Upstream commit 897d2e0046f941d8956f655f5ffc5d75c788558d ] Replace DP_RX_RELEASE_RING_SIZE macro with ath12k_dp_rx_release_ring_size() static inline helper. Pass the DP profile parameters explicitly to improve type safety and make the interface explicit. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-8-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 753a375bd54d82ef41288c7844bb160217740264 Author: Aaradhana Sahu Date: Thu Aug 20 11:18:03 2026 +0530 wifi: ath12k: convert ATH12K_RX_DESC_COUNT to inline helper [ Upstream commit fafb9b0450fd6fd3618daf347717a6d6320bea38 ] Replace ATH12K_RX_DESC_COUNT with ath12k_dp_rx_desc_count() static inline helper, also replace ATH12K_NUM_RX_SPT_PAGES which is calculated from ATH12K_RX_DESC_COUNT into static inline helper functions and pass the DP profile parameters explicitly to improve type safety and make the interface explicit. Also remove the unused ATH12K_NUM_TX_SPT_PAGE_START macro. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-7-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 471bf7dce307127ec7b568f6335e4baf4ccd1c3c Author: Aaradhana Sahu Date: Thu Aug 20 11:18:02 2026 +0530 wifi: ath12k: convert ATH12K_NUM_POOL_TX_DESC to inline helper [ Upstream commit 99b85a24189a518938eb0f1c4f8e15fbab4373ec ] Replace ATH12K_NUM_POOL_TX_DESC with the ath12k_dp_num_pool_tx_desc() static inline helper. Also replace ATH12K_TX_SPT_PAGES_PER_POOL, ATH12K_NUM_TX_SPT_PAGES, and ATH12K_RX_SPT_PAGE_OFFSET, which are derived from ATH12K_NUM_POOL_TX_DESC, with static inline helper functions. Pass the DP profile parameters explicitly to improve type safety and make the interface more explicit. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-6-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1615fa91c5e9a2c43e7dd19001aec479bd7dcb0d Author: Aaradhana Sahu Date: Thu Aug 20 11:18:01 2026 +0530 wifi: ath12k: convert DP_RXDMA_MONITOR_DST_RING_SIZE to inline helper [ Upstream commit 62e2758d17d307753457bd51af074be5f8265c03 ] Replace DP_RXDMA_MONITOR_DST_RING_SIZE macro with ath12k_dp_rxdma_monitor_dst_ring_size() static inline helper. Pass the DP profile parameters explicitly to improve type safety and make the interface explicit. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-5-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4e567ec40be835d2ae71225bc9c14f26f0e491d7 Author: Aaradhana Sahu Date: Thu Aug 20 11:18:00 2026 +0530 wifi: ath12k: convert DP_RXDMA_MONITOR_BUF_RING_SIZE to inline helper [ Upstream commit d57f90669269fad2dd9ca98cd32b7412ceccb0b0 ] Replace DP_RXDMA_MONITOR_BUF_RING_SIZE macro with ath12k_dp_rxdma_monitor_buf_ring_size() static inline helper. Pass the DP profile parameters explicitly to improve type safety and make the interface explicit. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-4-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 72603d155cbd8d1a96b3190c14cebe85ad014c0b Author: Aaradhana Sahu Date: Thu Aug 20 11:17:59 2026 +0530 wifi: ath12k: convert DP_TX_COMP_RING_SIZE to inline helper [ Upstream commit eaff19e86c2dbde320ccc8812cafb0a366dc65f4 ] Replace DP_TX_COMP_RING_SIZE macro with ath12k_dp_tx_comp_ring_size() static inline helper. Pass the DP profile parameters explicitly to improve type safety and make the interface explicit. Update code using ATH12K_TX_COMPL_NEXT to pass ring size directly rather than deriving it from the ath12k_base structure. Also remove the unused DP_TX_IDR_SIZE macro. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-3-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5483e3312b18fc20ccbc3960e367d95b940b7903 Author: Aaradhana Sahu Date: Thu Aug 20 11:17:58 2026 +0530 wifi: ath12k: move dp_profile_params to dp.h [ Upstream commit bf7c19e231e2f48cafddbe3f4c2a2f5b6184b55f ] Move struct ath12k_dp_profile_params from core.h to dp.h as it is specifically used for Data Path operations. This improves code organization by keeping DP-related structures in the DP header. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260820054804.3222296-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 89092aa492f1ff8cbbca14503a008795251bae6d Author: Lee Seong Hyeon Date: Thu Oct 15 18:07:03 2026 +0700 ksmbd: reject FSCTL_SET_ZERO_DATA on a directory handle [ Upstream commit ef85bad39cf273a8377722c9f3078294dcc2fc7a ] An authenticated client with a writable tree connection can open a directory with FILE_WRITE_DATA and send FSCTL_SET_ZERO_DATA on that handle. The handler only checks fp->daccess & FILE_WRITE_DATA_LE, but on a directory FILE_WRITE_DATA is the legitimate add-file right, so the check passes. ksmbd_vfs_zero_data() then calls kernel_write() on the directory file, which has no FMODE_WRITE, and __kernel_write_iter() hits WARN_ON_ONCE(!(file->f_mode & FMODE_WRITE)), panicking a panic_on_warn kernel. Before commit 25e414db7033 ("ksmbd: report holes in allocated range queries") the dense-file path used vfs_fallocate(), which rejects directories with -EISDIR. The kernel_write() loop that replaced it has no such check. Reject a directory handle in ksmbd_vfs_zero_data() before writing, as ksmbd_vfs_write() already does for SMB2_WRITE. WARNING: fs/read_write.c:608 at __kernel_write_iter+0x74b/0x8c0 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: kernel_write+0x1ef/0x4d0 ksmbd_vfs_zero_data+0x413/0x590 smb2_ioctl+0x21fa/0x66a0 handle_ksmbd_work+0x61b/0x1ff0 Fixes: 25e414db7033 ("ksmbd: report holes in allocated range queries") Signed-off-by: Lee Seong Hyeon Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 97cc014a259537354532faee3c6a185a1584e8fe Author: Stefan Metzmacher Date: Fri Oct 9 12:02:13 2026 +0200 smb: smbdirect: don't hand out already failed sockets in smbdirect_socket_accept() [ Upstream commit 5c171c90c446bdce80ebaecfc5ed2c410bcc7427 ] A socket on the ready list is in SMBDIRECT_SOCKET_NEGOTIATE_RUNNING, but it may fail before smbdirect_socket_accept() picks it up, e.g. RDMA_CM_EVENT_DISCONNECTED already moved it to SMBDIRECT_SOCKET_DISCONNECTED. smbdirect_socket_accept() unconditionally overwrote the status with SMBDIRECT_SOCKET_CONNECTED and handed out the already disconnected socket. smbdirect_socket_cleanup_work() then called rdma_disconnect() on it again, and before the recent commit smbdirect_socket_destroy_sync() waited forever for an RDMA_CM_EVENT_DISCONNECTED that already happened. Now we check first_error and change the status to SMBDIRECT_SOCKET_CONNECTED only via cmpxchg() from SMBDIRECT_SOCKET_NEGOTIATE_RUNNING, while we still hold listen.lock. If the socket already failed, we move it to the orphaned list and queue purge_orphaned_work, like smbdirect_listen_orphan_socket() does, and try the next one. If we only found failed sockets, we wait for the next one. Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1791224972.git.metze%40samba.org Closes: https://sashiko.dev/#/bug/linux-f9dbca09-30a7-4145-9bdb-4676759982c8 Cc: Namjae Jeon Cc: Paulo Alcantara Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit df7e97ff4f114e1dc2188d11339b8d0299c4a77f Author: Stefan Metzmacher Date: Fri Oct 9 12:02:12 2026 +0200 smb: smbdirect: release failed pending sockets of a listener [ Upstream commit 328c7e307e8411899e2f90beae83da9e4c45d700 ] A child of a listener only left the listen.pending or listen.ready list via smbdirect_socket_accept() or when the listener was destroyed. So every connection that failed before it was accepted (negotiate timeout, peer disconnect, invalid negotiate request, ...) stayed on the list and counted against the backlog until the listener was destroyed. After about backlog (10 for ksmbd) such connections smbdirect_listen_connect_request() rejected every new connection with -EBUSY, so an unauthenticated peer was able to permanently stop ksmbd from accepting SMB-Direct connections. Now a failed child moves itself to a new listen.orphaned list at the end of smbdirect_socket_cleanup_work(), after the disconnect was started, and queues listen.purge_orphaned_work, which releases it with smbdirect_socket_release(), without holding the listener's rdma_lock_handler() lock, in the same way smbdirect_socket_destroy() does for the remaining children. Orphaned sockets still count against the backlog until they are released. sc->accept.listener is now only changed under listener->listen.lock and whoever clears it is responsible for releasing the socket: smbdirect_socket_accept(), purge_orphaned_work or the destroy of the listener. In order to make that work: - a struct smbdirect_socket that is a listener is now freed via kfree_rcu(), so that a child can dereference sc->accept.listener under rcu_read_lock(), even if the listener is released concurrently. - smbdirect_listen_connect_request() adds nsc to the listen.pending list and sets nsc->accept.listener before it calls smbdirect_accept_connect_request(), and always returns 0 so the rdma_cm core keeps the connection id and nsc owns it. On a non-zero return it schedules nsc's teardown with smbdirect_socket_schedule_cleanup(), which orphans it off the listener so that purge_orphaned_work releases it; nsc destroys its own connection id with rdma_destroy_id() in that teardown. The teardown has to be deferred because the rdma_cm core holds nsc's id_priv->handler_mutex across the handler, so nsc->rdma.cm_id must not be destroyed synchronously from here. That same handler_mutex (and the listener's) also guarantees nsc can't go away under us, so setting the listener before the call is safe and lets a failure orphan nsc. - smbdirect_accept_negotiate_recv_work() no longer moves a socket to the ready list if it already failed or no longer belongs to the listener. Every accepting socket has a listener, so if sc->accept.listener is already cleared, it no longer sends a negotiate response, as the socket is about to be released. - smbdirect_socket_destroy() of the listener disables purge_orphaned_work and also releases the orphaned sockets. Fixes: dc691b91ad16 ("smb: smbdirect: introduce smbdirect_socket_{listen,accept}()") Reported-by: Lee Seong Hyeon Closes: https://lore.kernel.org/linux-cifs/CANTrAmxL5sWU8Sn29JAGZvSq5PBB2OA+VKA0MHsZJMesagtfzA@mail.gmail.com/ Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1791224972.git.metze%40samba.org Closes: https://sashiko.dev/#/patchset/cover.1791229120.git.metze%40samba.org Cc: Namjae Jeon Cc: Paulo Alcantara Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1ce50f83ed13b3147d4a40b50cc71d0dfdcc6d41 Author: Stefan Metzmacher Date: Fri Oct 9 12:02:11 2026 +0200 smb: smbdirect: don't wait for RDMA_CM_EVENT_DISCONNECTED in smbdirect_socket_destroy_sync() [ Upstream commit 4ca76b89917ad5b317e07ae4f0edc16f7c2a1248 ] smbdirect_socket_destroy_sync() waited for RDMA_CM_EVENT_DISCONNECTED after smbdirect_socket_cleanup_work() called rdma_disconnect(). That can take very long, e.g. if the peer just disappeared, until the rdma cm gives up, or forever if the event already happened, but the status was overwritten afterwards. This is not needed: smbdirect_socket_destroy() drains the qp under rdma_lock_handler(), destroys it and calls rdma_destroy_id(), which only waits for a currently running event handler and makes sure no further events are delivered. The rest of the disconnect protocol (DREQ/DREP and timewait for IB, abrupt close for iWarp) is handled by the rdma core asynchronously. drivers/nvme/host/rdma.c also just calls rdma_disconnect() and ib_drain_qp() before rdma_destroy_id(). So smbdirect_socket_destroy() now also accepts SMBDIRECT_SOCKET_DISCONNECTING and changes the status to SMBDIRECT_SOCKET_DISCONNECTED itself under rdma_lock_handler(). We could still get RDMA_CM_EVENT_DISCONNECTED in the small windows between rdma_unlock_handler() and rdma_destroy_id(), but in that case smbdirect_connection_rdma_event_handler() is basically a no-op. Fixes: 422a2436697d ("smb: smbdirect: introduce smbdirect_socket_destroy[_sync]()") Cc: Namjae Jeon Cc: Paulo Alcantara Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: linux-rdma@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Stefan Metzmacher Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d4a52e78378a501ae38f676e85a60a2a6c21af35 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 1a9c180cd8435917b7516edfb1c9148032c28773 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 Signed-off-by: Greg Kroah-Hartman