commit 497791a0a96b866d90add64041c47acdff49cae6 Author: Greg Kroah-Hartman Date: Sun Nov 1 13:44:45 2026 +0100 Linux 7.2.15 Link: https://lore.kernel.org/r/20261030121255.257615100@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 53173c77df20827b4b0229d1b018217842a3d051 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 d7d6ff98d5d1b400f02211f962ac32cc0020aeab Author: Zizhen Liu Date: Thu Oct 22 18:42:17 2026 +0800 net: skbuff: propagate shared-frag marker in skb_zerocopy() commit 79dc34beb1fdb3da79753e51e15c68591a2561fe upstream. skb_zerocopy() moves frag descriptors from @from into @to and takes a reference on each frag, but it does not copy skb_shinfo(from)->flags into skb_shinfo(to)->flags. A destination skb holding the same page-cache backed frags as the source therefore reports skb_has_shared_frag() as false. That breaks the invariant relied on by later in-place writers. ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(); with the marker lost, an skb that skb_zerocopy() built for nfnetlink_queue or for an openvswitch upcall is decrypted in place, letting an unprivileged user write into the page cache of a root-owned read-only file. Propagate SKBFL_SHARED_FRAG when frag descriptors are copied, as done for the other frag-transfer helpers. Fixes: af2806f8f90a ("net: Export skb_zerocopy() to zerocopy from one skb to another") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@kernel.org Signed-off-by: Zizhen Liu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261022104217.1852191-1-pointerliu@126.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted context in skb_zerocopy() due to missing from->unreadable propagation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9dea2e237ffe2a325b9d42ed15ea9ee6561979c7 Author: Christian Brauner Date: Wed Oct 28 13:13:46 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 915fa76e2258945cd2a9d657ef3afe5b851cdf9b Author: Christian Brauner Date: Wed Oct 28 13:13:45 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 be2156e8d61c7426e5cb626336a81d62d71eb792 Author: Christian Brauner Date: Wed Oct 28 15:03:19 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 00edc2319f19e34c6a0e117be30337010b36ae19 Author: André Draszik Date: Tue Jul 28 13:42:40 2026 +0100 kbuild: link-vmlinux.sh: improve detection of third pass requirement [ Upstream commit 14b8b4bf2d7bd5d58c17adbeed0edfda1dfc1a7f ] It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk because of section alignment and/or padding emitted by the assembler. link-vmlinux.sh doesn't detect this case currently and keeps using .tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the different symbol sizes, other symbols are shifted within the final image compared to .tmp_vmlinux2, and the final comparison of System.map against "${kallsyms_sysmap}" fails with the message: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround This can happen in particular if the linker emits additional symbols that might have different names between our (re-)linking steps, e.g. because those names depend on the virtual address of the symbol. Linker stubs for ARM errata work-arounds are one such case. These changed symbol names can cause the output of the token compression of kallsyms.c to change due to the changed symbol substring count, which in turn can change the size of the kallsyms_names symbol itself, causing the potential shift of subsequent symbol addresses in .tmp_vmlinux2.kallsyms.o and therefore the final image. Update link-vmlinux.sh to not rely on file size of .tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets within to resolve this, and do a third pass if required. Signed-off-by: André Draszik Tested-by: Nathan Chancellor Reviewed-by: Nicolas Schier Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 4c9c0235f8e453a8a53ad685830dc60e01ce5678 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 8df7b995ebef427fc12ff8f00e96d8b339e6d743 Author: Daniel Schaefer Date: Thu Jul 23 01:18:58 2026 +0800 iio: hid-sensor: als: scale each channel individually [ Upstream commit cad928dad9a4c26aa56b4223dc2a29bca517fb5f ] Some sensors have multiple channels (not just brightness but color ALS sensors) with different scaling factors. Signed-off-by: Daniel Schaefer Link: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/413 Tested-by: Sven Vainküla #Asus ProArt PX13 laptop. Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 99d13ac9f46d7c7e29ee7b2fe189b4c4a3d6d6c2 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 c13279523ed5da31ca7bba761115afdbd40e06eb 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 e08d8c2a022754e10b6f7d01faf20958665f4c4d 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 aaf8a64a3fbf745eddea729fe27c6e22f4a009e2 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