commit 458c6079fc1d41d564c37679c8ace02cd83ee817 Author: Greg Kroah-Hartman Date: Sat Jun 27 11:07:41 2026 +0100 Linux 7.0.14 Link: https://lore.kernel.org/r/20260625125637.527552689@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Justin M. Forbes Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Dileep Malepu Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 39a2b95e008665c14f84e50ed411d898df7cd11b Author: Miklos Szeredi Date: Thu May 28 10:58:24 2026 +0200 virtiofs: fix UAF on submount umount commit 06b41351779e9289e8785694ade9042ae85e41ea upstream. iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time. Reported-by: Aurélien Bombo Reported-by: Zhihao Cheng Cc: Greg Kurz Closes: https://github.com/kata-containers/kata-containers/issues/12589 Fixes: 26e5c67deb2e ("fuse: fix livelock in synchronous file put from fuseblk workers") Cc: stable@vger.kernel.org Reviewed-by: Greg Kurz Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b28b12be6e8910489e6800ed93ea4d41dfe19683 Author: Ruslan Valiyev Date: Tue Mar 17 17:05:44 2026 +0000 media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si commit 7d8bf3d8f91073f4db347ed3aa6302b56107499c upstream. syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+814c351d094f4f1a1b86@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=814c351d094f4f1a1b86 Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 06e1f05a1dbe8bbd054c0927b17fc0a61cc8bef7 Author: Gil Portnoy Date: Thu Jun 11 22:59:19 2026 +0900 ksmbd: reject non-VALID session in compound request branch commit 609ca17d869d04ba249e32cdcbf13c0b1c66f43c upstream. smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns "valid". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\host\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check. Fixes: 5005bcb42191 ("ksmbd: validate session id and tree id in the compound request") Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bc3dd82a0ffd488bb902f4c69c3d28fd4088d973 Author: Georgi Djakov Date: Thu May 14 02:26:57 2026 -0700 drivers/base/memory: set mem->altmap after successful device registration commit a2b8d7827f48ee54a686cb80e4a1d0ff954ec42a upstream. If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded. Link: https://lore.kernel.org/20260514092657.3057141-1-georgi.djakov@oss.qualcomm.com Fixes: 1a8c64e11043 ("mm/memory_hotplug: embed vmem_altmap details in memory block") Signed-off-by: Georgi Djakov Acked-by: Oscar Salvador (SUSE) Cc: Vishal Verma Cc: Mike Rapoport Cc: Richard Cheng Cc: David Hildenbrand Cc: Georgi Djakov Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d72650a4f334581b23a1892b888a4cb1be142f76 Author: Stepan Ionichev Date: Thu May 14 19:37:45 2026 +0500 serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails commit 10fc708b4de7f86002d2d735a2dbf3b5b7f65692 upstream. dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path. Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260514143746.23671-2-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman commit ead244f937d6ee50600f974b6a3a7374d74784a6 Author: Viken Dadhaniya Date: Thu May 28 22:48:07 2026 +0530 serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero commit b93062b6d8a1b2d9bad235cac25558a909819026 upstream. In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero, for example when the RX stale counter fires on an idle line, the handler returns without calling geni_se_rx_dma_prep(). The next RX DMA interrupt then hits the !port->rx_dma_addr guard and returns immediately, so the RX DMA buffer is never rearmed and later input is lost. Keep the handler on the rearm path when rx_in is zero. Warn about the unexpected zero-length DMA completion, skip received-data handling, and always call geni_se_rx_dma_prep(). Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260528-serial-rx-0-byte-fix-v2-1-b4195cfe342f@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 74be188eb2dc1c99d63986167b9a67d415fe7326 Author: Yi Yang Date: Thu Jun 4 06:07:34 2026 +0000 vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write commit a287620312dc6dcb9a093417a0e589bf30fcf38a upstream. A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated(). Fixes: 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") Cc: stable@vger.kernel.org Signed-off-by: Yi Yang Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260604060734.2914976-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit de2cc38489b629927910b1aeff69bba7bd5c6f1b Author: Giovanni Cabiddu Date: Mon May 11 11:04:08 2026 +0100 crypto: qat - remove unused character device and IOCTLs commit d237230728c567297f2f98b425d63156ab2ed17f upstream. The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs for device configuration, start, stop, status query and enumeration. These IOCTLs are not part of any public uAPI header and have no known in-tree or out-of-tree users. Device lifecycle is already managed via sysfs. The ioctl interface also increases the attack surface and is the subject of a number of bug reports. Remove the character device, the IOCTL definitions, and the related data structures (adf_dev_status_info, adf_user_cfg_key_val, adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal module_init/module_exit hooks for workqueue, AER, and crypto/compression algorithm registration. Clean up leftover dead code that was only reachable from the removed IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(), adf_devmgr_get_num_dev(), adf_devmgr_get_dev_by_id(), adf_get_vf_real_id() and the unused ADF_CFG macros. Additionally, drop the entry associated to QAT IOCTLs in ioctl-number.rst. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Reported-by: Zhi Wang Reported-by: Bin Yu Reported-by: MingYu Wang Closes: https://lore.kernel.org/all/61d6d499.ab89.19b9b7f3186.Coremail.wangzhi_xd@stu.xidian.edu.cn/ Link: https://lore.kernel.org/all/20260508034841.256794-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260508023542.256299-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260504025120.98242-1-w15303746062@163.com/ Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit abe0854e356b1bb814393ca884cb42b3eb12ce10 Author: Sam Daly Date: Thu May 14 18:23:20 2026 +0200 iio: adc: ti-ads1298: add bounds check to pga_settings index commit 95e8a48d7a85d4226934020e57815a3316d3a14b upstream. ads1298_pga_settings has 7 elements but ADS1298_MASK_CH_PGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system. Assisted-by: gkh_clanker_2000 Cc: stable Cc: Jonathan Cameron Cc: David Lechner Cc: "Nuno Sá" Cc: Andy Shevchenko Signed-off-by: Sam Daly Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f75beebcd5bc9bdc80e0722142e78a6f306214ee Author: Sam Daly Date: Thu May 14 18:23:21 2026 +0200 iio: light: veml6075: add bounds check to veml6075_it_ms index commit 307dc4240bd41852d9e0912921e298160db1c109 upstream. veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption. Assisted-by: gkh_clanker_2000 Cc: stable Signed-off-by: Sam Daly Signed-off-by: Greg Kroah-Hartman Reviewed-by: Javier Carrasco Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7ce4f09aab0abc94b29530fe3e9e6bf95f7a5b67 Author: Faicker Mo Date: Mon May 11 22:05:51 2026 +0800 net: net_failover: Fix the deadlock in slave register commit b84c5632c7b31f8910167075a8128cfb9e50fcfe upstream. There is netdev_lock_ops() before the NETDEV_REGISTER notifier in register_netdevice(), so use the non-locking functions in net_failover_slave_register(). failover_slave_register() in failover_existing_slave_register() adds lock and unlock ops too. Call Trace: __schedule+0x30d/0x7a0 schedule+0x27/0x90 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x538/0x9e0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 dev_set_mtu+0x40/0xe0 net_failover_slave_register+0x24/0x280 failover_slave_register+0x103/0x1b0 failover_event+0x15e/0x210 ? dropmon_net_event+0xac/0xe0 notifier_call_chain+0x5e/0xe0 raw_notifier_call_chain+0x16/0x30 call_netdevice_notifiers_info+0x52/0xa0 register_netdevice+0x5f4/0x7c0 register_netdev+0x1e/0x40 _mlx5e_probe+0xe2/0x370 [mlx5_core] mlx5e_probe+0x59/0x70 [mlx5_core] ? __pfx_mlx5e_probe+0x10/0x10 [mlx5_core] Fixes: 4c975fd70002 ("net: hold instance lock during NETDEV_REGISTER/UP") Signed-off-by: Faicker Mo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fabf508294f75e1e2e7cc7a53c8bade9fdc45ff1 Author: Mike Marciniszyn (Meta) Date: Sat Mar 7 05:58:43 2026 -0500 net: export netif_open for self_test usage commit 3fdd33697c2be9184668c89ba4f24a5ecbc8ec51 upstream. dev_open() already is exported, but drivers which use the netdev instance lock need to use netif_open() instead. netif_close() is also already exported [1] so this completes the pairing. This export is required for the following fbnic self tests to avoid calling ndo_stop() and ndo_open() in favor of the more appropriate netif_open() and netif_close() that notifies any listeners that the interface went down to test and is now coming back up. Link: https://patch.msgid.link/20250309215851.2003708-1-sdf@fomichev.me [1] Signed-off-by: Mike Marciniszyn (Meta) Link: https://patch.msgid.link/20260307105847.1438-2-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 69969796115a9d03941c05aa100fac899e28f13d Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: don't free fd-owned sockets when reaping in the heartbeat commit 56576518920edd7b6c3479477d8d490fe2ebdaaa upstream. The heartbeat reaps orphaned ROSE sockets after their bound device goes down. A socket still attached to a struct socket (sk->sk_socket != NULL -- e.g. an incoming connection an fpad client has accepted and kept open) is owned by that userspace fd: rose_release() frees it on close(). Freeing it from the heartbeat left the fd dangling, so the eventual close() touched freed memory -- slab-use-after-free in rose_release(). Reap only sockets with sk->sk_socket == NULL (unaccepted incoming connections and post-close orphans). For an fd-owned socket whose device went down, disconnect it and fall through to the switch so close() does the teardown. Also release the neighbour reference held by orphaned incoming sockets before tearing them down. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 4507ce5fec5edd8d2c2d8106cc8e6be0f167793e Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: clear neighbour pointer in rose_kill_by_device() commit 606e42d195b467480d4d405f8814c48d1651a76a upstream. rose_kill_by_device() drops the neighbour reference but leaves rose->neighbour pointing at it, unlike every other rose_neigh_put() site (see "rose: clear neighbour pointer after rose_neigh_put() in state machines"). The heartbeat STATE_0 reaping path then puts the same neighbour a second time, causing a rose_neigh refcount underflow and a use-after-free. Set rose->neighbour = NULL after the put, restoring the invariant. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 0c7919c4f1767a3402aed4118045d1f7bc72fef5 Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: cancel neighbour timers in rose_neigh_put() before freeing commit 9b222cb1d23ff210975e9df5ebab7b011acb6fad upstream. rose_neigh_put() kfree()s the neighbour but never cancels its ftimer and t0timer. Until now every caller that dropped the final reference first called rose_remove_neigh(), which deletes those timers. The socket heartbeat reaping path drops the last reference directly, so a neighbour could be freed with t0timer still armed -- it re-arms itself in rose_t0timer_expiry() -- leading to a use-after-free write in enqueue_timer(). Cancel both timers with timer_delete_sync() (the synchronous variant, to wait out a concurrently running, self-rearming handler) in the refcount-zero branch of rose_neigh_put(). Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit e0fbbe60d2721ae38c3e5bb4d63c50c46d4b3f08 Author: Bernard Pidoux Date: Thu May 28 20:20:55 2026 +0200 rose: drop CALL_REQUEST in loopback timer when device is not running commit cf5567a2652e44866eae8987dff4c1ea507680df upstream. When ax25stop brings down rose0 while the loopback timer has pending CALL_REQUEST frames, rose_loopback_timer() calls rose_dev_get() and finds the device still registered (unregister_netdevice waits for refs to drop), then calls rose_rx_call_request() which takes a netdev_hold() for the new socket. But NETDEV_DOWN fires only once: rose_kill_by_device() already ran before this timer tick, so the new socket is never cleaned up. The stuck reference prevents unregister_netdevice from completing, and the orphan socket's timers eventually fire on freed memory (KASAN slab-use-after-free in __run_timers). The kernel clears IFF_UP via dev_close() before sending NETDEV_DOWN, so checking netif_running() after rose_dev_get() is sufficient: if the device is no longer running, the CALL_REQUEST is silently dropped and no socket is created. This closes the race without touching the module-exit path (which already stops the timer via loopback_stopping). Tested: unregister_netdevice completes immediately after ax25stop with active loopback connections; no ref_tracker warnings, no KASAN. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 570e76a3c25f2edd2f5c6c15649f45e5a56f9eb1 Author: Bernard Pidoux Date: Thu May 28 19:38:31 2026 +0200 rose: release netdev ref and destroy orphaned incoming sockets commit df12be096302d2c947388acc25764456c7f18cc1 upstream. Two related cleanup gaps left the module unremovable after a loopback session: 1. rose_destroy_socket() did not release the device reference. When an unaccepted incoming socket (created by rose_rx_call_request()) is destroyed via rose_heartbeat_expiry(), it is removed from rose_list before rose_kill_by_device() can find it, so the netdev_hold() taken in rose_rx_call_request() was never matched by netdev_put(). Add the release at the top of rose_destroy_socket() guarded by a NULL check so that rose_release() and rose_kill_by_device(), which already call netdev_put() and set device = NULL, are not affected. 2. rose_heartbeat_expiry() STATE_0 cleanup required TCP_LISTEN in addition to SOCK_DEAD. Unaccepted incoming sockets are TCP_ESTABLISHED, so the condition was never true and those sockets lingered forever, holding the module use count above zero and blocking rmmod. Drop the TCP_LISTEN restriction: any STATE_0 + SOCK_DEAD socket is orphaned and should be destroyed. Together with the earlier rose_make_new() double-hold fix these three patches allow clean rmmod after loopback sessions. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 4f9aa720a80f1a23b26a04d8bc9d403f96770d09 Author: Bernard Pidoux Date: Thu May 28 19:11:55 2026 +0200 rose: fix netdev double-hold in rose_make_new() commit b9fb21ceb4f0d043767a1eba60786ec84809033b upstream. rose_make_new() copies orose->device from the listener socket and calls netdev_hold(), storing the tracker in rose->dev_tracker. The only caller, rose_rx_call_request(), then overwrites both make_rose->device and make_rose->dev_tracker with a fresh netdev_hold() for the actual incoming-call device. This orphans the tracker allocated by rose_make_new(): it remains in the device's refcount_tracker list but no pointer exists to free it via netdev_put(). The result is one spurious outstanding reference per accepted CALL_REQUEST, visible at rmmod time as: ref_tracker: netdev@X has 2/2 users at rose_rx_call_request+0xba3/0x1d50 [rose] rose_loopback_timer+0x3eb/0x670 [rose] The second entry is the orphaned tracker from rose_make_new(); the first is the correctly-managed socket reference from rose_rx_call_request(). Fix: initialise rose->device to NULL in rose_make_new() and let rose_rx_call_request() -- the sole caller -- assign the correct device and take the sole netdev_hold() as it already does. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 35ed67c5f66dcfba53a184263bafc7c5bd542558 Author: Bernard Pidoux Date: Thu May 28 17:38:18 2026 +0200 rose: disconnect orphaned STATE_2 sockets when device is gone commit d4f4cf9f09a3f5fafa8f09110a7c1b5d10f2f261 upstream. When ax25stop brings down ROSE interfaces, sockets in ROSE_STATE_2 (awaiting CLEAR CONFIRM) whose device pointer is already NULL are not reached by rose_kill_by_device() and wait for T3 (up to 180s) before self-cleaning via rose_timer_expiry(). This keeps the rose module usecount at 1, blocking rmmod for the full T3 duration. In rose_heartbeat_expiry(), detect ROSE_STATE_2 sockets with no device, cancel T3, release the neighbour reference, and call rose_disconnect() + sock_set_flag(SOCK_DESTROY). The next heartbeat tick (<=5s) then destroys the socket via the existing ROSE_STATE_0/SOCK_DESTROY path, allowing clean module unload within 10s instead of up to 180s. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 25982d734933184ef8c9a5d8c6ce782321e23324 Author: Bernard Pidoux Date: Wed May 27 14:11:21 2026 +0200 rose: set SOCK_DESTROY in rose_kill_by_device() for prompt cleanup commit 741a4863ad570889c75f7a8e404567d8f3e46335 upstream. When rose_kill_by_device() is called (via NETDEV_DOWN on module exit or interface removal), it calls rose_disconnect() which transitions sockets to ROSE_STATE_0 and sets SOCK_DEAD. However, rose_heartbeat_expiry() only calls rose_destroy_socket() at ROSE_STATE_0 if SOCK_DESTROY is set -- the SOCK_DEAD path is reserved for TCP_LISTEN sockets. Without SOCK_DESTROY, orphaned sockets in ROSE_STATE_2 (clearing) loop indefinitely in the heartbeat without ever being freed, keeping the module use-count elevated and blocking modprobe -r rose until the T1 timer (up to 200 s) expires. Set SOCK_DESTROY immediately after rose_disconnect() so the heartbeat destroys the socket at its next tick (within 5 s), allowing clean module unload. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 4e5848f3e04be9f427fa912a15cc54f032f059cd Author: Bernard Pidoux Date: Tue May 26 15:57:47 2026 +0200 rose: fix notifier unregistered too early in rose_exit() commit f71a8a1edc14dba746edde38adddd654ba202b4d upstream. rose_exit() called unregister_netdevice_notifier() before the loop that calls unregister_netdev() on each ROSE virtual device. As a result, the NETDEV_DOWN event fired by unregister_netdev() was never delivered to rose_device_event(), so rose_kill_by_device() never ran. Every socket whose rose->device pointed at a ROSE device therefore kept its netdev_tracker entry live until free_netdev() destroyed the ref_tracker_dir, at which point the kernel reported all of them as leaked references (165 entries in a typical FPAC setup). Worse, those sockets retained stale device pointers and live timers that could fire into freed module text after module unload, causing a silent system freeze with no kernel panic logged. Fix by moving unregister_netdevice_notifier() to after the device- unregistration loop. unregister_netdev() then delivers NETDEV_DOWN while the notifier is still registered, rose_kill_by_device() runs for each device, releases all netdev references held by open sockets, and calls rose_disconnect() which stops the per-socket timers. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit fd6ae188077362567b06b189c87bbde4cadde717 Author: Bernard Pidoux Date: Tue May 26 15:57:04 2026 +0200 rose: fix netdev double-hold in rose_rx_call_request() commit c675277c3ba0d2310e0825577d58308c39931e14 upstream. rose_rx_call_request() used netdev_tracker_alloc() after assigning make_rose->device, intending to take ownership of the reference passed by the caller. But every caller -- rose_route_frame() and rose_loopback_timer() -- already calls dev_put() for its own hold after the function returns, so the socket ended up with a tracker entry pointing at a reference that had already been released. The result was spurious refcount_t warnings ("saturated", "decrement hit 0") on every incoming CALL_REQUEST, leading to refcount corruption and eventual silent freeze. Replace netdev_tracker_alloc() with netdev_hold() so that rose_rx_call_request() acquires its own independent reference. Each caller retains its own hold from rose_dev_get() and releases it via dev_put() as before; socket cleanup releases the socket's separate hold via netdev_put(). Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 97f849566cc55472a5acd6c669c70a37ef6fd47e Author: Bernard Pidoux Date: Sat May 16 12:10:55 2026 +0200 rose: guard rose_neigh_put() against NULL in timer expiry commit 2b67342c6ff899a0b83359517146a5b7b243af97 upstream. In rose_timer_expiry(), the ROSE_STATE_2 branch calls rose_neigh_put(rose->neighbour) without first checking whether the pointer is NULL. After commit 5de7665e0a07 ("net: rose: fix timer races against user threads") the timer is re-armed when the socket is owned by a user thread; between the re-arm and the next firing, a device-down event or concurrent teardown via rose_kill_by_device() can set rose->neighbour to NULL, leading to a NULL-pointer dereference inside rose_neigh_put(). Add a NULL check before the put and clear the pointer afterwards. Fixes: 5de7665e0a07 ("net: rose: fix timer races against user threads") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit ccf200f62de0cd5697220132effa46f8166a6a2b Author: Bernard Pidoux Date: Sat May 16 12:10:38 2026 +0200 rose: clear neighbour pointer after rose_neigh_put() in state machines commit e8eb0c6faa8849ba7769516c1a8c84d9f612acf6 upstream. After calling rose_neigh_put() in rose_state1_machine() through rose_state5_machine(), rose->neighbour was left pointing at the potentially freed neighbour structure. A subsequent timer expiry or concurrent teardown path could dereference the stale pointer, causing a use-after-free. Set rose->neighbour to NULL immediately after each rose_neigh_put() call in the state machine functions. Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit f268167945a29dc140783e2aad47439b7941477b Author: Bernard Pidoux Date: Sat May 16 12:10:20 2026 +0200 rose: fix race between loopback timer and module removal commit 47dd6ec1a77d77895afb00aa2e68373a48289108 upstream. rose_loopback_clear() called timer_delete() which returns immediately without waiting for any running callback to complete. If the timer fired concurrently with module removal, rose_loopback_timer() could re-arm the timer after timer_delete() returned and then access rose_loopback_neigh after it was freed. Two complementary changes close the race: 1. Add a loopback_stopping atomic flag. rose_loopback_timer() checks it at entry (before acquiring a reference) and again inside the loop; when set it drains the queue and exits without re-arming the timer. 2. Switch rose_loopback_clear() to timer_delete_sync() so it blocks until any in-flight callback has returned before freeing resources. The smp_mb() between setting the flag and calling timer_delete_sync() ensures the flag is visible to any callback that is about to run. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 8f735e5122047824f7f40696c16957722e0593c7 Author: Bernard Pidoux Date: Sat May 16 12:10:03 2026 +0200 rose: hold loopback neighbour reference across timer callback commit d270a7a5793af84555c40dd1eb80f1d497fdf53c upstream. rose_loopback_timer() dereferences rose_loopback_neigh throughout its body but holds no reference on it. A concurrent rose_loopback_clear() followed by rose_add_loopback_neigh() could free and reallocate the neighbour while the timer body is running, causing a use-after-free. Take a reference with rose_neigh_hold() at the start of the callback (bailing out if the pointer is already NULL) and release it with rose_neigh_put() at the single exit point. The neigh cannot be freed while the callback holds a reference. Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit a0f4ec7041de7248ecaf0896d8d4eedb5de1aca3 Author: Bernard Pidoux Date: Sat May 16 12:09:33 2026 +0200 rose: fix dev_put() leak in rose_loopback_timer() commit ff91adc54db2b62c7cdf063ff761eceb5adf2215 upstream. rose_rx_call_request() always consumes or returns the skb but never releases the device reference obtained from rose_dev_get(). When rose_rx_call_request() succeeds (returns non-zero) dev_put() was never called, leaking one reference per loopback CALL_REQUEST. Move dev_put() outside the conditional so it is called unconditionally after rose_rx_call_request() in all cases. Also remove the dead check (!rose_loopback_neigh->dev && !rose_loopback_neigh->loopback) that immediately precedes it: the loopback neighbour always has loopback=1 so this condition can never be true. Fixes: 0453c6824595 ("net/rose: fix unbound loop in rose_loopback_timer()") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 0aa9b27c454c53074cde592eaceb442d30341585 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon May 4 15:48:23 2026 +0800 agp/amd64: Fix broken error propagation in agp_amd64_probe() commit b08472db93b1ccff84a7adec5779d47f0e9d3a30 upstream. A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source. Fixes: a32073bffc65 ("[PATCH] x86_64: Clean and enhance up K8 northbridge access code") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Lukas Wunner Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v2.6.18+ Link: https://patch.msgid.link/20260504074823.99377-1-w15303746062@163.com Signed-off-by: Greg Kroah-Hartman commit f193e38cb257d033060b63f1cfd94af076b3a2ab Author: Weiming Shi Date: Thu May 14 05:25:12 2026 -0700 net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() commit d00c953a8f69921f484b629801766da68f27f658 upstream. rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers. Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260514122511.3083479-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0526931b16e5a118d367b7bfce7d797e63f7ac69 Author: Weiming Shi Date: Wed Apr 15 01:23:39 2026 +0800 i2c: stub: Reject I2C block transfers with invalid length commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 16af24fea29c209dea53595c99f6da9398548e1b Author: Weiming Shi Date: Tue Apr 21 23:54:12 2026 -0700 bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths commit 375e4e33c18dfa05c5dfd5f3dfffeb29343dd4c7 upstream. bpf_selem_unlink_nofail() sets SDATA(selem)->smap to NULL before removing the selem from the storage hlist. A concurrent RCU reader in bpf_sk_storage_clone() can observe the selem still on the list with smap already NULL, causing a NULL pointer dereference. general protection fault, probably for non-canonical address 0xdffffc000000000a: KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057] RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174 Call Trace: sk_clone+0xfed/0x1980 net/core/sock.c:2591 inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222 tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571 tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729 tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855 tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347 Add a NULL check for smap in bpf_sk_storage_clone(). bpf_sk_storage_diag_put_all() has the same issue. Add a NULL check and pass the validated smap directly to diag_get(), which is refactored to take smap as a parameter instead of reading it internally. bpf_sk_storage_diag_put() uses diag->maps[i] which is always valid under its refcount, so diag->maps[i] is passed directly to diag_get(). Fixes: 5d800f87d0a5 ("bpf: Support lockless unlink when freeing map or local storage") Reported-by: Xiang Mei Acked-by: Amery Hung Signed-off-by: Weiming Shi Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20260422065411.1007737-2-bestswngs@gmail.com Signed-off-by: Greg Kroah-Hartman commit c75f8ce4baa29ae57fe615c6a2c5101f59b8b89a Author: Lord Ulf Henrik Holmberg Date: Sat May 9 10:40:11 2026 +0200 RDMA/bnxt_re: zero shared page before exposing to userspace commit f6b079629becfa977f9c51fe53ad2e6dcc55ef44 upstream. bnxt_re_alloc_ucontext() allocates uctx->shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it. The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents. Any user with access to /dev/infiniband/uverbsX on a host with a bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT. Other shared pages in the same file already use get_zeroed_page() correctly: drivers/infiniband/hw/bnxt_re/ib_verbs.c srq->uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL); cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL); uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page(). Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Lord Ulf Henrik Holmberg Link: https://patch.msgid.link/20260509084011.11971-1-pomzm67@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 261ce1d0b22246f89f1132dd132ecb128e16ea63 Author: Yang Erkun Date: Wed May 13 10:42:52 2026 +0800 Revert "NFSD: Defer sub-object cleanup in export put callbacks" commit 516403d4d85607fdef3ca41d4a56b54e5566fa9a upstream. This reverts commit 48db892356d6cb80f6942885545de4a6dd8d2a29. Commit 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") moved path_put() and auth_domain_put() out of svc_export_put() and expkey_put() and behind queue_rcu_work() to close a claimed use-after-free in e_show() and c_show() against ex_path and ex_client->name. Discussion in [1] shows neither the diagnosis nor the remedy survives review. The downstream teardown of both sub-objects is already RCU-deferred. auth_domain_put() reaches svcauth_unix_domain_release(), which frees the unix_domain and its ->name through call_rcu(). path_put() reaches dentry_free(), which frees the dentry through call_rcu(), and prepend_path() is already structured to tolerate concurrent dentry teardown. A reader in cache_seq_start_rcu() therefore observes both sub-objects through the next grace period regardless of whether svc_export_put() runs synchronously, so the synchronous form was never unsafe. The crash signature in the report cited by commit 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") has a different root cause: a /proc/net/rpc cache file held open across network-namespace exit lets cache_destroy_net() free cd->hash_table while a reader is still walking it. The correct fix pins cd->net for the open fd's lifetime and does not require any deferral inside svc_export_put(). Meanwhile, deferring path_put() out of svc_export_put() reintroduces the regression that commit 69d803c40ede ("nfsd: Revert "nfsd: release svc_expkey/svc_export with rcu_work"") repaired: after "exportfs -r" drops the last cache reference, the mount reference held through ex_path lingers in the workqueue, so a subsequent umount fails with EBUSY. Restore the synchronous path_put() and auth_domain_put() in svc_export_put() and expkey_put() and the call_rcu()/kfree_rcu() free of the containing structures. The unrelated fix for ex_uuid/ex_stats from commit 2530766492ec ("nfsd: fix UAF when access ex_uuid or ex_stats") is preserved. Link: https://lore.kernel.org/all/10019b42-4589-4f9f-8d5b-d8197db1ce3c@huawei.com/ [1] Fixes: 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Tested-by: Alexandr Alexandrov Signed-off-by: Yang Erkun Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0223f452532d9cd8a5e87c45de828fd93c99bd25 Author: Joanne Koong Date: Mon May 18 22:28:06 2026 -0700 fuse: re-lock request before replacing page cache folio commit a078484921052d0badd827fcc2770b5cfc1d4120 upstream. fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable@vger.kernel.org Reported-by: Lei Lu Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 63241af356bb9845dcea46b8e7702c1858863500 Author: Tudor Ambarus Date: Wed Jun 17 10:27:39 2026 -0400 firmware: samsung: acpm: Fix missing LKMM barriers in sequence allocator [ Upstream commit bf296f83a3ddab1ab875edc4e8862cb10553064f ] Sashiko identified memory ordering races in [1]. The ACPM driver uses a globally shared 'bitmap_seqnum' to track available sequence numbers. Even though threads now strictly free their own sequence numbers, the allocation and freeing of these bits across concurrent threads are effectively lockless operations and require explicit LKMM memory barriers. Previously, the driver used plain bitwise operators (test_bit, set_bit, clear_bit), which lack ordering guarantees. This creates two race conditions on weakly ordered architectures like ARM64: 1. Polling Release Violation: The polling thread copies its payload and calls clear_bit(). Without a release barrier, the CPU can reorder the memory operations, making the cleared bit globally visible before the payload reads have fully completed. 2. TX Acquire Violation: The TX thread loops on test_bit(), calls set_bit(), and then wipes the payload buffer via memset(). Without an acquire barrier, the CPU can speculatively execute the memset() before the bit is safely and formally claimed. If these reorderings overlap, a new TX thread can claim the sequence number and overwrite the buffer while the original polling thread is still actively reading from it. Fix this by upgrading the bitwise operators. Wrap the TX allocation in test_and_set_bit_lock() to establish formal LKMM Acquire semantics, and pair it with clear_bit_unlock() in the polling path to enforce Release semantics. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-6-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48b7e0a28a1060d6868ae59ea80da8403b4cfdcb Author: Tudor Ambarus Date: Tue Jun 16 21:47:27 2026 -0400 firmware: samsung: acpm: Fix false timeouts and Use-After-Free in polling [ Upstream commit c889b146478885344a220dd468e5a08de088cbc5 ] Sashiko identified severe races in the polling state machine [1]. In the ACPM driver's polling mode, threads waited for responses by monitoring the globally shared 'bitmap_seqnum'. This caused false timeouts because if a thread processed its response and freed the sequence number, a concurrent TX thread could immediately reallocate it before the polling thread woke up. Additionally, the driver suffered from a cross-thread Use-After-Free (UAF) preemption race. Previously, acpm_get_rx() cleared the sequence number of whichever RX message it drained from the hardware queue. This meant Thread A could globally free Thread B's sequence slot while Thread B was asleep. A new Thread C could then steal the slot, overwrite the buffer, and leave Thread B to wake up to corrupted state or a timeout. Fix this by rewriting the polling state machine: 1. Decouple polling from the global allocator by introducing a per-slot 'completed' flag, synchronized via smp_store_release() and smp_load_acquire(). 2. Strip acpm_get_saved_rx() out of acpm_get_rx() to make it a pure queue-draining function. Introduce a 'native_match' boolean argument which evaluates to true only if the thread natively processed its own sequence number during the call. This explicitly informs the polling loop whether it must retrieve its payload from the cross-thread cache. 3. Centralize the cache fallback and sequence number free (clear_bit) inside the polling loop. Crucially, the free operation now strictly targets the thread's own TX sequence number (xfer->txd[0]), rather than the drained RX sequence number. This enforces strict ownership: a thread only ever frees its own allocated sequence slot, and only at the exact moment it completes its poll, eliminating the UAF window. Furthermore, explicitly guard the 'native_match' assignment with an if (rx_seqnum == tx_seqnum) check, even for zero-length (no payload) responses. While an unguarded assignment wouldn't crash (because the cache fallback acpm_get_saved_rx() safely returns early on zero-length transfers) doing so would "lie" to the state machine. If a thread drained the queue and found another thread's zero-length message, setting native_match = true would falsely convince the polling loop that it natively handled its own response. Maintaining a rigorous state machine requires that native_match is only set when a thread explicitly processes its own sequence number. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-5-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ca187ed2fb761857593ac7b98bc7bc404dbd8113 Author: Tudor Ambarus Date: Tue Jun 16 18:39:36 2026 -0400 firmware: samsung: acpm: Fix cross-thread RX length corruption [ Upstream commit f133bd4b5daf71bccdde0ad1a4f47fac76a6bfb1 ] Sashiko identified a cross-thread RX length corruption bug when reviewing the thermal addition to ACPM [1]. When multiple threads concurrently send IPC requests, the ACPM polling mechanism can encounter responses belonging to other threads. To drain the queue, the driver saves these concurrent responses into an internal cache (`rx_data->cmd`) to be retrieved later by the owning thread. Previously, the driver incorrectly used `xfer->rxcnt` (the expected receive length of the *current* polling thread) when copying data for *other* threads into this cache. If the threads expected responses of different lengths, this resulted in buffer underflows (leading to reads of uninitialized memory) or potential buffer overflows. Fix this by replacing the boolean `response` flag in `struct acpm_rx_data` with `rxcnt`, caching the exact expected receive length for each specific transaction during transfer preparation. Use this cached length when saving concurrent responses. Consequently, ensure that `xfer->rxcnt` is explicitly zeroed in driver helpers (e.g., `acpm_dvfs_set_xfer`) for fire-and-forget messages to prevent uninitialized stack garbage from being interpreted as a massive expected receive length. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Reported-by: Titouan Ameline de Cadeville Closes: https://lore.kernel.org/r/20260426210255.73674-1-titouan.ameline@gmail.com/ Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-1-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d37e3e1fe9888bccca67df10b86ff0fb2840866 Author: Krzysztof Kozlowski Date: Tue Jun 16 18:39:35 2026 -0400 firmware: exynos-acpm: Count acpm_xfer buffers with __counted_by_ptr [ Upstream commit 951b8eee0581bbf39e7b0464d679eee8cb9da3e0 ] Use __counted_by_ptr() attribute on the acpm_xfer buffers so UBSAN will validate runtime that we do not pass over the buffer size, thus making code safer. Usage of __counted_by_ptr() (or actually __counted_by()) requires that counter is initialized before counted array. Tested-by: Tudor Ambarus Reviewed-by: Tudor Ambarus Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-3-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski Stable-dep-of: f133bd4b5daf ("firmware: samsung: acpm: Fix cross-thread RX length corruption") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7611065b40e93fa040221e61bf7e18f0b1848eb Author: Krzysztof Kozlowski Date: Tue Jun 16 18:39:34 2026 -0400 firmware: exynos-acpm: Count number of commands in acpm_xfer [ Upstream commit 00808ae2e679a97dccc5cf0ee4474ba1e2e8a21a ] Struct acpm_xfer holds two buffers with u32 commands - rxd and txd - and counts their size by rxlen and txlen. "len" suffix is here ambiguous, so could mean length of the buffer or length of commands, and these are not the same since each command is u32. Rename these to rxcnt and txcnt, and change their usage to count the number of commands in each buffer. This will have a benefit of allowing to use __counted_by_ptr later. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-2-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski Stable-dep-of: f133bd4b5daf ("firmware: samsung: acpm: Fix cross-thread RX length corruption") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7c42cff61014ce883405765df2270d140c2ba64 Author: NeilBrown Date: Fri Jun 19 16:47:50 2026 -0400 lockd: fix TEST handling when not all permissions are available. [ Upstream commit 0b474240327cebeff08ad429e8ed3cfc6c8ee816 ] The F_GETLK fcntl can work with either read access or write access or both. It can query F_RDLCK and F_WRLCK locks in either case. However lockd currently treats F_GETLK similar to F_SETLK in that read access is required to query an F_RDLCK lock and write access is required to query a F_WRLCK lock. This is wrong and can cause problems - e.g. when qemu accesses a read-only (e.g. iso) filesystem image over NFS (though why it queries if it can get a write lock - I don't know. But it does, and this works with local filesystems). So we need TEST requests to be handled differently. To do this: - change nlm_do_fopen() to accept O_RDWR as a mode and in that case succeed if either a O_RDONLY or O_WRONLY file can be opened. - change nlm_lookup_file() to accept a mode argument from caller, instead of deducing base on lock time, and pass that on to nlm_do_fopen() - change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing the same mode as before for other requests. Also set lock->fl.c.flc_file to whichever file is available for TEST requests. - change nlmsvc_testlock() to also not calculate the mode, but to use whatever was stored in lock->fl.c.flc_file. This behaviour of lockd - requesting O_WRONLY access to TEST for exclusive locks - has been present at least since git history began. However it was hidden until recently because knfsd ignored the access requested by lockd and required only READ access for all locking requests (unless the underlying filesystem provided an f_op->open function which checked access permissions). The commit mentioned in Fixes: below changed nfsd_permission() to NOT override the access request for LOCK requests and this exposed the bug that we are now fixing. Note that there is another issue that this patch does not address. The flock(.., LOCK_EX) call is permitted on a read-only file descriptor. Linux NFS maps this to NLM locking as whole-file byte-range locks. nfsd will see this as though it were fcntl( F_SETLK (F_WRLCK)) and will now require write access, which it might not be able to get. It is not clear if this is a problem in practice, or what the best solution might be. So no attempt is made to address it. Reported-by: Tj Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861 Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ec8427444b710599a2786e97db6e038851a5cbce Author: Mark Rutland Date: Thu Jun 18 16:14:26 2026 +0100 arm64/entry: Fix arm64-specific rseq brokenness commit 411c1cf430392c905e39f12bc305dd994da0b426 upstream. Mathias Stearn reports that since v6.19, there are two big issues affecting rseq: (1) On arm64 specifically, rseq critical sections aren't aborted when they should be. (2) The 'cpu_id_start' field is no longer written by the kernel in all cases it used to be, including some cases where TCMalloc depends on the kernel clobbering the field. This patch fixes issue #1. This patch DOES NOT fix issue #2, which will need to be addressed by other patches. The arm64-specific brokenness is a result of commits: 2fc0e4b4126c ("rseq: Record interrupt from user space") 39a167560a61 ("rseq: Optimize event setting") The first commit failed to add a call to rseq_note_user_irq_entry() on arm64. Thus arm64 never sets rseq_event::user_irq to record that it may be necessary to abort an active rseq critical section upon return to userspace. On its own, this commit had no functional impact as the value of rseq_event::user_irq was not consumed. The second commit relied upon rseq_event::user_irq to determine whether or not to bother to perform rseq work when returning to userspace. As rseq_event::user_irq wasn't set on arm64, this work would be skipped, and consequently an active rseq critical section would not be aborted. Fix this by giving arm64 syscall-specific entry/exit paths, and performing the relevant logic in syscall and non-syscall paths, including calling rseq_note_user_irq_entry() for non-syscall entry. Currently arm64 cannot use syscall_enter_from_user_mode(), syscall_exit_to_user_mode(), and irqentry_exit_to_user_mode(), due to ordering constraints with exception masking, and risk of ABI breakage for syscall tracing/audit/etc. For the moment the entry/exit logic is left as arm64-specific, directly using enter_from_user_mode() and exit_to_user_mode(), but mirroring the generic code. I intend to follow up with refactoring/cleanup, as we did for kernel mode entry paths in commit: 041aa7a85390 ("entry: Split preemption from irqentry_exit_to_kernel_mode()") ... which will allow arm64 to use the GENERIC_IRQ_ENTRY functions directly. Fixes: 39a167560a61 ("rseq: Optimize event setting") Reported-by: Mathias Stearn Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Acked-by: Catalin Marinas Link: https://lore.kernel.org/regressions/CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com/ Link: https://patch.msgid.link/20260508142023.3268622-1-mark.rutland@arm.com [Mark: fix conflicts in entry-common.c & irq-entry-common.h] Signed-off-by: Mark Rutland Signed-off-by: Sasha Levin commit b027adee02ac56521ddb084ede3df45e7d4e6a9d Author: Gabriel Krisman Bertazi Date: Wed Jun 17 15:27:22 2026 -0400 io_uring/net: Avoid msghdr on op_connect/op_bind async data [ Upstream commit 3979840cd858f30f43ea9f4e7f7f1f56de82d698 ] This fixes a memory leak due to the lack of the cleanup hook for the iovec. The stable backport differs from upstream by dropping the io_connect_bpf_populate hunk, which didn't exist at the time and by fixing the merge conflict due to the introduction of io_bind_file_create. Both IORING_OP_CONNECT and IORING_OP_BIND reuse the msghdr object just to store the sockaddr. Beyond allocating a much larger object than needed, msghdr can also wrap an iovec, which will be recycled unnecessarily. This uses the sockaddr directly. Cc: stable@vger.kernel.org Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260602215327.1885109-2-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Sasha Levin