commit a300e35c0a4b4a38fb53742ea6e2a203c98ee523 Author: Greg Kroah-Hartman Date: Fri Sep 11 11:51:26 2026 +0200 Linux 7.2.5 Link: https://lore.kernel.org/r/20260909134230.441546314@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Takeshi Ogasawara Tested-by: Salvatore Bonaccorso Tested-by: Dileep Malepu Tested-by: Wentao Guan Tested-by: Justin M. Forbes Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Benjamin Boortz Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit be15b8da4a82cf1e1f9880b2661b90770606eec1 Author: Namjae Jeon Date: Tue Aug 25 09:31:35 2026 +0900 ksmbd: zero pipe read compound padding commit 73f860489e3be2245598d1819226304fc5b87291 upstream. Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Cheryl Babcock Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit ecdcceed4d377b02d4ea036b65f83f962c38ede7 Author: Farhan Ali Date: Wed Sep 9 07:47:44 2026 -0400 PCI: Allow per function PCI slots to fix slot reset on s390 [ Upstream commit dcc5bec09e23bbc4f9de055a11fce9937244f2c8 ] On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES. Fixes: 44510d6fa0c0 ("s390/pci: Handling multifunctions") Suggested-by: Niklas Schnelle Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Schnelle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-3-alifm@linux.ibm.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8418a7201bb3f38817c8f998819470757462b850 Author: Farhan Ali Date: Wed Sep 9 07:47:43 2026 -0400 PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder value [ Upstream commit c243e6c470c4695965cc8287767925bc1d9a7867 ] Introduce a constant for placeholder value and update the kerneldoc for pci_create_slot() to reference PCI_SLOT_PLACEHOLDER instead of -1 throughout. No functional change. Suggested-by: Bjorn Helgaas Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Cc: Madhavan Srinivasan Cc: Tyrel Datwyler Cc: linuxppc-dev@lists.ozlabs.org Link: https://patch.msgid.link/20260805165518.794-2-alifm@linux.ibm.com Stable-dep-of: dcc5bec09e23 ("PCI: Allow per function PCI slots to fix slot reset on s390") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb27cd32dd7818db580252e1aa6b466efa00c43b Author: SJ Park Date: Tue Jul 14 20:09:58 2026 -0700 mm/damon/vaddr: drop last same folio access check optimization commit 831846078caa14b7d00b2ccca8b8fe522afe3204 upstream. The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit e3db5d6bb03495239baf6a4c3a15c2ddf59bf656 Author: SJ Park Date: Tue Jul 14 20:09:59 2026 -0700 mm/damon/paddr: drop last same folio access check reuse optimization commit f23f0aa62b2f32c2b12f95959fc4603ef81678b2 upstream. It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 91b75a9e79e98887828a3b1a40e7df43a74c3adb Author: SJ Park Date: Sun Jul 19 09:11:33 2026 -0700 mm/damon/ops-common: use nr_accesses moving sum for quota score commit 6c25083f7ae7e2660d766169e5b4d3e96010503f upstream. Since commit 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval"), DAMOS scheme can be applied at any time. At that time, nr_accesses may not be fully aggregated. But the quota prioritization score is calculated using the not fully aggregated count. As a result, the performance of DAMOS could be degraded. Fix by using damon_nr_accesses_mvsum() instead. The user impact of the issue is suboptimum DAMOS performance under certain setups. Nonetheless, the bug was there from the beginning of the setup availability. In other words, the suboptimum performance is the baseline of the setup and hence it didn't cause regression. Also the extent of the suboptimality was not big enough to be found from users and testers. Still, this is a clear bug that is better to be fixed, and can be easily fixed. Link: https://lore.kernel.org/20260719161136.90191-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SJ Park Cc: # 6.7.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 8a96a06e04d210845be5d9581c0e9e338947e8f8 Author: SJ Park Date: Tue Jul 14 20:09:56 2026 -0700 mm/damon/core: avoid infinite kdamond_merge_regions() internal loop commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd upstream. Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 013731074ab6a8d11ec209eee64c5b2656954479 Author: Fan Wu Date: Wed Sep 9 07:28:12 2026 -0400 power: supply: ab8500_fg: fix use-after-free on remove [ Upstream commit 75b1e88d34254f4fb7753345e21bfee47abddd7f ] ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool. Fixes: 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260802020316.417757-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a184e6f211c863239f7b68bb406c9caae5c301e Author: Pan Chuang Date: Wed Sep 9 07:28:11 2026 -0400 power: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe() [ Upstream commit aa5f4decedfb4fc5cd0fe49ab256ad4304d192e4 ] The devm_request_threaded_irq() and devm_request_irq() now automatically log detailed error messages on failure. This eliminates the need for driver-specific dev_err() and dev_err_probe() calls that previously printed generic messages. Signed-off-by: Pan Chuang Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260709033428.362970-7-panchuang@vivo.com Signed-off-by: Sebastian Reichel Stable-dep-of: 75b1e88d3425 ("power: supply: ab8500_fg: fix use-after-free on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 57dba479a3e1f26fbbf4b73b0aaa5a4df1fbc095 Author: Mukesh Ojha Date: Wed Sep 9 05:26:01 2026 -0400 remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check [ Upstream commit c06c5ab4945392d2c2aded6d832ab6b58cabe351 ] All other call sites of qcom_scm_pas_metadata_release() for the DTB context are guarded by a check on pas->dtb_pas_id, but the call inside qcom_pas_load() was not. Fix this by moving the call to the guarded block. Reviewed-by: Konrad Dybcio Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson [ changed qcom_pas_metadata_release() to qcom_scm_pas_metadata_release() for the older branch API. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea0408273ccf5df1fb52d9a1b9db4d31600dcb36 Author: Chuck Lever Date: Tue Sep 8 19:12:56 2026 -0400 rpcrdma: arm rn_done before publishing the notification [ Upstream commit 5b06f706374c37375bdff9d21cc10e61df925a92 ] rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref. Fixes: 7e86845a0346 ("rpcrdma: Implement generic device removal") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260601201703.46078-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c4efdc1d4cb3e9183e41a1b2a5e0901dbbb31cdf Author: Jiri Olsa Date: Tue Sep 8 08:48:13 2026 -0400 bpf: Disable preemption in bpf_get_stackid [ Upstream commit 15f1bd8574662f1b7b26aaa2e23ebf4066f0117d ] The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled. Fixes: d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE") Reported-by: Tao Chen Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803210149.296496-6-jolsa@kernel.org Closes: https://lore.kernel.org/bpf/20260206090653.1336687-2-chen.dylane@linux.dev/ Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1e97925827c5059fec3610e95aed4c9a3dfec79 Author: Jiri Olsa Date: Tue Sep 8 08:48:12 2026 -0400 bpf: Use stack id functions instead of __bpf_get_stackid [ Upstream commit 09b3fd6caa0b57f8a39254ee5db3af30bdd53c18 ] Replacing __bpf_get_stackid calls with sequence of following functions: stackid_fastpath stackid_new_bucket stackid_install This makes code more structured and allows us to easily disable preemption only in bpf_get_stackid in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-5-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3024de68b817440040f26f2a56a666d708c95ec Author: Jiri Olsa Date: Tue Sep 8 08:48:11 2026 -0400 bpf: Factor stackid_new_bucket from __bpf_get_stackid [ Upstream commit bb4e6f4e1b68fe60c04ca04c564c6624e837dbf4 ] The new stackid_new_bucket allocates the new bucket and initializes it with the trace data. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-4-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 370069c1f627c2bb910eea768065e434eb7ed562 Author: Jiri Olsa Date: Tue Sep 8 08:48:10 2026 -0400 bpf: Factor stackid_fastpath function from __bpf_get_stackid [ Upstream commit 0ca56befcffec3a6c9d1842eae06c74e1cf41f11 ] The new stackid_fastpath does the fast stack hash and trace check, that does not need new bucket allocation. It covers both just-ip and buildid code paths. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-3-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8cf96ff8c113a54a9055c1d09adad032706bede Author: Jiri Olsa Date: Tue Sep 8 08:48:09 2026 -0400 bpf: Factor stackid_init function from __bpf_get_stackid [ Upstream commit 15b837759a97237d647962f9943afe0d55af615a ] The new stackid_init function stores all the necessary bits for stackid trace and it will be used by other functions in following changes. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260803210149.296496-2-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8cc98db4fc590e6c7d9db6529320982ee16c5d1d Author: Abdifatah Suruur Date: Sat Aug 29 18:40:22 2026 +0300 ksmbd: fix use-after-free in oplock break notification commit 0e753899627b5e28a9fea8bca98262a6f65a2452 upstream. smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. Fixes: b003086d7696 ("ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 88abd367fe8a7d21506fd7d76549419e27962896 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:06 2026 +0400 drm/nouveau/gsp: fix vblank interrupts on GB20x commit 5bb489b333237c1bf63a891a4362986253a0060a upstream. The GSP path programs per-head timing (vblank) interrupts the same way on every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend around four message-based kernel vectors (high latency, low latency, PMU, and GSP) and moved RM head-timing interrupts to the dedicated low-latency vector: - The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from 575.51.02 on, and v05_01 dev_disp.h). - The vector is reported as a separate interrupt table entry, MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors). - The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) at 0x611f34 after servicing (kdispServiceInterrupt -> kdispIntrRetrigger_v05_01). The event latch (0x611800), per-head status (0x611c00), and dispatch summary (0x611ec0) the interrupt handler uses are unchanged on GB20x (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 remain for DISPv0502+). On GB20x the old code enables head timing onto the legacy vector, leaves its handler there, and never re-arms the message-based vectors. Page flips still complete (nv50 sends those events from the commit path), so the desktop looks fine while DRM vblank waits and vblank sequence queries are affected. Supply GB20x vblank enables and an interrupt handler that re-arms the vector after servicing through gb202_gsp_disp, translate the low-latency interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to that instance. GB20x was the last cross-file user of the TU1xx vblank enables, so make those static and drop their head.h prototypes. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 37ae6066f65e66052a395c87be84d4ed38f44413 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:05 2026 +0400 drm/nouveau/disp: fix head state readback on GB20x commit 9421dfe912e55360e6b9301a110acb00df7e7320 upstream. The GSP path reads armed head state and the RG scanout position through gv100_head_state() and gv100_head_rgpos() on every generation. gv100_head_state() reads the core channel's state mirror at a 0x400 per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800, while the mirror bases are unchanged (assembly at 0x680000, armed at +0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on DISPv0502). Add gb202_head_state(), the same readback at the 0x800 stride, and a gb202_gsp_head table to supply it. gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800 stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00 still reads NV_PDISP_RG_DPCA on DISPv0502. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 37a758989faa584e482798fc30a4414608605f4d Author: Mohamed Ahmed Date: Tue Aug 25 04:14:03 2026 +0400 drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x commit 764deff8450c9a83e335c17c32ea258ec25bb71e upstream. The GSP path brackets audio enablement with a General Control Packet AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted and the old generic and VSI units are gone (ACR keeps slot 2) and the GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack 0x6f004c from NVIDIA's published clc971.h. The same offsets are also used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The old addresses are reserved on GB20x, so the AVMute writes were silent no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio() already sends through the SET_OD_PACKET RM control. Add a GB20x GCP writer using the new offsets and hook it into gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware as on earlier chips. Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP fields are generated (hardware or from the driver, with the default being HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 20ca0fdad658ef4d1ba36f62d2ed96e2d74f7fd9 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:02 2026 +0400 drm/nouveau/disp: fix HDMI vendor infoframes on GB20x commit 92f09dcb4e8473ab25764e950994ab7b6abce6dd upstream. The GSP path reuses the GV100 direct-MMIO infoframe writers on every chip. On GB20x that is only half right as while the legacy SF AVI unit is unchanged, the legacy VSI unit at 0x6f0100 was removed, so gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor infoframe ever reaches the HW. This affects HDMI-VIC signalling which can impact some 4K modes for legacy HDMI 1.4 sinks. GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's published C971/CA71 DISP_SF_USER class headers, only three legacy units remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor infoframes must instead be sent through the shared generic infoframe units at +0x130, whose 9-dword packet slots are loaded through the shared data port at +0x3f0/+0x3f4. Add a VSI writer using the same programming sequence OpenRM uses on these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable the unit and wait for it to idle, clear the SENT status, write the packet through the data port with a zero inserted in HB3 after the three header bytes, then enable the unit for every-frame transmission during vblank. Generic unit 1 is used for the VSI, matching the slot assignment in NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved for extended metadata packets and unit 2 for the HDR DRM infoframe, if those are wired up later). GB20x so far shared GA10x's display entry point. Give it its own, gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI writer to the GSP path and otherwise carries the same hooks as GA10x. The following fixes fill in the rest of the GB20x differences there. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit dbcaa9d0e9ee593099a1a0ef1922d96041736c22 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:01 2026 +0400 drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks commit 9886aad51f4b5e7082209a153e404bcd8101356c upstream. The GSP-RM display code in rm/r535/disp.c borrows a few register-programming routines from engine/disp (the head-timing interrupt handler, vblank enables, armed head state and scanout position readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so far picked them by name, which means it has to know which chip it runs on the moment a generation changes any of them. Give nvkm_disp_func a .gsp table that each chip fills with exactly those hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards) carrying the current functions, hand them to r535_disp_new() instead of the full hardware tables, and make rm/r535/disp.c call through the hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and the interrupt handler comes from the table. The tables are per chip even though the two currently coincide, so a generation that changes a hook only touches its own file. rm/r535/disp.c no longer contains chip-specific register code, and a new display generation only has to provide its own table. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit a1db244bb28281ef519787409ef6e26f139f4245 Author: Mohamed Ahmed Date: Tue Aug 25 04:14:00 2026 +0400 drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp commit eb1ffc3dc72d379a41e367a44b99fb61a15bf8ba upstream. r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying the same General Control Packet, and the audio mute-stream toggle) with a direct write of the GCP AVMute bit through the SF GCP unit. The controls are RM and stay, but the direct write is register programming and moves next to the other per-chip display code as tu102_sor_hdmi_gcp(). No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0cec2ceb5d9551e8d3e031c2f6b3c5a3ad7fbd3f Author: Mohamed Ahmed Date: Tue Aug 25 04:13:59 2026 +0400 drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c commit c6659e0ffc19b4ef0b3273c185cb8409a154eada upstream. The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO routines: the head-timing (vblank) interrupt handler and the per-head vblank enable/disable. They program display registers, not RM, so they belong with the rest of the per-chip register code in engine/disp/. Move them to tu102.c (Turing is the first GSP-capable generation) as tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for rm/r535/disp.c, which keeps calling them by name for now. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit c60033c172420179b7bbb3d1f843f8dc90164dc5 Author: Zhenhao Wan Date: Tue Aug 11 16:46:30 2026 +0800 drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE commit 38a62306c4266bcb3cd89e33c7111ee33096ebb3 upstream. A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 4083d24c2636fde7b18076115af52820d203bc57 Author: Zhenhao Wan Date: Tue Aug 11 16:46:29 2026 +0800 drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE commit ccf930812f23b8259ef64fd3394d53b093e4651a upstream. In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 3857238de6bce6c1573e8cb86c37b067e5208f05 Author: Zhenhao Wan Date: Tue Aug 11 16:46:28 2026 +0800 drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op commit 412a6ceb56d501ef2f8202e26ab4b5d4dfbca566 upstream. Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 4f3f9deca7e796deeee2eab67654749a70760d04 Author: Faith Ekstrand Date: Fri Aug 21 23:42:59 2026 -0500 drm/nouveau: Use write-combined maps for coherent commit 774b73428e6eabb4f0382aeeb76e569c7b106a29 upstream. On Tegra devices, uncached maps translate to device memory, causing unaligned accesses by userspace resulting in a SIGBUS. Instead, use write-combined maps to ensure proper access. This would also affect discrete cards on any Arm device. It was determined that discrete cards regardless of cpu arch should use write-combined maps for coherent anyways. Thus this change is made for all gpu types. Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand Co-developed-by: Aaron Kling Signed-off-by: Aaron Kling Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time") Link: https://patch.msgid.link/20260821-tegra-coherent-wc-v2-1-2b1ddb67bf18@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 1fef7553dc628295c1208a4f2ac2094c62886e5d Author: Marek Czernohous Date: Thu Aug 13 01:13:27 2026 +0200 drm/nouveau: unsubscribe the channel-kill event before the fence context commit 511585987d27d8cb668acebd399fc4deda23404c upstream. nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com Signed-off-by: Greg Kroah-Hartman commit ae5d57131dbff461b069d8b1dd8c20bce8e1caae Author: Mohamed Ahmed Date: Tue Aug 25 04:14:04 2026 +0400 drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmware commit 39fd4b742720c68da8695ee1ffa85c5fea4f8e11 upstream. NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled, MvidWarParams} block from the SST sub-struct of NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases (compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct. Everything nouveau writes sits at identical offsets in both layouts except the trailing SST.bEnableAudioOverRightPanel (written as zero), but the size is wrong on r570, which means r535_sor_dp_sst() and r535_sor_dp_vcpi() are sent with an incorrect size. Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the existing implementation for r535 and add an r570 implementation built against the 570.144 layout, which already exists in r570/nvrm/disp.h but was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM define that was missing from the layout. Other DP controls sent through shared r535 code did not change layout between the tags. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4deb29b9d33bfdb3de4d2d9944947ecf77221e42 Author: Zhenhao Wan Date: Tue Aug 11 22:28:50 2026 +0800 drm/nouveau/dmem: fix mismatched DMA unmap size for large folios commit caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f upstream. Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-1-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 0163b92946d0a7c816f619c57a4d9867954dd106 Author: Zhenhao Wan Date: Tue Aug 11 22:28:51 2026 +0800 drm/nouveau/dmem: fix callocated underflow on large folio split commit c2256c044a1df39c8aad4dd2d6f709b2533e2d7a upstream. nouveau_dmem_folio_free() drops chunk->callocated once per freed folio, while a large (compound) device-private folio is only counted once when it is allocated. When such a folio is split, the mm core invokes ->folio_split() (nouveau_dmem_folio_split()) once for each new sub-folio, but the hook only fixes up the sub-folio metadata and leaves chunk->callocated unchanged. Each resulting sub-folio is later freed separately, so after a split the single allocation (+1) is met by N frees (-N), leaving chunk->callocated short by N-1. On the first split/free cycle it underflows: WARN_ON(!chunk->callocated) fires, the unsigned counter wraps and never returns to zero, so the chunk can no longer be reclaimed (nouveau_dmem_fini() also warns on the leaked count). Account for the new sub-folio in the split hook, under the same lock as nouveau_dmem_folio_free(), so the count stays balanced. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-2-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 10e92e18e3dab081789d868878f2ecce6166948a Author: Matthew Brost Date: Tue Sep 1 23:35:04 2026 -0700 drm/pagemap: Fix folio allocation fallback and use-after-put commit df72e55e754c8d449321ddddad19a8bd3cb8d032 upstream. drm_pagemap_migrate_populate_ram_pfn() had two issues when populating RAM PFNs with higher-order folios: 1. The higher-order vma_alloc_folio()/folio_alloc() calls did not pass __GFP_NOWARN, so a THP allocation failure under memory pressure would spam the kernel log, and there was no fallback path despite a TODO comment stating one was needed. Add __GFP_NOWARN to the higher-order allocation and, on failure, fall back to order-0 allocations for the entire range originally covered by the failed higher-order allocation, leaving MIGRATE_PFN_COMPOUND unset for those PFNs. 2. In the free_pages error path, order was computed via folio_order(page_folio(page)) *after* put_page(page) had already dropped the reference, resulting in a use-after-free/put when that was the last reference on the page. Compute order before releasing the page. Introducing the fallback in 1. also requires the source page array handed to ->copy_to_ram() to be built differently. Both callers only populated the entry at the head of each source folio, relying on the copy callback to derive the rest of the folio from the order recorded in the matching drm_pagemap_addr. Once the destination has been demoted to order-0 folios the drm_pagemap_addr entries are per-page, so a source page is needed for every one of them; leaving them NULL makes the copy callback stop after the first page and the remainder of the range is never copied. The source folio is only split later, by migrate_vma_pages() / migrate_device_pages(), so its order cannot be used to detect the demotion - test the destination for MIGRATE_PFN_COMPOUND instead. Factor the array population out into drm_pagemap_migrate_populate_src_pages() and use it from both drm_pagemap_evict_to_ram() and __drm_pagemap_migrate_to_ram(). Fixes: ddeda6136038 ("drm/pagemap: Allocate folios when possible") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-5 Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260902063504.3024362-2-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit f34f8b904592e183b3971a8c9c4aeed8153aca18 Author: Shixiong Ou Date: Fri Jul 31 19:17:29 2026 +0800 drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug commit 958f35cbb8955ca3fa439cd9f2092cb42414aa8c upstream. The is_avivo() function has a logic error where it compares a constant to another constant instead of checking the device parameter: (PCI_VENDOR_ID_ATI_R600 >= 0x9400) Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Fixes: f496834e1674 ("drm/ofdrm: Add per-model device function") Signed-off-by: Thomas Zimmermann Cc: # v6.2+ Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit d9daf9a6e7a6f82ef338a09386eefc6807100d3f Author: Shixiong Ou Date: Tue Aug 25 18:41:34 2026 +0800 drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation commit c6f48e59ece0123f6a11527ad4d89b21c2d65b87 upstream. The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c. Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Cc: # v6.2+ Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit bbdc6761c55662fb9ddf5ab580acb616131998fe Author: Thomas Zimmermann Date: Thu Jun 25 11:39:36 2026 +0200 drm/sysfb: simpledrm: Improve stride validation commit df6533f11688aa30be3bb883c7637f4ffdbb7cbd upstream. Validate the computed stride against the maximum value INT_MAX. Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 7bfa5c7b28d6 ("drm/simpledrm: Compute linestride with drm_format_info_min_pitch()") Cc: # v6.1+ Link: https://patch.msgid.link/20260625094509.157581-5-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 48c60b763a0ddb98d58217af00bcecfbf12eb7b3 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:34 2026 +0200 drm/sysfb: simpledrm: Improve panel-size validation commit 3a75a0761914d01c7362adf1f906cc1d1762c189 upstream. Validate the panel size from the device-tree node against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail transparently on errors; do not warn. v3: - move comments to a more prominent place (Thierry) v2: - only use initialized values in debugging output (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 2a6d731a8f16 ("drm/simpledrm: Allow physical width and height configuration via panel node") Cc: Rayyan Ansari Cc: # v6.4+ Link: https://patch.msgid.link/20260625094509.157581-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 5683b1b2a60909d458f20dc81e037d7df1bf9951 Author: Thomas Zimmermann Date: Thu Jun 25 11:39:33 2026 +0200 drm/sysfb: simpledrm: Improve framebuffer-size validation commit 03f1a3545b721fa7fdadd00080e237519a286a97 upstream. Validate the framebuffer size from the firmware against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail probing on errors. v2: - remove unused function simplefb_get_validated_int0() (Sashiko) Signed-off-by: Thomas Zimmermann Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: # v5.14+ Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Link: https://patch.msgid.link/20260625094509.157581-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 62e744babd0b52509848cbd20c372b70bcbc4532 Author: Sunday Clement Date: Thu Aug 6 10:59:34 2026 -0400 drm/amdkfd: Reject zero-sized AQL queue allocations after size halving commit 40ba09e11188d1b7f79d51fc28aca5ea45e0c138 upstream. KFD_IOC_ALLOC_MEMORY_OF_GPU with flag KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM and size=1 triggers the AQL wraparound workaround (size >>= 1), reducing size to 0. The resulting zero passes through PAGE_ALIGN(0) = 0 without validation, bypassing the per-process VRAM quota check in reserve_mem_limit() (vram_used + 0 > vram_available is always false). The fix adds post-halving zero-size validation in the primary allocation path (amdgpu_amdkfd_gpuvm.c). The check happens after size halving but before reserve_mem_limit(), and uses err_alignment_size error path to properly clean up the allocated kgd_mem structure and mutex. Cc: stable@vger.kernel.org Signed-off-by: Sunday Clement Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c643c229babe2e8efc5eefe60e19d44868a643ff Author: Vladimir Marioukhine Date: Wed Aug 12 12:58:12 2026 -0400 drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore commit 6aa530642f95d5c48aa336416f94a35e7949b647 upstream. Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd(). Fixes: 48f0bdf4e38e ("drm/amdkfd: Added MQD manager files for GFX12.") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0a9a0e8a97da70a0336c9115178aaf1be29bcfb1 Author: Xiaogang Chen Date: Sun Aug 23 15:47:15 2026 -0500 drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram commit 520e345ffe05aabef1db82beda4288afb1757ff2 upstream. When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 58e866711b234571b0ce342c43d153a4786b32b8 Author: Mario Limonciello Date: Mon Aug 31 08:00:51 2026 -0500 drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds commit 012a026bae0212952b423a842b7e2c0bf21f8e7a upstream. Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD queue triggers a NULL pointer dereference because the for loop that calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the if (pqn->q) block that initializes mqd_mgr. The queue list can contain entries where pqn->q is NULL (kernel queues where only pqn->kq is valid). In the original code: if (pqn->q) { ... mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type]; size = mqd_mgr->mqd_stride(...); } for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block mqd = q->mqd + size * xcc; r = mqd_mgr->debugfs_show_mqd(m, mqd); } When iterating over a queue node where pqn->q is NULL: 1. The if (pqn->q) block is skipped 2. mqd_mgr remains uninitialized (NULL from declaration) 3. The for loop executes anyway 4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode RIP: 0010:0x0 Call Trace: pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu] kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu] seq_read_iter+0x132/0x4b0 ... Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr and related variables are only used when properly initialized. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689 Reviewed-by: Alex Deucher Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a2035918a7a1d8fd3bb79d22e1e149294a5a8418 Author: Xiaogang Chen Date: Sun Aug 23 15:22:54 2026 -0500 drm/amdkfd: Fix error path at svm_migrate_copy_to_ram commit 960c4a8069bfd352c48cc88592618f1ebe24c69e upstream. If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6aae545c87087e4dc96e205452243813bfa73ba2 Author: Priya Hosur Date: Thu Aug 27 15:02:46 2026 +0530 drm/amdkfd: Add TLB flush after MES queue eviction/suspension commit 94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 upstream. MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. Signed-off-by: Priya Hosur Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6decb921f7c58f139a62673dfdd34261a6adc27e Author: Sunil Khatri Date: Thu Aug 27 20:33:35 2026 +0530 drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c upstream. For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4e651478656b5a4d03a50caa7307f6751d2d02db Author: Sunil Khatri Date: Mon Aug 31 20:18:31 2026 +0530 drm/amdgpu: update the fw version for gfx12 userqueues commit 49a74a2388528c1a2e96f01114c4513e635605fe upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bcc58f2ef7708ab0a770ceb96756fc0e0db66402 Author: Sunil Khatri Date: Mon Aug 31 20:17:17 2026 +0530 drm/amdgpu: update the fw version for gfx11 userqueues commit c748dd03df33360549ad60cdccee13570e9c0f90 upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c931aedaf18c9c88335c39b8caef4c2ab115343f Author: Kanala Ramalingeswara Reddy Date: Mon Aug 31 19:59:11 2026 +0530 drm/amdgpu: Skip accessing psp rum time db for APUs commit a26301203a196a991527f7b1ab884d4dd0e7c95e upstream. Psp runtime DB is for dGPUs only. Signed-off-by: Kanala Ramalingeswara Reddy Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ebe7542553d008e2285e0fbba0c63f0295a7e694 Author: Jesse Zhang Date: Thu Aug 13 12:27:53 2026 +0800 drm/amdgpu: force complete the MES ring fences on reset commit 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 upstream. The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0]. Cc: stable@vger.kernel.org Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bdd6a58743e00ebc6d52b9cdf9aafb4e535e0b71 Author: Jesse Zhang Date: Thu Aug 13 12:28:04 2026 +0800 drm/amdgpu: force complete the KIQ ring fences on reset commit fd65d1742992361fc2201ecb4e43411e6e417fcb upstream. Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back. Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq. Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Suggested-by: Alex Deucher Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4614011a844b4f048d79022dd54554604b5808d8 Author: Sunil Khatri Date: Thu Aug 27 21:00:22 2026 +0530 drm/amdgpu: fix Idle BOs list in VM debugfs status info commit 90ce19bd11b2864e26e4b43e7acbffabf037b69b upstream. amdgpu_debugfs_vm_bo_status_info() prints the "Idle BOs" section by iterating lists->needs_update, the same list already printed just above under "Moved BOs". struct amdgpu_vm_bo_status has a dedicated idle list, populated whenever a BO's state machine settles, but it was never read here, so genuinely idle BOs never show up in the debugfs output and the "Idle BOs" section duplicates "Moved BOs" instead. Iterate lists->idle for the "Idle BOs" section. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Sunil Khatri Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 451bfc778a8c364841837def00ba15936f72762b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c41cc2632bd60929b0ee90248db0b0fb19984761 Author: Sunil Khatri Date: Mon Aug 31 21:01:39 2026 +0530 drm/amdgpu: fix byte/dword unit mismatch in coredump IB dump commit 3b5c4f4a479d0e58a7500cbd2b09d62f719f48b8 upstream. In amdgpu_devcoredump_print_ibs(), the NO_CPU_ACCESS VRAM path passed cursor.start/4 and cursor.size/4 to amdgpu_device_mm_access(), but that function's pos/size parameters are byte offsets/lengths (confirmed by amdgpu_ttm_vram_mm_access() and leading to wrong size calculation. Similarly with that change the off index needs to be calculated based on dword since that is a u32 type. Fixes: 7b15fc2d1f1a ("drm/amdgpu: dump job ibs in the devcoredump") Signed-off-by: Sunil Khatri Reviewed-by: Vitaly Prosyak Acked-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 1bd613b0ed98a23575b18674c94b8b3392614681) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 236ccf3ff9fde666f177f7b0d9ff7eff86408272 Author: Guangshuo Li Date: Sat Aug 8 20:09:34 2026 +0800 drm/amdgpu: fix autosuspend cleanup during removal commit ef5fcf2a6c320676bf8be2dadac93d9023b468b7 upstream. amdgpu_pci_probe() calls pm_runtime_use_autosuspend(), but amdgpu_pci_remove() does not call the matching pm_runtime_dont_use_autosuspend(). If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260808120934.2813010-1-lgs201920130244@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6ea36fc580cdb0ffb89a261ce011c8a2e0df5f72 Author: Yang Wang Date: Wed Aug 5 11:44:54 2026 +0800 drm/amdgpu: Disable runtime PM for externally attached dGPUs commit c52feb4365396b6a881b5e8a95540517ffabb3b7 upstream. pci_is_thunderbolt_attached() requires an upstream PCI bridge with is_thunderbolt set from an Intel Thunderbolt VSEC. This does not cover the affected ASM4242 USB4 PCI hierarchy: 00:02.2 \- 0f:00.0 [1b21:2421] +- 10:01.0 [1b21:2423] -> 45:00.0 -> 46:00.0 | -> 47:00.0 -> 48:00.0 -> 49:00.0 [1002:7590] \- 10:03.0 -> 76:00.0 [1b21:2425] USB4 Host Router The host router is outside the GPU upstream bridge chain, leaving no ancestor with is_thunderbolt set. PCI core propagates DEVICE_REMOVABLE below the external-facing PCIe tunnel. Disable Runtime PM when either pci_is_thunderbolt_attached() or dev_is_removable() is true. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Candice Li Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0bfb938182d1313e5cac32ae38dbaaa4eabe4af4 Author: Xiang Liu Date: Fri Aug 21 17:41:57 2026 +0800 drm/amdgpu: clamp the isolation index for rings outside a partition commit b30900566642ceb2c9e12b56c2afec28d0fd91a0 upstream. adev->isolation[] has one slot per partition, but a ring that is not assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing the array with it is out of bounds. SDMA submissions hit this on both the isolation enforcement and the VM flush path and trip UBSAN. Fall back to the first slot the way the cleaner shader path already does, and stop taking the address before the ring type check that makes it relevant. Cc: stable@vger.kernel.org Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4d030c3487074e4754c225dbcd92c0911adac758 Author: Pierre-Eric Pelloux-Prayer Date: Mon Jun 15 13:48:23 2026 +0200 drm/amdgpu: delay ttm buffer func enablement on xgmi commit c675dea86a000e9550077c5bca97c6431786d1b7 upstream. When amdgpu_init_minimal_xgmi is used, SDMA engines init is delayed so amdgpu_ttm_enable_buffer_funcs must be called later. Without this, the check for num_buffer_funcs_scheds will fail and using ttm buffer funcs later will fail. Given that amdgpu_ttm_enable_buffer_funcs is a no-op if amdgpu_in_reset() returns true, the call has to occur after the reset lock is dropped. Cc: stable@vger.kernel.org Fixes: e4029f7a9474 ("drm/amdgpu: only use working sdma schedulers for ttm") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fd4746ed0574d8a969535cac79b3a211a3ffe6a4 Author: Yang Wang Date: Wed Aug 12 11:08:40 2026 +0800 drm/amdgpu: check thunderbolt before switcheroo registration commit 8587d48d694da5aca580f92461658ec14470592b upstream. Introduce a helper to consolidate the vga_switcheroo registration condition used by the init and fini paths. Keep the explicit pci_is_thunderbolt_attached() check, as dev_is_removable() does not provide equivalent coverage for Thunderbolt-attached GPUs. This ensures such devices remain excluded from switcheroo registration while preserving the existing PX and Apple gmux handling. Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a46ab76b6cf5478e2ac7b942a377c7a1827b436a Author: Matthew Brost Date: Tue Jun 16 18:55:31 2026 -0700 drm/ttm: Drop tt->restore after successful restore commit 941ac10529b3be5965a88d432a161ab459672ba8 upstream. ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below. Fix this by freeing and dropping tt->restore in ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [  309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490 20547 [  309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [  309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [  309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [  309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [  309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [  309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [  309.850634] FS:  00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [  309.858749] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [  309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [  309.871678] PKRU: 55555558 20557 [  309.874403] Call Trace: 20558 [  309.876866]  20559 [  309.878988]  sg_alloc_table_from_pages_segment+0x60/0x100 20560 [  309.884415]  ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [  309.889845]  ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [  309.894045]  xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [  309.898037]  xe_bo_move+0x927/0xaa0 [xe] 20564 [  309.902029]  ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [  309.907022]  ttm_bo_validate+0xbe/0x190 [ttm] 20566 [  309.911405]  xe_bo_validate+0x9a/0x120 [xe] 20567 [  309.915663]  xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [  309.920206]  drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [  309.925459]  ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [  309.930627]  xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [  309.935428]  xe_exec_fn+0x20/0x40 [xe] 20572 [  309.939249]  drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [  309.944410]  xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [  309.949385]  xe_exec_ioctl+0x806/0xc30 [xe] 20575 [  309.953639]  ? ttwu_queue_wakelist+0xd9/0xf0 20576 [  309.957935]  ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [  309.962449]  ? __wake_up_common+0x73/0xa0 20578 [  309.966482]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [  309.971263]  drm_ioctl_kernel+0xa3/0x100 20580 [  309.975209]  drm_ioctl+0x213/0x440 20581 [  309.978637]  ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [  309.983415]  xe_drm_ioctl+0x67/0xd0 [xe] 20583 [  309.987408]  __x64_sys_ioctl+0x7f/0xd0 Cc: Thomas Hellström Cc: Christian Koenig Cc: Huang Rui Cc: Matthew Auld Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages") Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260617015531.1164189-1-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit e6195b941fdc8d81fc431c9f25539cf6c6234b51 Author: Thadeu Lima de Souza Cascardo Date: Mon Jul 27 17:45:49 2026 -0300 drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used commit 4d4be202165e832d74849b4a68e289a2a377039c upstream. Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms. Fixes: 24835e442f28 ("drm: reference count event->completion") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com Signed-off-by: Greg Kroah-Hartman commit d152b582d852c53af78e9acbf098c751b9107d2a Author: Kavan Smith Date: Mon Jul 6 18:32:40 2026 -0700 drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value commit 6cd33b6f4155efc20485929fd0b56bb704641db9 upstream. MSM8916 runtime DSI commands still go through msm_dsi_host_xfer_prepare(), which re-applies the link clock rate before enabling the link clocks. That is fine in principle, but on DSI 6G the requested byte clock rate often does not exactly match the DSI PHY PLL's realizable rate. For example, the driver can request 56250000 Hz while the PLL actually runs at 56246337 Hz. Because the requested and actual rates differ slightly, every later link_clk_set_rate() call is treated as a real clock change and re-locks the PLL. On a video-mode panel without an internal timing generator, such as samsung,s6d7aa0 / lsl080al03 on MSM8916, that live-clock glitch makes the panel lose pixel lock and visibly corrupts scanout on each runtime DCS command, including backlight writes. Fix this by rounding the computed 6G byte clock rate up front, before it is stored in msm_host->byte_clk_rate and reused by later transfers. Once the host carries the PLL-achievable rate instead of the idealized one, repeated link_clk_set_rate() calls become no-ops in the common clock framework and no longer re-lock the PLL. This keeps the normal transfer callback sequencing intact, preserves the OPP vote path in link_clk_set_rate(), and matches the fix direction suggested in the original 2018 discussion. Reported-by: Daniel Mack Closes: https://lore.kernel.org/all/1a682c5b-7fc9-3aaa-120b-64b239a355a3@zonque.org/ Fixes: 6b16f05aa39f ("drm/msm/dsi: Split clk rate setting and enable") Cc: stable@vger.kernel.org Signed-off-by: Kavan Smith Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/738234/ Link: https://lore.kernel.org/r/20260707013240.681012-1-kavansmith82@gmail.com [DB: dropped extra chunk from the patch] Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit eab46d9629807db1b5647d17227e16110a18227f Author: Tao Yu Date: Wed Aug 19 15:28:35 2026 +0800 drm/gud: validate TV mode names before creating enum property commit da1ea35fea67ad841f4ada28dd61b41be65e5437 upstream. The GUD protocol returns TV mode names as fixed-size GUD_CONNECTOR_TV_MODE_NAME_LEN entries and requires each name to be NUL-terminated. gud_connector_add_tv_mode() currently passes each fixed-size entry directly to drm_mode_create_tv_properties_legacy(), which eventually reaches drm_property_add_enum() and strlen(). If a device returns an entry without a terminating NUL byte, strlen() reads past the end of the slot and can run beyond the allocated buffer, triggering an out-of-bounds read. Validate that each returned TV mode name contains a NUL terminator within its fixed-size slot before passing it to the DRM property code. If a malformed entry is found, reject the device response with -EIO. This fixes the out-of-bounds read without changing the handling of valid devices, and avoids silently truncating malformed protocol data. Reported-by: syzbot+9ae8e7884e451eaed5b4@syzkaller.appspotmail.com Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Signed-off-by: Tao Yu Reviewed-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260819072835.4074130-1-tao1.yu@intel.com Signed-off-by: Greg Kroah-Hartman commit 6ea61f1d4cbaa0db937e31bffc041fb8afeacf52 Author: Deepanshu Kartikey Date: Sun Aug 16 14:22:34 2026 +0530 drm/gud: NUL-terminate TV mode names read from the device commit 500cb24cd61bad8a2747ddfc49b7034899c82d94 upstream. gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=916c888ba5f1a54c9526 Tested-by: syzbot+916c888ba5f1a54c9526@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Acked-by: Ruben Wauters Cc: Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260816085234.22053-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9ae19bd60891bea0a7b7504cc8dbfe74570ac3b3 Author: David (Ming Qiang) Wu Date: Fri Aug 7 15:12:14 2026 -0400 drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check commit 4d7390530853eb7befda9cc786e4c86e8ad7ac9e upstream. If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier "header does not fit in BO" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: stable@vger.kernel.org Signed-off-by: David (Ming Qiang) Wu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 25ad527dc92aa62be2035cd5b585a25e02eb4486 Author: Alex Deucher Date: Thu Aug 20 09:02:01 2026 -0400 drm/amdgpu/gfx8: only apply compute quantums to KCQs commit 7346a046c6a9b9f30cb1f7d301449300a9174c71 upstream. Don't apply to KIQ. Seems to cause problems on KIQ on some ARM platforms. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5658 Fixes: 91cf34bc5a55 ("drm/amdgpu/gfx8: align mqd settings with KFD") Reviewed-by: Jesse Zhang Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 6aae7bab029cdccae9a7157facfe36bfc35fc940) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2d2071d673039a5f454cbe5dda1aab8a3589055e Author: Roman Li Date: Fri Aug 14 18:03:17 2026 -0400 drm/amd/display: Set gpuvm min page size to 4K on dcn35/36 commit 9ce3169430f1db035d491481086e2fae2552569c upstream. [WHY] Splash screen corruption on some 8K monitors. [HOW] Set GPUVM min page size to 4K for DCN35/36 to use the correct DML2 calculations, avoiding the corruption path observed during splash. Fixes: 115009d11ccf ("drm/amd/display: Add DCN35 DML2 support") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Roman Li Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 2cbfb03dead5088a7bdfe2ce392a5caa3d1b3719) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 647426f78a344eda02be2b7d2d2cd49cbd254d37 Author: Austin Zheng Date: Wed Aug 19 09:33:57 2026 -0400 drm/amd/display: Remove const Qualifier From Non-Pointer Fields commit 93a77d353cb26772ae2fba50ae7321ae996b7f00 upstream. [WHY/HOW] Integer values for dml2_core_calcs_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport_params should not have the const qualifier. This prevents using different values of the inputs when the function is called again. Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 342280aae4f33816e8d07c15cb538a3b375a7f8f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b10cc09b329245c6d95f8fa3e7f068575e3e0e9f Author: Harry Wentland Date: Tue Aug 4 17:04:05 2026 -0400 drm/amd/display: validate plane degamma LUT size for private color prop commit e4c3ab59021e7c146a84b6671f0d530972bd58b4 upstream. Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined. Fixes: 980f8710075a ("drm/amd/display: add plane degamma TF and LUT support") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3891405e6488536ad64e11c56727277480414320 Author: Timur Kristóf Date: Fri Aug 21 23:50:58 2026 +0200 drm/amd/display: Fix HPD consideration for VGA/LVDS connectors on DCE commit 52536ce677a3470c0e5323b940791efb33975450 upstream. After a refactor that landed in Linux 7.0, DC now crashes when it is initialized on GPUs that have a VGA or LVDS connector. This is because these connectors have no HPD so the hpd_gpio is NULL and therefore DC takes the code path meant for DCN 4.2+ which sets irq_source_hpd = 255 that causes the subsequent code to try to register the HPD interrupt, which fails, and causes a crash. This commit should be backported to Linux 7.0 and newer. Cc: stable@vger.kernel.org Cc: Dmytro Laktyushkin Cc: Roman Li Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5490 Fixes: def3488eb0fd ("drm/amd/display: refactor HPD to increase flexibility") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260821215059.312868-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit dac29cbb405b912742f4f7eda833cec8e7a53780 Author: Linkai Gong Date: Wed Aug 19 13:47:42 2026 +0800 drm/amd/display: fix dc_lock leak on GPU reset error paths commit 92a9eebd2a1f892fe482154d83f9f1626bc73d3b upstream. On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error. Fixes: 3cf7a0bc87f0 ("drm/amd/display: Catch failures for amdgpu_dm_commit_zero_streams()") Fixes: 2b6943df5413 ("drm/amd/display: Pass up errors for reset GPU that fails to init HW") Cc: stable@vger.kernel.org Signed-off-by: Linkai Gong Reviewed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 15ee43aad0df43dfd1dbb32e7d5b951745c4b87f Author: Harry Wentland Date: Tue Aug 4 17:04:04 2026 -0400 drm/amd/display: avoid divide-by-zero in __is_lut_linear() commit 4f40873f8a4107df2b9c8e68c947c4fd0cd519d2 upstream. __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero. Fixes: 086247a4b2fb ("drm/amd/display: Use 4096 lut entries") Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland Reviewed-by: Melissa Wen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ac908108d1977aca6f92db7df29ca53844ecf892 Author: Thomas Zimmermann Date: Thu Jun 18 14:28:39 2026 +0200 drm/hibmc: Use drm_atomic_helper_check_plane_state() commit 715c5db68bdbd4a524b79ebf20fb61e880fffea0 upstream. Call drm_atomic_helper_check_plane_state() from the primary plane's atomic-check helper and replace the custom implementation. All plane's implementations of atomic_check should call the shared _check_plane_state() helper first. It adjusts the plane state for correct positioning, rotation and scaling of the plane. Do this even if the plane's CRTC has been disabled by setting the parameter can_update_disabled. The original code returned early in this case, but it's safe to so and cleaner to have all plane state initialized. As we don't set can_position, drm_atomic_helper_check_plane_state()'s visibility check tests if the plane covers all of the CRTC. This is a small change from the original code, which tested if the plane is exactly the size of the CRTC. With the new test, the plane still has to cover all of the CRTC, but can be larger than the CRTC's size. A later patch can fully implement this feature in hibmc. If the plane is disabled, the helper clears the visibility flag in the plane state. On errors or if the plane is not visible, the atomic-check helper can return early. Implement all this in hibmc and drop the custom code that does some of it. v2: - extend the commit description (Yongbang) Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Baihan Li Cc: Yongbang Shi Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 93f36cf57c729cead879d0b78613e4ce0d06497b Author: Thomas Zimmermann Date: Thu Jun 18 14:28:40 2026 +0200 drm/hibmc: Fix list of formats on the primary plane commit 0e682e136c466ae37c62f18099f591c096260ee0 upstream. Remove all formats from the primary plane that are unsupported for various reasons. * Formats with alpha channel: planes should not announce alpha channels unless they support transparency. There's no transparency support in the primary plane's implementation. * Formats with BGR order. The common format is in RGB channel order. There's no BGR support in the primary plane's implementation. * RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the output is distorted. This can be tested by booting with video=1024x768-24. Removing all unsupported formats leaves XRGB8888 and RGB565. Both of which are supported and work correctly. Signed-off-by: Thomas Zimmermann Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine") Reviewed-by: Yongbang Shi Cc: Rongrong Zou Cc: Sean Paul Cc: Xinliang Liu Cc: Dmitry Baryshkov Cc: Yongbang Shi Cc: Baihan Li Cc: # v4.10+ Link: https://patch.msgid.link/20260618123142.92298-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit d8c055b34ab3a1948570d993a3d771bd1a6ce666 Author: Lyude Paul Date: Tue Apr 28 23:03:40 2026 -0400 drm/nouveau/disp/r535: Add scanline position support + head state support commit 804cb093b245c752f15d17186e0d404f10303593 upstream. That's right! It looks like this never actually got finished, something which I just noticed today when I saw this fun message spamming one of my test machine's kernel logs when enabling display debug output for nouveau: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal] crtc 0 : scanoutpos query failed. So it looks like we've been falling back to DRM's core fallback for a while now, whoops. So, while it seems that we do have the option of doing this through GSP - that doesn't seem like a great idea. Mainly because reading this from GSP would involve a lot more latency then we should have for vblank handling due to the RPC communication. So instead of implementing that, just use gv100_head_state and gv100_head_rgpos for implementing .state and .rgpos. It seems to work perfectly fine! Fixes: 9e9944449023 ("drm/nouveau/disp/r535: initial support") Cc: Ben Skeggs Cc: Dave Airlie Cc: Timur Tabi Cc: Ben Skeggs Cc: James Jones Cc: Faith Ekstrand Cc: Suraj Kandpal Cc: Lyude Paul Cc: Aaron Kling Cc: Danilo Krummrich Cc: Zhang Enpei Cc: # v6.7+ Signed-off-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260429030348.3930866-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 423fd96d094c1f5821feb46e3a272b910253719a Author: Amit Barzilai Date: Mon Jun 22 15:26:04 2026 +0300 drm/ssd130x: fix column and row end address in partial updates in ssd133x commit b7fcb70162acd7f15ed20bc64a14c150db34256f upstream. On partial screen updates, SSD133X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: b4299c936d8fd ("drm/ssd130x: Add support for the SSD133x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-4-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 956005c09cfd9a36a0359fe51286557b894f3606 Author: Wentao Liang Date: Sun Jun 7 03:09:50 2026 +0000 drm/sun4i: fix refcount leak in sun4i_backend_init_sat() commit f7a56ff6240e6fd0cb36a3c0a911a1cd54789ce2 upstream. When sun4i_backend_init_sat() calls reset_control_deassert() it increments the deassert_count of the reset controller, and must pair that with a reset_control_assert() call to decrement it. In the error path where clk_prepare_enable() fails, the function returns immediately without calling reset_control_assert(), leaking the reference count. Other error paths, like the devm_clk_get() failure, correctly jump to the err_assert_reset label which performs the missing assert. Fix the leak by using the existing err_assert_reset label in the clk_prepare_enable error path instead of returning directly. Cc: stable@vger.kernel.org Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT") Signed-off-by: Wentao Liang Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260607030950.83636-1-vulab@iscas.ac.cn Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit adadda76184eb5188edac26e048da189184f6f8d Author: Amit Barzilai Date: Mon Jun 22 15:26:02 2026 +0300 drm/ssd130x: fix column and row end address in partial updates for ssd132x commit 99e9c09358195454ecd200b9c6aba6b7d209fad4 upstream. On partial screen updates, SSD132X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: fdd591e00a9c9 ("drm/ssd130x: Add support for the SSD132x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260622122604.32500-2-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 84829e324a396668ceafb14723293b2863a74dcf Author: Deepanshu Kartikey Date: Thu Aug 13 12:19:02 2026 +0530 drm/i915: Guard against NULL driver_data in i915_pci_probe() commit 3785d40831ba5601296283e0197e10e089392757 upstream. pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com Signed-off-by: Jani Nikula (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 80e4fd48b90044aa2c55d51af6162bebc19c0c04 Author: Nemesa Garg Date: Tue Aug 18 15:21:49 2026 +0530 drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a upstream. icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after selective fetch had been turned off, the guard fired early and left the register's enable bit set in hardware. The bit is harmless until selective fetch is re-enabled. When it is, the hardware resumes fetching for the now-disabled plane and keeps its old DDB range reserved. i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL and is fixed the same way. v2: Add same check for cursor also. [sashiko] Cc: stable@vger.kernel.org Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739 Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Nemesa Garg Reviewed-by: Jouni Högander Signed-off-by: Animesh Manna Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com (cherry picked from commit 600a7c9d40e5e0c5544f42d1c9592c8d15224dc0) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 2d1215a72159d00001e08dee162e27718934bee9 Author: Danilo Krummrich Date: Sun Jun 28 16:53:36 2026 +0200 drm: fix race between partial drm_dev_register() failure and ioctl commit eb197f7d60f00d0f5b1b3505dfc86a7e36045a3e upstream. If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register(). Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620190648.2E9F61F000E9@smtp.kernel.org/ Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-17-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 972afe6d5314037556bf6b3e635d7a06547064ee Author: Johan Hovold Date: Fri Jul 17 16:31:18 2026 +0200 drm/panel-edp: fix i2c adapter leak on probe failure commit e2a9e291275a74e309a21cbb1def6296a72d6aed upstream. Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f7f61839ba3933d3008aa27fee52b11a9a36e463 Author: Johan Hovold Date: Fri Jul 17 11:08:19 2026 +0200 drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure commit 09b195a7bb23df56269cd2a95d01ba3a5533af13 upstream. Make sure to drop the i2c adapter device and module references before returning when detecting a malformed devicetree during probe. Fixes: 80e2f97968b5 ("drm: bridge: dw-hdmi: Switch to regmap for register access") Cc: stable@vger.kernel.org # 4.12 Cc: Neil Armstrong Signed-off-by: Johan Hovold Reviewed-by: Luca Ceresoli Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260717090819.1630965-1-johan@kernel.org Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 3e5c7cddc0073eef6f9bb373189b11a969f1f6f6 Author: Osama Abdelkader Date: Mon Jul 20 15:44:35 2026 +0200 drm/panthor: fix firmware control interface bounds checks commit 6a47f9fd2d970674ed9dedc52fc7ab76fd015785 upstream. panthor_init_cs_iface() and panthor_init_csg_iface() validate firmware control interface offsets with 32-bit arithmetic and the size of the host wrapper structures. The offsets are derived from firmware-provided strides, so the arithmetic can wrap before the bounds check, and the host wrapper size is not the size of the firmware control interface being mapped. Use 64-bit arithmetic for the computed offsets and validate against the actual firmware control interface structure sizes with subtraction-based bounds checks. Also validate that the shared section is large enough for the global control interface before using it. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260720134435.13377-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 6ae19dce3e8c13ae73590b3f4311abe9f96bbae8 Author: Osama Abdelkader Date: Mon Jul 20 13:32:11 2026 +0200 drm/panthor: harden firmware build-info bounds checks commit 8321b093fa6c297b80586460ce6914d9655df170 upstream. panthor_fw_read_build_info() checks whether the metadata range fits in the firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so the addition can wrap and let an out-of-bounds range pass validation. The function also reads the "git_sha: " prefix without first checking that the metadata is long enough, and meta_size == 0 can underflow the NULL terminator index. Use subtraction-based bounds checking and reject metadata that is too short to contain the expected prefix and trailing NULL byte. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patch.msgid.link/20260720113212.11981-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit c659ba693970224471210d4ad1f8eed91a26e6ee Author: Matthew Auld Date: Wed Sep 2 13:41:20 2026 +0100 drm/xe/vram: report FLAT_CCS base misalignment commit 0e68c74e44da81a4599c52437ee1f63a2c234470 upstream. So we can easily check if a machine had the CCS bug, when looking back over bug reports where we have the same machine with newer kernel. Example print for a machine with the CCS bug: FLAT_CCS base:27bbff800, aligned:no v2 (Matt B): - Unconditionally print the base + alignment Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Rodrigo Vivi Cc: stable@kernel.org Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260902124117.918018-9-matthew.auld@intel.com (cherry picked from commit d00b7f4f03bbeb2efad872f1686130e18c2b4141) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 967a179463d3227dfaf9200fd654c1f5a26a11e8 Author: Bob Zhou Date: Wed Aug 19 14:23:49 2026 +0800 drm/amdgpu: avoid force-completing uninitialized UVD rings commit 6760f5cb12d2366ddd58a2d8637f7583d73f596b upstream. uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized. Fixes: 0a33b11d26c6 ("drm/amdgpu: mark force completed fences with -ECANCELED") Cc: stable@vger.kernel.org Signed-off-by: Bob Zhou Acked-by: Leo Liu Acked-by: Frank Min Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3e234c6face8651045f46895dfe9c086ea64f03b Author: Thomas Hellström Date: Sat Jul 25 12:00:31 2026 +0200 drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() commit e773798e14ac0aea54ca9676083b91f445e5bc59 upstream. drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run. Reported-by: Sashiko-bot Closes: https://sashiko.dev/#/patchset/20260428073116.15687-1-thomas.hellstrom@linux.intel.com?part=4 Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM") Cc: Friedrich Vock Cc: Maarten Lankhorst Cc: Tejun Heo Cc: Maxime Ripard Cc: Christian König Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.14+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Arunpravin Paneer Selvam Reviewed-By: Maarten Lankhorst Tested-by: Thadeu Lima de Souza Cascardo Link: https://patch.msgid.link/20260725100036.2372-2-thomas.hellstrom@linux.intel.com Acked-by: Christian König Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit c42608c09b6b5d5967bf211c255914c068c2cde1 Author: Chao Yu Date: Tue Aug 11 15:16:37 2026 +0800 f2fs: fix to zero post-EOF data when extending file size commit 5eced87b7d19dbc76ebdddaf322046f9ac582fcb upstream. generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) # --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 # +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 # @@ -1,4 +1,16 @@ # QA output created by 794 # append_write # +FAIL: non-zero data in gap [4080,4096) after shutdown+remount # +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< # +* # +001000 # truncate_up # ... # (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option. Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 0b196c07407f48a41cd9741cf53e10cb1e23d2e5 Author: Chao Yu Date: Thu Aug 6 20:35:37 2026 +0800 f2fs: fix to pass folio->index to f2fs_sanity_check_node_footer() commit 7e188e9f9437ab47c3237d609f1b26348d6fea1a upstream. Otherwise in f2fs_sanity_check_node_footer(), it will check the same nid incorrectly. Cc: stable@kernel.org Fixes: 0a736109c9d2 ("f2fs: fix to do sanity check on node footer in __write_node_folio()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 153df7dc3aaeedb5ed99caf9fe2af8a2b7ab6db5 Author: Chao Yu Date: Wed Aug 12 12:17:54 2026 +0000 f2fs: fix to reclaim space in f2fs_allocate_pinning_section() commit fa487f56efba6344aef67d871688f0908fe08af3 upstream. It needs to trigger checkpoint to free space reclaimed by f2fs_gc_range(), otherwise, fallocate() on pinfile will fail easily even there is slash space in conventional zone. [Testcase] nullblk_create.sh 512 2 1024 1024 mkfs.f2fs /dev/nullb0 -f -m mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile mkdir /mnt/f2fs/dir/ for((i=0;i<3934;i++)) do { dd if=/dev/zero of=/mnt/f2fs/dir/$i bs=1M count=1;} done sync for((i=0;i<3934;i+=2)) do { rm /mnt/f2fs/dir/$i;} done for((i=0;i<1950;i++)) do { rm /mnt/f2fs/dir/$i;} done sync f2fs_io fallocate 0 0 $((1024*1024*1024)) /mnt/f2fs/pinfile sync stat /mnt/f2fs/pinfile f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile [Before] fallocate failed: Resource temporarily unavailable File: /mnt/f2fs/pinfile Size: 109051904 Blocks: 213208 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 20:04:02.264000000 +0800 Modify: 2026-08-12 20:04:26.784000000 +0800 Change: 2026-08-12 20:04:26.784000000 +0800 Birth: - root@localhost:~# root@localhost:~# root@localhost:~# root@localhost:~# f2fs_io fiemap 0 $((1024*1024*1024)) /mnt/f2fs/pinfile Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000002dc00000 0000000000400000 00001000 2 0000000000600000 000000002e400000 0000000000600000 00001000 3 0000000000c00000 000000007a400000 0000000005c00000 00001001 [After] File: /mnt/f2fs/pinfile Size: 1073741824 Blocks: 2099216 IO Block: 4096 regular file Device: 250,0 Inode: 4 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-08-12 19:47:49.428000000 +0800 Modify: 2026-08-12 19:49:06.808000000 +0800 Change: 2026-08-12 19:49:06.808000000 +0800 Birth: - Fiemap: offset = 0 len = 1073741824 logical addr. physical addr. length flags 0 0000000000000000 0000000002e00000 0000000000200000 00001000 1 0000000000200000 000000003aa00000 0000000000400000 00001000 2 0000000000600000 000000003b400000 0000000000200000 00001000 3 0000000000800000 000000007a200000 0000000005e00000 00001000 4 0000000006600000 0000000002800000 0000000000200000 00001000 5 0000000006800000 0000000003200000 0000000000400000 00001000 6 0000000006c00000 0000000003000000 0000000000200000 00001000 7 0000000006e00000 0000000003600000 0000000037200000 00001000 8 000000003e000000 000000003b200000 0000000000200000 00001000 9 000000003e200000 000000003a800000 0000000000200000 00001000 10 000000003e400000 000000003ae00000 0000000000400000 00001000 11 000000003e800000 000000003b600000 0000000001800000 00001001 Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 931e1aa4d44c52ff8e0feb38420a8827c62e886b Author: Chen Changcheng Date: Tue Aug 4 08:54:02 2026 +0800 f2fs: fix valid block count leak on data block allocation failure commit 0f9af07ecc1ab486038373db6ae0436c5d674b19 upstream. In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called. Fixes: 7d009e048d7c ("f2fs: fix to handle segment allocation failure correctly") Cc: Reviewed-by: Chao Yu Signed-off-by: Chen Changcheng Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit bee6dfcc111b1dffdb3e13d73b7028b699fa0165 Author: Wenjie Qi Date: Tue Aug 4 09:48:49 2026 +0800 f2fs: protect critical_task_priority updates with s_umount commit 8e4692c6c165e81b2cbb847d8da4b45a53483b33 upstream. The sysfs store path already takes s_umount for GC thread control entries, and ckpt_thread_ioprio is covered as well. critical_task_priority also updates checkpoint or GC kthread scheduling state, but it is not covered by that serialization. It can race with remount or teardown paths that are stopping those threads. Protect critical_task_priority sysfs writes with s_umount too. Fixes: 52190933c37a ("f2fs: sysfs: introduce critical_task_priority") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3923ec2b98c96dda4a8bfab81d22553dbf0dd6c2 Author: Chao Yu Date: Wed Aug 5 12:29:20 2026 +0000 f2fs: fix to clear dirty flag on folio in error path commit 5b86eab84ac8e9289b5afc52ef88ab18ba5bacab upstream. If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage. Cc: stable@kernel.org Fixes: b42b179bda9f ("f2fs: fix to do checksum even if inode page is uptodate") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 436cdabc64c10945c174594b530d62c5da65612f Author: Chao Yu Date: Tue Aug 11 15:16:36 2026 +0800 f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page() commit b2205d3cfd6c76fd5c5443ee9fdb498cfb0e1c66 upstream. Otherwise, it will drop one more page after new_size which is not necessary. Cc: stable@kernel.org Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit e88a37a6ec5d9ded23c662205c1af2d72155ca20 Author: Chao Yu Date: Wed Aug 5 12:20:08 2026 +0000 f2fs: fix to return -EFSCORRUPTED in f2fs_get_node_info() correctly commit 026d7aeadf27291f961893165edb6079a7078f6f upstream. Otherwise, it will cache wrong nat info in cache. Cc: stable@kernel.org Fixes: 3cb396a2c790 ("f2fs: fix to do sanity check on nat entry of quota inode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 4e85a62b0c27b41ec9ec8fcbf9c1eec71b191e7c Author: Zhan Xusheng Date: Tue Aug 18 22:55:35 2026 +0800 f2fs: fix i_size when pinned fallocate partially fails commit 0f448bb3767ef6119f5cdeabcae3f10d6e75aed6 upstream. From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 = block 511, so pg_start % sec_blks = 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 905411f6504876d268ba8dafc8e75367782da4b7 Author: Chao Yu Date: Mon Aug 24 21:17:29 2026 +0800 f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages() commit ce366bfa821ec81dd45bde547ee31e659306cc61 upstream. There is potential deadloop in race condition: Thread A Thread B - fsync - f2fs_do_sync_file - f2fs_fsync_node_pages - last_fsync_dnode - folio_get(last_folio) - f2fs_setattr - f2fs_truncate - f2fs_truncate_blocks - f2fs_do_truncate_blocks - f2fs_truncate_inode_blocks - truncate_dnode - truncate_node - invalidate_mapping_pages - folio->mapping = NULL - is_node_folio alwasy return false - atomic && !marked is always true, then goto retry Cc: stable@kernel.org Fixes: 608514deba38 ("f2fs: set fsync mark only for the last dnode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit b9776094aa7118e8e5dfdcd791ffc8330c5ca408 Author: Daeho Jeong Date: Wed Aug 19 11:06:35 2026 -0700 f2fs: fix to migrate all curseg types during free_segment_range commit 8ec06f50ddd8d201bd7e55b896ae28ed9d4cb7d1 upstream. In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range. Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 8f3b99c50dd0da1777994ce7c7e60d39b9f60f4b Author: Wenjie Qi Date: Tue Aug 4 09:48:48 2026 +0800 f2fs: avoid NULL checkpoint thread access in sysfs commit 5cb33b00c8fbb6e8f1fa3d281c3036d5f7c7c41f upstream. checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio. Fixes: e65920661708 ("f2fs: add ckpt_thread_ioprio sysfs node") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit cc34df18da92f68f9b384c3ae95ad64be46cb5ee Author: Zhaoyang Huang Date: Mon Jul 13 19:19:44 2026 +0800 f2fs: fix folio_nr_pages() race after put in large folio invalidate commit 0dab71381f1b4d12dc2056f8bd5aaa9d93ce9082 upstream. Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10 Cc: stable@kernel.org Fixes: 05e65c14ea59 ("f2fs: support large folio for immutable non-compressed case") Reviewed-by: Chao Yu Signed-off-by: Zhaoyang Huang Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 93a3e6a4c9e726a13a935963e8dc43d181db1527 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 19 16:45:14 2026 +0800 f2fs: fix dentry folio leak in find_in_level commit cca7d3e30bf30333314e31bc70b9a739f1342167 upstream. find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller. Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 99d14d61aa8beb6cb9a984b9fcddd45e35b24494 Author: Chao Yu Date: Mon Jul 6 12:33:21 2026 +0000 f2fs: embed f2fs_gc_kthread in f2fs_sb_info commit 3d7bca9d583793bb7d0bac0d95a24ddd2e129eed upstream. Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store - remount|shutdown - f2fs_stop_gc_thread - access sbi->gc_thread - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task Fixes: 52190933c37a ("f2fs: sysfs: introduce critical_task_priority") Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown") Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 34d9717097485b1f459082bb68ef68e55903c14b Author: Chao Yu Date: Mon Jun 29 11:49:18 2026 +0000 f2fs: fix to avoid potential section-unaligned pinfile commit d0a481fad5c7a3a56ecf54a099651216869f4d0a upstream. Blocks of pinfile may not aligned to section size due to wrong use on pinfile, result in heavy overhead of GC, let avoid this by adding additional check condition in f2fs_setattr(). - truncate -s 8mb pinfile : random checkpoint may persist filesize w/ inode - fallocate -o 0 -l 8mb pinfile - f2fs_fallocate - f2fs_expand_inode_data - f2fs_allocate_pinning_section - f2fs_map_blocks - f2fs_map_lock - __allocate_data_block - file_need_truncate : w/ FADVISE_TRUNC_BIT, we can expect unaligned mapping can be truncated while open() if f2fs is not umount abnormally - f2fs_map_unlock : following f2fs checkpoint and sudden power-cut - mount - open pinfile - f2fs_file_open - finish_preallocate_blocks - truncate_setsize : filesize is 8mb - f2fs_truncate : can only truncate block outside filesize, rather than truncating unaligned blocks inside filesize Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Cc: stable@kernel.org Cc: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 47a4aaa56622630ab993fbbe3eb36d89301b82e6 Author: Zhan Xusheng Date: Tue Jun 23 15:26:41 2026 +0800 f2fs: don't drop the top folio order in the f2fs_iostat tracepoint commit 575f6f8ef2abe8552af96e42c65d70964db53563 upstream. The f2fs_iostat tracepoint stores the per-order read folio counts in a fixed-size array and prints a fixed number of buckets, both hardcoded to 11. The sysfs iostat accounting array is instead sized by NR_PAGE_ORDERS (= MAX_PAGE_ORDER + 1), which is not always 11: arm64 16K pages -> MAX_PAGE_ORDER 11 -> NR_PAGE_ORDERS 12 arm64 64K pages -> MAX_PAGE_ORDER 13 -> NR_PAGE_ORDERS 14 f2fs enables large folios for immutable, non-compressed files, and the read folio order is bounded by MAX_PAGECACHE_ORDER, i.e. min(MAX_XAS_ORDER, PREFERRED_MAX_PAGECACHE_ORDER). With THP enabled this reaches order 11 on 16K/64K base-page kernels (MAX_XAS_ORDER caps it at 11). So an order-11 read folio is possible there and is accounted into index 11 of the array. On those configurations the sysfs file reports the order-11 count correctly, but the tracepoint silently drops it: the memcpy is capped at min(NR_PAGE_ORDERS, 11), so index 11 is never copied and the trace disagrees with sysfs. There is no memory-safety issue, only the order-11 bucket missing from the trace; 4K-page kernels (NR_PAGE_ORDERS == 11, max order <= 9) are unaffected. Size the array and the printed buckets by a ceiling that covers the largest possible NR_PAGE_ORDERS (14) with headroom, and add a BUILD_BUG_ON() so any future growth of NR_PAGE_ORDERS fails the build loudly instead of silently truncating again. The human-readable "order=count" output is preserved. Fixes: cb8ff3ead9a3 ("f2fs: add page-order information for large folio reads in iostat") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 317d32e1a8deaf1c01c388badc667334c39e62ca Author: Wenjie Qi Date: Tue Jun 30 16:23:30 2026 +0800 f2fs: limit recovery filename logging to stored length commit 01027b2fcb74dade59fb833b51023f6593b6a9a2 upstream. F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN. Fixes: f356fe0cba0e ("f2fs: add debug msgs in the recovery routine") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit cb0446b7076688690e3459b5bfa76d656414a5d2 Author: Wenjie Qi Date: Mon Jul 27 15:49:10 2026 +0800 f2fs: return writeback error from collapse range commit f8a4108800254d6f7b2755515fbbd9d0caac561e upstream. f2fs_collapse_range() writes back pages moved by f2fs_do_collapse(), but ignores the return value. If writeback fails, the ioctl can still truncate page cache, shrink blocks, and report success. Return the error before truncating page cache or updating the file size. Fixes: b4ace3370324 ("f2fs: support FALLOC_FL_COLLAPSE_RANGE") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ab31e3b774f5d06b4489cef6c297b48c47c9dcbd Author: Zhan Xusheng Date: Thu Jul 16 10:59:08 2026 +0800 f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() commit a54ffce4637acb0db8e695188a6c7f99f14c3576 upstream. f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the "system.advise" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead. Fixes: 01beba7957a2 ("fs: port inode_owner_or_capable() to mnt_idmap") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu Acked-by: Christian Brauner (Amutable) Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 83f234dcb0e8d591f0aaca4c0001d7037d95cf3d Author: Joanne Chang Date: Tue Jun 23 06:34:28 2026 +0000 f2fs: dirty directory inodes on mtime/ctime update commit 9ec09d5f4b317a417c8655c14056f70cbe71eb6c upstream. Xfstests generic/547 sometimes fail with mismatched directory metadata before and after a power failure. This happens because when a directory entry is added, renamed, or deleted, its mtime and ctime are updated and the inode is marked dirty via f2fs_mark_inode_dirty_sync(dir, sync=false). The sync=false flag means the dirty inode is not added to the global DIRTY_META list. Therefore, subsequent checkpoints skip flushing these updated directory blocks, causing directory timestamps to revert to stale values after a sudden power failure. Address this by changing the dirtying parameter to sync=true during directory entry mutations and renames. This forces F2FS to immediately queue the updated directory blocks on the global DIRTY_META list, ensuring timestamps are committed to checkpoints. Fixes: 7c45729a4d6d ("f2fs: keep dirty inodes selectively for checkpoint") Cc: stable@vger.kernel.org Signed-off-by: Joanne Chang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit dcae1eeda53149f219dd6af93b3083b7271c1c63 Author: Wenjie Qi Date: Tue Jun 30 11:17:00 2026 +0800 f2fs: validate MOVE_RANGE destination size commit e533889fc26aea0cd83c90327063f272061dd820 upstream. F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode. Fixes: 4dd6f977fc77 ("f2fs: support an ioctl to move a range of data blocks") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c14282d35ea867a1870045e1915758c576418b90 Author: Chao Yu Date: Tue Jun 23 20:48:23 2026 +0800 f2fs: fix to avoid move_range and defragment on device_alias file commit 1b4db09b7f10895dc1a0bc32704c7de05188fb1d upstream. It's forbidden to migrate blocks of device alias file. Cc: stable@kernel.org Fixes: 128d333f0dff ("f2fs: introduce device aliasing file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 89c65ec3c18903de763cf567c96ab3ef60e5f3b0 Author: Wenjie Qi Date: Mon Jul 27 21:04:29 2026 +0800 f2fs: only redirty pinned folios in redirty_blocks commit 85171332742e741ccd6f401c69b6e0d698119e72 upstream. redirty_blocks() pins folios with read_cache_folio() and then walks the same range again with filemap_lock_folio() to redirty them and drop the references it took. Commit 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") changed the second pass to a do/while loop. If read_cache_folio() fails before anything is pinned, page_idx does not advance but the cleanup loop still runs once. If readahead has already populated the failed folio in page cache, that extra iteration finds it and folio_put_refs(folio, 2) drops one reference too many. Later drop_caches or reclaim can then report "BUG: Bad page state". Only redirty the range that was pinned successfully. Fixes: 5951fee46bef ("f2fs: Use a folio in redirty_blocks()") Cc: stable@kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 45837717808fbd6ca33c02b982fe7192e95ec3d4 Author: Hao-Qun Huang Date: Wed Jul 8 14:54:39 2026 +0800 f2fs: reject overlapping move range after len expansion commit 28c1ef094e7c86977d9bf570dc0362fc54e36437 upstream. F2FS_IOC_MOVE_RANGE treats a zero length as a request to move data from pos_in to EOF. However, the same-file overlap check runs before that expansion, so a request with len == 0 bypasses the overlap rejection added for same-file moves. For example, with a four-block file, moving from block 0 to block 1 with len == 0 is accepted by the old check because pos_in + len is still pos_in at that point. The code then expands len to cover the rest of the file and calls __exchange_data_block() on overlapping source and destination ranges in the same inode, which is the data-corruption case the overlap check was meant to reject. Move the overlap check after the source range has been validated and len == 0 has been expanded, so it sees the effective length. This is a no-op for non-zero len (the value is unchanged there) and keeps the existing early return for identical positions. Fixes: d95fd91c1ac1 ("f2fs: exclude special cases for f2fs_move_file_range") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 5ba01cc4004139895b0521ba31be26c4cb09b2ff Author: Wenjie Qi Date: Mon Aug 10 21:38:32 2026 +0800 f2fs: return symlink writeback errors commit a2c73a7a677afdaa8b16d775188f9ef5cfbfd8b2 upstream. F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit e9bfb56e2c1bda49d3c5442d824569d71eec07e2 Author: Nilesh Javali Date: Thu Jul 30 21:28:30 2026 +0530 scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started commit f7e46ebffc5781aab3f1f5a5d4350addbb5833f4 upstream. qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt(). Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-26-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7881faf862ee301ecfe3adc0725bd2fa0021cd95 Author: Nilesh Javali Date: Thu Jul 30 21:28:34 2026 +0530 scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak commit b93d3bb3afe1b44489927de1eb4e66e8536a5935 upstream. Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-30-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4cd349f89daa37156e77b59b0d3c8f1b9bd41205 Author: Nilesh Javali Date: Thu Jul 30 21:28:33 2026 +0530 scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics commit 7c4f3f50d83af4545efaa99b3d0d46fb8d52031e upstream. qla26xx_dport_diagnostics() streaming-maps the caller's result buffer with dma_map_single(). The bsg path passes &dd->buf from the __packed struct qla_dport_diag, where buf lands at a 2-byte offset and shares cachelines with the surrounding options/unused fields. Mapping such a misaligned sub-buffer violates the DMA API requirement that streaming buffers be cacheline aligned and not share a cacheline with other data, and can corrupt data on non-DMA-coherent architectures. Allocate a dedicated DMA-coherent buffer inside qla26xx_dport_diagnostics() for the mailbox command and copy the result back into the caller's buffer. This removes the streaming map of the misaligned sub-buffer entirely; the caller's buffer is now only a plain CPU buffer, so its packing no longer matters. Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-29-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7d0b3f745efb24c0aac5e06b49b3420bc65d23b9 Author: Nilesh Javali Date: Thu Jul 30 21:28:28 2026 +0530 scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition commit 7944039ba9cb5c3a935d17c91004e3b8649ff58e upstream. qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization. Fixes: 430eef03a763 ("scsi: qla2xxx: Relocate/rename vp map") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-24-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 91fde7ad722531a5decdb66f036dca0aef9ad61e Author: Nilesh Javali Date: Thu Jul 30 21:28:27 2026 +0530 scsi: qla2xxx: Drop vport reference under lock in report ID acquisition commit 1154b16439ffc562f9461494c4508c63446eb684 upstream. qla24xx_report_id_acquisition() format-1 handling takes the vport reference under vport_slock but drops it outside the lock, after setting vp->vp_flags and vp->dpc_flags: set_bit(VP_IDX_ACQUIRED, &vp->vp_flags); set_bit(REGISTER_FC4_NEEDED, &vp->dpc_flags); set_bit(REGISTER_FDMI_NEEDED, &vp->dpc_flags); atomic_dec(&vp->vref_count); Neither set_bit() nor atomic_dec() imply a memory barrier, so on a weakly ordered architecture the decrement can become visible before the flag stores. qla24xx_deallocate_vp_id() polls vref_count under vport_slock and unlinks the vport once it reads zero, after which qla24xx_vport_delete() frees it via scsi_host_put(). The poller could therefore observe vref_count == 0 early and tear the vport down while the pending vp_flags/ dpc_flags stores land on freed memory. Drop the reference under vport_slock, as is done for the matching increment and by every other vref_count user. The unlock release pairs with the deallocate poller's lock acquire so the flag stores are ordered before vref_count == 0 can be observed. Fixes: 793cedee296f ("scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-23-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e70036dc2ddc03418a77a73d4b98c6fbac2fd01f Author: Nilesh Javali Date: Thu Jul 30 21:28:29 2026 +0530 scsi: qla2xxx: Fix NVMe abort reference leak on repeated abort commit 06b5b2a5d499323f1c3256ead35798e8e3d15e60 upstream. qla_nvme_ls_abort() and qla_nvme_fcp_abort() take a command reference with kref_get_unless_zero() and then call schedule_work() on priv->abort_work, ignoring its return value. qla_nvme_abort_work() runs once and drops exactly one reference via kref_put(&sp->cmd_kref, sp->put_fn). Since the per-abort INIT_WORK() was moved to submission time, schedule_work() now returns false when the work is already pending, for example on a concurrent transport teardown and timeout-driven abort of the same command. In that case the reference taken for the second abort is never released because the work still executes only once, leaking a reference. The command is then never returned to the NVMe-FC transport, which can hang the port. Drop the reference when schedule_work() returns false, so each kref_get_unless_zero() is balanced regardless of whether the work was newly queued. The held reference keeps priv->sp valid for the put. Fixes: 7e85f6dbc856 ("scsi: qla2xxx: Initialize NVMe abort_work once at submission") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-25-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 35124cfa9898b2088ee72859e573e0876aff66fc Author: Nilesh Javali Date: Thu Jul 30 21:28:21 2026 +0530 scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() commit deb8abde83a799d2501f3977f6d6051000253f5e upstream. qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference. Fixes: a6fe35c052c4 ("[SCSI] qla2xxx: Avoid invalid request queue dereference for bad response packets.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-17-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f6e8977bce887481b2b2b0e2e14a791270741cfb Author: Nilesh Javali Date: Thu Jul 30 21:28:20 2026 +0530 scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read commit ca6d880d6c70cb7946e7b3e05d7285f271b6d99e upstream. In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: if (IS_FWI2_CAPABLE(ha)) { sense_data += rsp_info_len; par_sense_len -= rsp_info_len; } rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): if (sense_len > par_sense_len) sense_len = par_sense_len; memcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites. Fixes: 5544213be7b4 ("[SCSI] qla2xxx: Correct extended sense-data handling.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-16-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 845d4abd92cd2f97551356c8b281ad6e197acb07 Author: Nilesh Javali Date: Thu Jul 30 21:28:25 2026 +0530 scsi: qla2xxx: Avoid double completion in async IOCB timeout commit bb45bc4bd53c95a7bf6f782577b5ede94c0f8aa8 upstream. qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout(). Fixes: f6145e86d21f ("scsi: qla2xxx: Fix race between switch cmd completion and timeout") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-21-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 157ca7d1af45f87aa14a286754f19c3f72386988 Author: Nilesh Javali Date: Thu Jul 30 21:28:22 2026 +0530 scsi: qla2xxx: Quiesce response IRQ before freeing request queue commit 505753ec2594c6af09a601f0dd60be7d840c1d2d upstream. qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early. Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-18-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit df86c27cf1ba9d66f737a1fa56479c6e7efafe4e Author: Nilesh Javali Date: Thu Jul 30 21:28:18 2026 +0530 scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() commit 3ba019bdd89d931499d9476456b5d9c7ab7fa753 upstream. qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer(). Fixes: fac2807946c1 ("scsi: qla2xxx: edif: Add extraction of auth_els from the wire") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-14-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 29f1f9ad9e354cd0b6e4f6fc75ba09162d6a04d9 Author: Nilesh Javali Date: Thu Jul 30 21:28:23 2026 +0530 scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path commit 0f41d07d72f2245208c45374ca8d0a1846cad667 upstream. qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-19-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a6374b508893de15fee78583a95f5099d7812e85 Author: Nilesh Javali Date: Thu Jul 30 21:28:12 2026 +0530 scsi: qla2xxx: Don't query firmware state while chip is down commit e0cebe20dcffbed9c078fe30e2d18cd5046d9eff upstream. qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy. Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-8-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit aac0d3cb9199121d2ce5906e06f94b793fac1052 Author: Nilesh Javali Date: Thu Jul 30 21:28:14 2026 +0530 scsi: qla2xxx: Fix FCE trace enable parsing in debugfs commit b7368687e3d11f51392d3c4774ec0263d5fbf31f upstream. qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as "disable" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-10-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 9f31de4d07e4cde91dfc24522993a5fbb4d67083 Author: Nilesh Javali Date: Thu Jul 30 21:28:13 2026 +0530 scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() commit 9efaa782845b4d5fb3e01242be0d06ebc7428d8f upstream. The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents. Fixes: 4d4df1932b6b ("[SCSI] qla2xxx: Add ISP84XX support.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-9-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 41ef7edde27ac87d55ffc703da44e78aa8c2e896 Author: Nilesh Javali Date: Thu Jul 30 21:28:15 2026 +0530 scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump commit 53298efcbbb0f0438366d45cb7ed7e6d93dd5531 upstream. qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it. Fixes: 841df27d619e ("scsi: qla2xxx: Move FCE Trace buffer allocation to user control") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-11-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 122bf170c94a3797531b12fee580639a5dc893ed Author: Nilesh Javali Date: Thu Jul 30 21:28:11 2026 +0530 scsi: qla2xxx: Fix cs84xx use-after-free on host teardown commit 33d102102d925357c5fd172dd6672a27d74b3215 upstream. qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed. Fixes: fe1b806f4f71 ("[SCSI] qla2xxx: Refactor shutdown code so some functionality can be reused.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-7-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 33735490789e5417851752974c0b1d23125559cd Author: Nilesh Javali Date: Thu Jul 30 21:28:08 2026 +0530 scsi: qla2xxx: Serialize flash version read in reset handler commit f606ed93de0c4f1e7e3618779e9fad731455314a upstream. The "update cache versions without reset" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path. Fixes: 8c2cf7d4e387 ("[SCSI] qla2xxx: Add a new interface to update versions.") Reported-by: Sashiko Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-4-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 33c77254e6e91f37c72c7fad4051777452b10de8 Author: Nilesh Javali Date: Thu Jul 30 21:28:06 2026 +0530 scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation commit ebfd35c64433821bd5619a6d07ccc2df8b5b1de3 upstream. ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as "ha->max_req_queues = ha->msix_count - 1" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent "ha->max_req_queues--" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following "ha->req_q_map[0] = req" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs). Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-2-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit b02ff132017b28222187ebcf95ce7f4cb576cd36 Author: Nilesh Javali Date: Thu Jul 23 10:34:09 2026 +0530 scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject commit f743488e4a203049f27ec5d8cd0caccc483af01e upstream. qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-53-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f2d4f025b67fcbfb2bbbadd3b5a6a43c4b436514 Author: Nilesh Javali Date: Thu Jul 23 10:34:12 2026 +0530 scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() commit de62cf265dbe309f34f144a6cdbca9240317727e upstream. qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-56-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 9fc03be982763a131913f84fe73b240ae45bca37 Author: Nilesh Javali Date: Thu Jul 23 10:34:10 2026 +0530 scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak commit a152edab3854f01dd2daf3eaf8f32cbabdb3834e upstream. qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2(). Fixes: ec89146215d1 ("qla2xxx: Add bsg interface to support D_Port Diagnostics.") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-54-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 61f05f2e98f0f5929d107ddc33e019377c50aeeb Author: Nilesh Javali Date: Thu Jul 23 10:34:06 2026 +0530 scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config() commit 9101c51649f5b6773a97bf5271785c948589ea1d upstream. The Modify VP Config completion handler labelled its first error branch "error status" but tested vpmod->comp_status instead of vpmod->entry_status. Because CS_COMPLETE is 0, the following "comp_status != CS_COMPLETE" branch duplicated that test and was dead code, and entry_status was never examined at all. When firmware rejects the IOCB early it sets entry_status while leaving comp_status zero. As the IOCB is allocated with dma_pool_zalloc(), both comp_status branches evaluate false and the handler falls through to the success path, calling fc_vport_set_state(FC_VPORT_INITIALIZING) for a configuration the firmware never accepted. This can leave the virtual port enabled on top of an invalid config and surface later as login timeouts or follow-on firmware errors. Test entry_status in the first branch, matching qla_ctrlvp_completed() and the login/logout/abort/reset IOCB handlers; the comp_status branch then becomes the live completion-status check. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-50-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f4aaa4a4e6f1da6f3abfd80e1917bef922287177 Author: Nilesh Javali Date: Thu Jul 23 10:34:08 2026 +0530 scsi: qla2xxx: Initialize NVMe abort_work once at submission commit 7e85f6dbc85616de2172bce8eaf84b387a723cd1 upstream. qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe. Fixes: e473b3074104 ("scsi: qla2xxx: Add FC-NVMe abort processing") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-52-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit d556f899964d184e6cb788f3fa9dcddcafe1ab2d Author: Nilesh Javali Date: Thu Jul 23 10:34:07 2026 +0530 scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() commit 793cedee296fd819bfadc2a7ec4d52faf9c09a0a upstream. In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals. Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-51-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit e25241f9fa01fb0c088381a156d84a725b71c1ef Author: Nilesh Javali Date: Thu Jul 23 10:34:11 2026 +0530 scsi: qla2xxx: Fix BSG job leak on validate flash image error path commit 0fb52cc632464b0cd07f970341330466d772efe1 upstream. qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally, telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver owns and will complete the request. But bsg_job_done() is guarded by "if (!rval)", so on the error path (rval == -EINVAL) neither the driver nor the transport completes the job. The request dangles until it times out, leaking block layer resources. Commit c2c68225b145 ("scsi: qla2xxx: Fix bsg_done() causing double free") added the "if (!rval)" guard to a batch of BSG handlers. That is correct for handlers that also return the error code (the transport then completes the job once via fail_host_msg), but this function returns QLA_SUCCESS unconditionally, so the guard turned a correct single completion into a leak. Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is reported in vendor_rsp[0], and since the function returns 0 the transport will not complete the job a second time. Fixes: c2c68225b145 ("scsi: qla2xxx: Fix bsg_done() causing double free") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-55-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit b185375d2996b32651fd7bc0e6287f8ad38c5fdf Author: Nilesh Javali Date: Thu Jul 23 10:34:04 2026 +0530 scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters commit eb137255fd7aa834c4d639ae7b5e9e8ecf3a4fb2 upstream. In the CS_PORT_LOGGED_OUT case of qla2x00_chk_ms_status(), the FWI2-capable branch compared ms_pkt->loop_id.extended against NPH_SNS to decide whether the Name Server had logged out. On FWI2 and later adapters the response is a ct_entry_24xx / ct_entry_24xx_ext, where loop_id.extended (via the legacy ms_iocb_entry_t view) aliases offset 8, which is comp_status, not nport_handle (offset 10). As this code runs under CS_PORT_LOGGED_OUT, the field read back 0x29 (CS_PORT_LOGGED_OUT) and the comparison against NPH_SNS (0x7fc) was always false. As a result the driver never recognized a Name Server logout on FWI2/ 29xx adapters: it returned the generic QLA_FUNCTION_FAILED instead of QLA_NOT_LOGGED_IN and skipped setting LOOP_RESYNC_NEEDED / LOCAL_LOOP_UPDATE, so the fabric rediscovery triggered by an SNS logout did not happen. Read nport_handle from the ct_entry_24xx layout (offset 10) instead. nport_handle is at the same offset in ct_entry_24xx and ct_entry_24xx_ext, so a single cast covers 24xx-class and 29xx. The non-FWI2 branch keeps using loop_id.extended, which is correct for the ms_iocb_entry_t response on those adapters. Fixes: b98ae0d748db ("scsi: qla2xxx: Fix name server relogin") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-48-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 75fd6d041c4a325ae37f4683e6678d3015988bb0 Author: Nilesh Javali Date: Thu Jul 23 10:34:03 2026 +0530 scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check commit c20ee380ca59c5a8646750c4849969a815924e2e upstream. qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the "Command already returned" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction. Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-47-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 47049fdadc0eaa115e813735b827e1379c0d2cf8 Author: Nilesh Javali Date: Thu Jul 30 21:28:37 2026 +0530 scsi: qla2xxx: Bound i2c->length in I2C bsg handlers commit 0918ee2c0eeb4d7f45b82b3dc11e65c2d9b7ad59 upstream. struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers. Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-33-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a5501c42256235523c4dddf799f032dfbf4f4c77 Author: Nilesh Javali Date: Thu Jul 30 21:28:36 2026 +0530 scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers commit b47d4a1547d9ef21b2e9d1a739fe2204d4be05dc upstream. The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260730155838.2119230-32-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2215e55ee1e5e69ad53862d968360c5aa63dd3a7 Author: Jackson Lee Date: Fri Jun 26 10:22:32 2026 +0900 media: chips-media: wave5: Resume device before setting EOS flag commit a52e6f7923c17a672135b485ffd96fbd72f46267 upstream. Setting the EOS flag talks to the firmware via send_firmware_command(), which accesses VPU registers. Both the STREAMOFF path (wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path (wave5_vpu_dec_stop()) can run while the device is runtime suspended, so those register accesses hit powered-down hardware and the SoC raises an asynchronous SError, panicking the kernel: SError Interrupt on CPU3, code 0x00000000bf000000 -- SError send_firmware_command+0x2c/0x160 [wave5] wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5] wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5] wave5_vpu_dec_job_abort+0x44/0xa0 [wave5] v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem] v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem] Resume the device with pm_runtime_resume_and_get() around the EOS firmware command and release it with pm_runtime_put_autosuspend(), matching the runtime PM handling already done in wave5_vpu_dec_device_run(). Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2e5b9d632da6dd7387e20600ce8ff4cc586c4af7 Author: Jackson Lee Date: Fri Jun 26 10:22:31 2026 +0900 media: chips-media: wave5: Fix pipeline stall when queuing fails commit e3a80073d99c376176d81013335cd355af576be2 upstream. The Wave5 decoder calls v4l2_m2m_job_finish() immediately in device_run() after submitting frames to firmware. When the firmware completes those frames and the queue drains to zero, finish_decode() has no active M2M job to finish, so v4l2_m2m_schedule_next_job() is never called and the decoder stalls. Call v4l2_m2m_try_schedule() in finish_decode() when the firmware queue empties to ensure the framework always schedules the next device_run(). Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 63d758d2f9dba836d5ae597d317cde522e817cf9 Author: Jackson Lee Date: Fri Jun 26 10:22:30 2026 +0900 media: chips-media: wave5: Defer job_finish() only when a DEC_PIC was queued commit b694ba0a5526a69f78a6924982b1553154ccfd73 upstream. Decoder instances sharing a VPU also share one v4l2_m2m job slot, released when the running context calls v4l2_m2m_job_finish(). While draining, device_run() defers job_finish() once EOS is sent (sent_eos), expecting a later finish_decode() (from a DEC_PIC completion IRQ) to release the slot. But the m2m core checks job_ready() only when a job is queued, not when it is dispatched. A job queued while draining can run after finish_decode() has already moved the instance to STOP and sent EOS. device_run() then runs in STOP, issues no DEC_PIC, yet still skips job_finish() - so no IRQ, no finish_decode(), and the shared slot is leaked, stalling every instance. With several v4l2h264dec instances in parallel, GStreamer hangs at EOS. Track whether the run actually queued a DEC_PIC (cmd_issued) and defer job_finish() only then. Otherwise finish the job immediately Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c104f37b9f79d6c179c5f1a170d7f1da497ff527 Author: Jackson Lee Date: Fri Jun 26 10:22:29 2026 +0900 media: chips-media: wave5: Add timeout while stop_streaming commit 2ae7faed2e60d6d07d9efdd962d20dcb15330ced upstream. When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dc37c478ed6595fdd7479fa1d660ccda5247cb42 Author: Jackson Lee Date: Fri Jun 26 10:22:28 2026 +0900 media: chips-media: wave5: avoid skipping device_run while VPU has work commit 8c5a74a24cbbba9142e38c463c96435d316149ce upstream. The decoder stalls because empty_queue is set to true even when the m2m context still has pending commands. As a result, device_run is never invoked, the m2m source queue fills up, and userspace (e.g. Chromium) can no longer queue new bitstream buffers to the V4L2 driver. Fix this by querying the VPU queue status via DEC_GET_QUEUE_STATUS before deciding whether to skip device_run. Only skip when the VPU's instance_queue_count equals the number of ready source buffers in the v4l2-m2m context, which indicates that there is genuinely no new work to perform. Otherwise, proceed with issuing a decode command so that the VPU can continue draining its internal queue. Fixes: a176ac5e701f ("media: chips-media: wave5: Improve performance of decoder") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8c3cfb9fff96525791e863f6f3123b0953e725c8 Author: Jackson Lee Date: Fri Jun 26 10:22:27 2026 +0900 media: chips-media: wave5: Set inst->std during default format initialization commit cfcefc5a996f6a00b310c963b5f811430f28a30a upstream. When the encoder is opened, wave5_set_default_format() sets up the default capture format (e.g. H.264) but does not initialize inst->std. As a result, inst->std remains zero, which does not match any valid encoder codec. If STREAMON is called before the user explicitly calls S_FMT on the capture queue — as v4l2-compliance does in testBlockingDQBuf — the codec/product check in wave5_vpu_enc_init_seq() fails with "Unsupported encoder-codec & product combination" because inst->std is neither W_HEVC_ENC nor W_AVC_ENC, returning -EOPNOTSUPP. Fix this by setting inst->std via wave5_to_vpu_std() in wave5_set_default_format(), so that the codec type is always consistent with the default capture pixel format from the moment the instance is opened. Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5ee3099138fc2a0a35eefc0d4c56827481daf7a6 Author: Jackson Lee Date: Fri Jun 26 10:22:26 2026 +0900 media: chips-media: wave5: Guard bit depth check with initial_info_obtained commit 1551386934ad43d934c3bb7317929207e1edcd6a upstream. When CAPTURE STREAMON is called before the VPU has completed sequence initialization (initial_info_obtained == false), the initial_info fields contain uninitialized data. The driver checks luma_bitdepth and rejects anything other than 8-bit, so garbage values (e.g. 15) cause STREAMON to fail spuriously. This is reproducible with the following multi-threaded test scenario: 1. Allocate 2 CAPTURE buffers. 2. Call STREAMON on the CAPTURE queue. 3. Call DQBUF, which blocks waiting for a decoded frame. 4. A second thread calls STREAMOFF on the CAPTURE queue. 5. The blocked DQBUF should be released, allowing graceful termination. At step 2, STREAMON reads uninitialized luma_bitdepth and rejects the stream, causing the test to fail. Fix this by checking initial_info_obtained before accessing the bit depth fields, so the validation is only performed when the sequence info has actually been parsed by the VPU. Fixes: 035371c9e509 ("media: chips-media: wave5: Fix timeout while testing 10bit hevc fluster") Cc: stable@vger.kernel.org Signed-off-by: Jackson Lee Signed-off-by: Nas Chung Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cfcaa26b36f7edfded395063bfc2ae39e2905922 Author: Wangao Wang Date: Thu Jul 23 10:55:54 2026 +0800 media: qcom: iris: fix missing hfi_id in gen1 GOP_SIZE cap commit 5eebacbc9a38e1019854ea5f86e367a4d5116387 upstream. Add hfi_id to gen1 encoder GOP_SIZE cap and replace the set function, remove the redundant INTRA_PERIOD cap. Fixes: d22037f3fd33 ("media: iris: Set platform capabilities to firmware for encoder video device") Reviewed-by: Vishnu Reddy Signed-off-by: Wangao Wang Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit d7f34cbaced92069400fc5d71fefe3cb4c748da8 Author: Hungyu Lin Date: Tue Jun 30 15:26:17 2026 +0000 media: qcom: iris: use disable_irq() during power-off commit b9c2215bdedc9c532a7e9d57ec49ee1b6381f863 upstream. The IRQ is registered as a threaded IRQ. Using disable_irq_nosync() in iris_vpu_power_off() does not wait for an already queued threaded IRQ handler to complete before returning. As a result, a threaded IRQ handler may still run after the VPU has been powered down and access hardware registers after power-off. Replace disable_irq_nosync() with disable_irq() so the power-off path waits for any in-flight threaded IRQ handler to complete before returning. Fixes: bb8a95aa038e ("media: iris: implement power management") Cc: stable@vger.kernel.org Suggested-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Hungyu Lin Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 14f49e4577810a9ba601550fa20577464997f3ec Author: Dikshita Agarwal Date: Sun May 31 11:20:36 2026 +0530 media: qcom: iris: fix state-change debug log printing stale value commit 460d3257a6dffc7f0bf58009daeb7e0b6eb2d9d3 upstream. The state‑change debug log in iris_inst_change_state() always prints the same value for the old and new state, rendering it useless for debugging. This happens because the state is updated before the log is emitted. Log the transition before updating the state so the previous value is preserved, consistent with the existing sub‑state handling. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Reviewed-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Dikshita Agarwal Signed-off-by: Vishnu Reddy Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 672dbccf4351370dad002d3c78dbb29ca1588f22 Author: Ruoyu Wang Date: Wed Jul 8 22:33:49 2026 +0800 media: zoran: Avoid freeing a registered video_device twice commit 0735e0b5a96761a9ce277a238e834008ad92a0a5 upstream. zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 82e3a496eb56 ("media: staging: media: zoran: move videodev alloc") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b24d34fd0b7cc822d977c0f355e6afd1e9621692 Author: Arash Golgol Date: Wed Jul 22 20:14:51 2026 +0330 media: vimc: fix pixel format lookup in enum_framesizes commit ad4c65fa30cfb00e2e06adae9a8eb407086eaa66 upstream. vimc_capture_enum_framesizes() looks up the requested format using vimc_pix_map_by_code(), which searches the pix map table by media bus code (MEDIA_BUS_FMT_*). However, v4l2_frmsizeenum::pixel_format holds a V4L2 pixel format (V4L2_PIX_FMT_*), not a media bus code, so valid pixel formats end up being rejected with -EINVAL. Fix this by using vimc_pix_map_by_pixelformat() instead, which performs the lookup by pixel format as the ioctl expects. Fixes: 09c41a23a2e2 ("media: Revert "media: vimc: propagate pixel format in the stream"") Cc: stable@vger.kernel.org Signed-off-by: Arash Golgol Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0e7f2cd72a4f9268ee09a13b13f3339e7cc71557 Author: Uday Khare Date: Mon Jul 6 20:58:33 2026 +0530 media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure commit 76e379754ba618989f6215be608d5c04774a611d upstream. kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path. Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver") Cc: stable@vger.kernel.org Signed-off-by: Uday Khare Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 22128985b581df2598377d637ced6a4b2b6f7f2b Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:55 2026 +0100 media: venus: fix payload size calculation in parse_raw_formats() commit bd595b745eb770e80347c31ffc25351046935305 upstream. The consumed size is computed after the loop using the num_planes value from the last iteration for all entries. When entries have different plane counts, this produces an incorrect total. Accumulate the actual size during the loop instead. Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 66fe517d2dd387e10493e6d0d985bfc070fd9ae4 Author: Mohammed EL Kadiri Date: Wed Jun 10 13:56:54 2026 +0100 media: venus: fix payload size returned by parse_caps() and parse_alloc_mode() commit a51cea23e409278f6e2ea072280aba93cc1dd75e upstream. parse_caps() and parse_alloc_mode() return only the size of their fixed header fields, excluding the flexible array payload. hfi_parser() uses this return value to advance through the firmware response buffer, so underreporting causes parser desynchronization. Return the full consumed size (header + entries), matching the correct pattern used by parse_profile_level(). Fixes: 9edaaa8e3e15 ("media: venus: hfi_parser: refactor hfi packet parsing logic") Cc: stable@vger.kernel.org Signed-off-by: Mohammed EL Kadiri Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 881aafb139520570fd3390bf9938d7098b7fbb99 Author: Biren Pandya Date: Fri Jun 19 13:41:30 2026 +0530 media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link commit a6e86efd7f85e519bf48417f41923f8bd51f1597 upstream. In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. Signed-off-by: Biren Pandya Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Cc: stable@vger.kernel.org [Sakari Ailus: Fix subject prefix and coding style a little.] Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 2bce73ab36d6904b92ff7b0d5d937b1e1f878cf0 Author: Ming Qian Date: Mon Jul 20 18:17:26 2026 +0900 media: v4l2-ctrls: Allow unknown HDR10 white point and luminance commit 49af0c7cad889f7dabe5cf080b019392066122a3 upstream. SMPTE ST 2086 defines the nominal ranges for mastering display chromaticity and luminance values. Its Annex A also documents that CTA 861-G uses zero maximum and minimum luminance values to signal that the corresponding values are unknown, and the xy chromaticity coordinate (0, 0) to signal that the white point chromaticity is unknown. The V4L2 HDR10 mastering display compound control currently rejects these values. Consequently, an unknown white point or luminance value prevents the entire compound control from being updated, making the other valid mastering display metadata unavailable to userspace. Accept (0, 0) as an unknown white point and zero as an unknown maximum or minimum mastering luminance. Continue to reject partially zero white point coordinates and non-zero values outside the nominal ranges. Display primary validation remains unchanged. Document the newly accepted unknown values in the V4L2 userspace API. Fixes: 1ad0de78e794 ("media: v4l: Add HDR10 static metadata controls") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 30f85a7c59113a8844b276efc010085a34f912e9 Author: Michael Bommarito Date: Wed May 27 15:47:36 2026 -0400 media: v4l2-ctrls: validate HEVC EXT SPS RPS counts commit 796b5c6d4f1615d59d5d8fe5a38fae6bfdfe878e upstream. The HEVC SPS control carries the short-term and long-term RPS counts that decoder drivers use to walk the matching EXT SPS dynamic arrays. Reject SPS values that exceed the HEVC limits of 64 short-term sets and 32 long-term references so drivers cannot later index beyond those controls. Also reject EXT SPS ST RPS entries whose negative or positive picture counts exceed the 16-entry arrays, or whose combined delta-POC count exceeds the HEVC DPB maximum. Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Cc: stable@vger.kernel.org Suggested-by: Detlev Casanova Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a57d94026cb4fd7b3d258f0db2ad391cbccfaba5 Author: Xu Rao Date: Mon Aug 10 17:50:12 2026 +0800 media: v4l2-async: avoid deleting unlinked ASC entry on link error commit 47d82b605351c0e04f6365e42c8ffe2fcfdba615 upstream. v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back. Fixes: 28a1295795d8 ("media: v4l: async: Allow multiple connections between entities") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit fd5b4a14c87b21e1c9eaee603b01bb7fa7db45c8 Author: Fan Wu Date: Thu Jul 16 11:32:30 2026 +0000 media: ti: vpe: quiesce overflow recovery before freeing streams commit aeaacc3001449d44b4ab7da56331121d1f3b137b upstream. The VIP overflow recovery worker is armed from the hardirq handler when a FIFO overflow is detected, and the list-complete path looks the stream up through the VPDMA list private pointer. Both keep touching stream, port and device state; the recovery worker also resets the parser and VPDMA, repopulates the descriptor list, and re-enables the per-list IRQs. vip_stop_streaming() masks and clears the per-list IRQs, but it neither synchronizes the hardirq handler nor disables recovery_work. An overflow IRQ that has already queued recovery_work, or a list-complete IRQ in flight when the stream is torn down, can therefore still dereference the stream after its resources are released: the descriptor list is freed by vip_release_stream() on file release, and the stream itself by free_stream() on unbind/remove. Drain the recovery worker and the IRQ handler at both teardown points through a shared vip_quiesce_stream() helper, before any stream-owned resource is released. disable_work_sync() cancels pending recovery_work, drains a running instance, and raises its disable depth, so a subsequent schedule_work() issued by a racing IRQ handler is rejected at the workqueue scheduler: recovery_work cannot be requeued after disable_work_sync() takes effect. The worker may still re-enable the per-list IRQs before disable_work_sync() returns; disable_irqs() then masks those sources and synchronize_irq() waits for any in-flight handler that still dereferences stream state. In vip_stop_streaming() the helper runs before the parser is stopped, since a worker drained by disable_work_sync() may re-enable the parser before exiting and would otherwise undo the stop. recovery_work is created disabled and enabled in vip_start_streaming() before IRQs, pairing the enable with the teardown disable across the streaming lifecycle. This issue was found by an in-house static analysis tool and confirmed by manual code review. Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Yemike Abhilash Chandra Tested-by: Yemike Abhilash Chandra Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f1ba602afd5ee6609fd71a0d112d18e8447a485f Author: Ilya Krutskih Date: Sun Jul 19 13:08:35 2026 +0000 media: tda18250: fix possible integer overflow commit 6dd8e257f7cafda7fbf10d81b3c55c9bba4825f4 upstream. Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior. Fixes: 148abd3b5b14 ("media: tda18250: support for new silicon tuner") Cc: stable@vger.kernel.org Signed-off-by: Ilya Krutskih Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit fc65623524b5bf23baddc6ae688d954fba0d5de2 Author: Guangshuo Li Date: Sat Jul 18 14:10:11 2026 +0800 media: saa7164: fix cleanup on resource allocation failure commit 28e84c6e2e6753ed238ea097b2842a32a6a6879b upstream. saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails. Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7d221859ba45d7228d0138c9a3e55bd3bb31e14e Author: Lei Huang Date: Tue Jul 14 14:52:02 2026 +0800 media: s2255: check firmware size before reading trailing marker commit 330f2936ab768c7215322a476f033143e8891d28 upstream. s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing. Fixes: 14d962602c8b ("V4L/DVB (8752): s2255drv: firmware improvement patch") Cc: stable@vger.kernel.org Signed-off-by: Lei Huang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dd739517560c8d0ec4463a53e717bf40b988d7da Author: HyeongJun An Date: Wed Jul 1 20:45:36 2026 +0900 media: s2255: bound JPEG frame size before copying into the buffer commit e504cc888f42999dd76b6a43788c422610f2aad2 upstream. s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: payload = le32_to_cpu(pdword[3]); if (payload > vc->req_image_size) /* payload is checked ... */ return -EINVAL; vc->pkt_size = payload; vc->jpg_size = le32_to_cpu(pdword[4]); /* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it. Fixes: 38f993ad8b1f ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5249a092ed2cf61eb1b5f158850ee495430232c3 Author: Tommaso Merciai Date: Wed Jul 29 12:55:46 2026 +0200 media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement commit 56c29fa3ee666197516a231e75aed789ae9c530d upstream. The RZ/G3E CRU programs the line stride via the AMnIS register, whose IS field encodes the value in units of 128 bytes. If bytesperline is not a multiple of 128, the division truncates and the hardware uses a wrong stride, causing horizontal banding. Commit ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") replaced the open-coded aligned calculation with v4l2_fill_pixfmt(), which sets no alignment, reintroducing the issue. Round bytesperline up to RZG2L_CRU_STRIDE_ALIGN and recompute sizeimage when info->has_stride is set. RZ/G2L has no AMnIS register and keeps the values from v4l2_fill_pixfmt() unchanged. Fixes: ace92ccef0c9 ("media: platform: rzg2l-cru: Use v4l2_fill_pixfmt()") Cc: stable@vger.kernel.org Signed-off-by: Tommaso Merciai Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit ac02b2c56ccef0788cea9b86990a8f349a3fc6d8 Author: Valery Borovsky Date: Sat May 23 19:53:58 2026 +0300 media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure commit fe50cdaebf12cd32ff9a44d92bfd6fbc2300dbd4 upstream. rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a0d9d9a3b41a1346c26af57aade6ba3f552fa171 Author: Valery Borovsky Date: Sat May 23 19:53:37 2026 +0300 media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak commit dabb047c62668f280998e29117c55e41aabac336 upstream. rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 74938f83a8abbee8f502dfb5d94213b2497d1edf Author: Michael Bommarito Date: Wed May 27 15:47:37 2026 -0400 media: rkvdec: hevc: guard INTER_REF_PIC_SET_PRED index underflow commit 052c5ed5a1d96a6b24fd50ccda16fc6841ee7ca3 upstream. st_ref_pic_set_prediction() computes the reference RPS index as st_rps_idx - (delta_idx_minus1 + 1) per HEVC spec equation 7-59. Both operands are u8, so when delta_idx_minus1 + 1 exceeds the current index the subtraction wraps and the subsequent array access at calculated_rps_st_sets[ref_rps_idx] reads far out of bounds. A userspace V4L2 client that can open the RKVDEC m2m decoder can submit an EXT_SPS_ST_RPS control with INTER_REF_PIC_SET_PRED set and delta_idx_minus1 crafted to trigger the underflow. Reject the entry early when the reference index would underflow. Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Cc: stable@vger.kernel.org Suggested-by: Detlev Casanova Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5ef075c44c79f118480761708fa4b618e237a991 Author: Michael Bommarito Date: Wed May 27 15:47:35 2026 -0400 media: rkvdec: hevc: tighten EXT SPS RPS control dimensions commit f0b9d7e5be061b4858279d451f5a6ad0ed20b1be upstream. The VDPU381 HEVC driver registers V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS and V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS with .cfg.dims = { 65 }, but the HEVC spec caps num_short_term_ref_pic_sets at 64 (ITU-T H.265 7.4.8) and num_long_term_ref_pics_sps at 32 (7.4.3.2.1). The hardware descriptor table (struct rkvdec_rps) sizes match those spec limits: refs[32] and short_term_ref_sets[64]. Reduce the dims to { 64 } and { 32 } respectively so the V4L2 control framework rejects oversized payloads before any driver code runs. Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant") Cc: stable@vger.kernel.org Suggested-by: Detlev Casanova Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e21f0344fcdfd38bdfb005030681e2c9f1041f45 Author: Narasimharao Vadlamudi Date: Wed Jul 1 16:42:03 2026 +0530 media: rkvdec: Propagate platform_get_irq() errors commit c37aca64206fafe938119e801a3fd10a537a051f upstream. platform_get_irq() returns a positive IRQ number on success and a negative error code on failure. It no longer returns zero. The driver currently returns -ENXIO for all failures, which loses useful errors such as -EPROBE_DEFER. Return the error from platform_get_irq() directly. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Cc: stable@vger.kernel.org Signed-off-by: Narasimharao Vadlamudi Reviewed-by: Detlev Casanova Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b866d4bcd2ec699ce06430237764010e39bb5e57 Author: Sven Püschel Date: Fri Jun 5 15:32:01 2026 +0200 media: rockchip: rga: don't change RGB quantization commit 7acc334cf038b5ac1a7ee480d3ec59d288d2f5f3 upstream. Don't change the quantization of an RGB format when converting between RGB and YUV with the RGA3. As the RGA3 only supports doing conversions to full range YUV with BT601, it wants to announce it through try_fmt/s_fmt. As it is only relevant, when converting between RGB and YUV, it's guarded by a given condition. But the condition also causes the RGB format quantization to be adjusted to limited range, which is incorrect. Therefore simplify the condition to only apply when the current format is a YUV format. Also document the reason for checking if the other format is an RGB format. Fixes: 24a63d4c9d3c ("media: rockchip: rga: add rga3 support") Cc: stable@vger.kernel.org Signed-off-by: Sven Püschel Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5e6f5bffaa80fc8ecce348ec0e34fed9d843e47e Author: Myeonghun Pak Date: Wed May 13 16:11:03 2026 +0900 media: rc: sunxi-cir: Unregister rc device on probe failure commit 479aa6fa8c50f1052f1451326ef7d4d586d340c3 upstream. After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds. Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit f220b29d318f3b755ccb9afeb84589ee342fe833 Author: David Carlier Date: Thu Jun 18 20:52:54 2026 +0100 media: mali-c55: Fix scaler factor overflow for large crop sizes commit 2447c768cb5dfb9f52630b82d419e2b24fee27a3 upstream. The horizontal and vertical scaling factors multiply the crop dimensions by MALI_C55_RSZ_SCALER_FACTOR, a Q4.20 factor of (1 << 20). Both operands are 32-bit, so the multiplication wraps before the result is stored in the u64 scale variables. For any crop dimension of 4096 or more (the maximum is 8192) the value overflows; an 8192 to 4096 downscale yields a TINC of zero, so the scaler never advances and the output is corrupted. Define MALI_C55_RSZ_SCALER_FACTOR as a 64-bit constant so the multiplication is performed in 64-bit. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Daniel Scally Reviewed-by: Linus Walleij Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit efb92bf2bd7a66e27a076b497001c9f8ec768342 Author: David Carlier Date: Tue Jun 9 06:32:31 2026 +0100 media: mali-c55: Fix AEXP IHIST disable bit shift commit 9a2925b823d541a23b8330f80056e6cca78c7677 upstream. The post-Iridix auto-exposure histogram disable bit in MALI_C55_REG_METERING_CONFIG is bit 16, but MALI_C55_AEXP_IHIST_DISABLE was defined with a shift of 12, copied from the AEXP_HIST definition above it. As the value is masked with the BIT(16) disable mask when it is programmed, the result is always zero and the disable bit is never set. The IHIST can therefore never be disabled, neither at ISP init nor via a parameters block flagged V4L2_ISP_PARAMS_FL_BLOCK_DISABLE, and the hardware keeps producing histogram statistics that userspace believes are switched off. Use a shift of 16 so the disable request takes effect. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Reviewed-by: Daniel Scally Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 003b2bf690683854a688d8f17a1d32ff310ef382 Author: David Carlier Date: Fri Jul 3 17:35:03 2026 +0100 media: mali-c55: Fix clock leak on reset deassert failure commit f499befeb668436b67bdb2b610b34db57732703f upstream. __mali_c55_power_on() enables the clocks before deasserting the resets, but bails out on a deassert failure without disabling them again. Both callers treat a failed power-on as already cleaned up, so the clocks are left enabled. Disable them on the error path. Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Daniel Scally Reviewed-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 63fbd6372f77d4311ad8fb4cb1849248bb8f6f16 Author: David Carlier Date: Tue Jun 2 19:53:05 2026 +0100 media: mali-c55: fix dropped last AEC histogram zone weight commit fb9b87145624eedaf3d50edac9b11d707494cb5b upstream. The 15x15 AEC histogram metering grid has 225 per-zone weights, packed by userspace as a u8 array. The driver writes the first 56 registers (zones 0 through 223) in a loop, then handles the final register on its own to keep static analysers from flagging the array access. That separate path computes the address and value for the 225th weight (the bottom-right zone) but never issues the register write, so the zone keeps its stale or default weight. Any non-default weight userspace sets for the last zone is silently ignored, skewing auto-exposure metering. Both the AEXP_HIST_WEIGHTS and AEXP_IHIST_WEIGHTS blocks are affected as they share this handler. Issue the missing write, masking the value as the loop does. Fixes: 01535ea08674 ("media: platform: Add mali-c55 parameters video node") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: David Carlier Reviewed-by: Jacopo Mondi Reviewed-by: Daniel Scally Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 5a65e6f9dff66409dc7ad29e1c4b3ca93b345190 Author: Guoniu Zhou Date: Tue Jul 28 14:58:56 2026 +0800 media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks commit 77e60a2c5d824ad2d493f53dc17137ae065753fe upstream. Use BIT_ULL() instead of BIT() for u64 stream masks to avoid incorrect results on 32-bit architectures when stream IDs are 32 or greater. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260728-isi-v5-1-1d22ab91602a@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit de7192f111a4743f4b8d2ff25f3bbdf28238c028 Author: Guoniu Zhou Date: Mon Jul 20 11:34:07 2026 +0800 media: nxp: imx8-isi: Correct color map between V4L2 and ISI commit 4640ec1cb0121473867e7a6850c7449340dcd428 upstream. Fix the ISI input format for the color map V4L2_PIX_FMT_XBGR32 in memory-to-memory mode. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Tested-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-5-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ab15c39a83b6d677e0ed06830b37409beea07036 Author: Guoniu Zhou Date: Mon Jul 20 11:34:03 2026 +0800 media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing commit 795bd2863591f2fee33fab8f10cf9c383c94342e upstream. The crossbar routing validation has a critical bug where it validates the wrong routing table, allowing userspace to bypass validation entirely. The __mxc_isi_crossbar_set_routing() function is called to validate and apply a new routing table from userspace. However, the validation loop iterates over state->routing (the currently active routing table) instead of the routing parameter (the new table being validated): for_each_active_route(&state->routing, route) { This means userspace can submit any invalid routing configuration and it will pass validation as long as the currently active routing is valid. This is a security issue as it allows userspace to configure routes that violate hardware constraints, potentially causing undefined hardware behavior. Fix by validating the routing table that will actually be applied. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260720-isi-v2-1-45845bc5d4fa@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 426ead7eed6d6b3c3f0fe0925c112ef73fc87256 Author: Johan Hovold Date: Mon Jul 6 08:59:27 2026 +0200 media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup commit 90368323fb244da0504e3da37a182f8e89bcc3b9 upstream. Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound. Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Cc: stable@vger.kernel.org # 6.1 Cc: Moudy Ho Signed-off-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0259ade4c4ceaf1e184a7c1aea8071ad398f9b6f Author: Guangshuo Li Date: Sun Jul 5 01:31:19 2026 +0800 media: platform: mtk-mdp3: Fix SCP device refcounting commit 55793e4665b7f15151e6f5ab51ca980e73abed5d upstream. mdp_probe() first tries to get the SCP handle with scp_get(). When that fails, it falls back to looking up the SCP platform device with __get_pdev_by_id() and then reads its driver data. The fallback lookup returns the platform device with a reference, just like scp_get() does. However, the fallback path currently drops that reference immediately after platform_get_drvdata(). The driver later still calls scp_put(mdp->scp) unconditionally from the probe error path and from mdp_video_device_release(), which drops the SCP device reference again. Keep the fallback reference until the existing scp_put() call, so that the fallback path follows the same ownership rules as the scp_get() path. Fixes: 8f6f3aa21517 ("media: platform: mtk-mdp3: fix device leaks at probe") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d61ba609c3226af3c84268ba606ea06ee63e511b Author: Christian Hewitt Date: Wed Jun 24 06:58:08 2026 +0000 media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common commit 20aa934ace6917262ff579a73ec018d06a7bad1c upstream. When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format. Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Christian Hewitt Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f99d78280faaa93f9569afac439f0a686b1a5604 Author: Bryan O'Donoghue Date: Tue Jun 2 14:59:21 2026 +0100 media: iris: Enumerate cap->bus_info to differentiate between encoder and decoder commit 94ef75095d5e76df848a2e5508d71a4532a6ce23 upstream. commit 66c744e28b69 ("media: venus: assign unique bus_info strings for encoder and decoder") introduced the naming convention plat:node-addr:video-codec{enc|dec}. Right now Iris does not replicate this naming convention. When we do v4l2-ctrl --list -devices we see: Iris Decoder (platform:aa00000.video-codec): /dev/video0 /dev/video1 Enumerate the bus_info field of the capabilities structure for namespace parity and appropriate differentiation: Iris Decoder (plat:aa00000.video-codec:dec): /dev/video0 Iris Encoder (plat:aa00000.video-codec:enc): /dev/video1 Fixes: 5ad964ad5656 ("media: iris: Initialize and deinitialize encoder instance structure") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Dmitry Baryshkov Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit dc31e4f1e1463839a8a613bf598c0c357b22b115 Author: José María Martín Date: Mon Aug 10 16:30:26 2026 +0200 media: ipu-bridge: check all DMI entries when overriding sensor rotation commit 4900cad020c0580dfb1be27776ff10a4ef110cfa upstream. A machine can have more than one sensor whose rotation needs to be overridden, which takes one upside_down_sensor_dmi_ids[] entry per sensor, all sharing the same DMI match but with different ACPI HIDs in driver_data. ipu_bridge_parse_rotation() uses dmi_first_match(), which always stops at the first entry matching the running machine, so any further entry for the same machine is unreachable and only one sensor per machine can ever be corrected. Walk the whole table and match every entry for the running machine against the sensor's ACPI HID instead. Fixes: b75710155a82 ("media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors") Cc: stable@vger.kernel.org Signed-off-by: José María Martín Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit eee6069e4e9511e814a33a75e403f7e863f70394 Author: Cong Nguyen Date: Sat Aug 8 16:10:02 2026 +0700 media: intel/ipu6: fix async notifier cleanup leak on parse error commit abb1f808ceab5a3275f8a6b4e37cff17f9f781c1 upstream. isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an endpoint parse or add fails partway through the loop, it jumps to err_parse and returns without calling v4l2_async_nf_cleanup(), leaking every v4l2_async_connection already added to the notifier's waiting list. The register-failure path just below already cleans up correctly, and the caller only tears the notifier down (isys_notifier_cleanup()) once isys_notifier_init() has returned success. Clean up the notifier on the parse error path too. Fixes: f50c4ca0a820 ("media: intel/ipu6: add the main input system driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit ea97482e46cc2b43f74cd7a3d6b75cb2ffbefa2b Author: Dave Stevenson Date: Wed Jul 15 12:43:14 2026 +0100 media: imx355: Avoid calling imx355_power_off twice in error path commit ee737bc3ccae7dc713ccaa83ffa46080c6031b3e upstream. If v4l2_async_register_subdev_sensor failed, then the sensor had already been powered down by pm_runtime_idle, but the error path then also explicitly called imx355_power_off as well. That left an imbalance in the regulator and clock calls. Call pm_runtime_idle only after v4l2_async_register_subdev_sensor succeeds to avoid this. Fixes: efa5fe19c0a9 ("media: imx355: Enable runtime PM before registering async sub-device") Cc: stable@vger.kernel.org Signed-off-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 64d5e26dc6bb69806bf6bcf3ffe99506b9eba453 Author: Benjamin Mugnier Date: Mon Jun 29 12:51:46 2026 +0200 media: i2c: vd55g1: Fix media bus code initialization commit e4a4f2e3b9bc65e0b82ae8c3a2945955870df36f upstream. In the driver initialization, the index of the default media bus code from the supported media bus code array is passed directly to the vd55g1_get_fmt_code() function instead of the proper media bus code. This works correctly as a proper media bus code is set after initialization but could not have been the case. This also resulted in mutliple "Unsupported mbus format" error messages. Retrieve the media bus code from the media bus code array, and pass this media bus code to vd55g1_get_fmt_code() instead of the code index. Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future confusions. Display the guilty error code in warning message. Cc: stable@vger.kernel.org Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant") Signed-off-by: Benjamin Mugnier Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 7304585c759720e1c30bd20fdfa7b65585c5944e Author: Benjamin Mugnier Date: Mon Jun 29 12:51:48 2026 +0200 media: i2c: vd55g1: Fix manual digital gain on color variant commit 113a84d6ba739d333eef2a595e3ccd4f97a306c2 upstream. Apply digital gain to all channels, each channel representing a color. Cc: stable@vger.kernel.org Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant") Reviewed-by: Jacopo Mondi Signed-off-by: Benjamin Mugnier Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit c85aa92f1b16695ba575e8c29f4e9e0aaef4562a Author: Richard Leitner Date: Mon Jul 20 20:31:00 2026 +0200 media: i2c: ov9282: restore flash duration calculation commit d836f57e8ab971c1cd3b607d9e466513f654e644 upstream. The migration to CCI helpers made V4L2_CID_FLASH_DURATION write the requested duration directly to OV9282_REG_STROBE_FRAME_SPAN, dropping the conversion from microseconds to the register value. This made flash strobes too long and produced overly bright frames. Restore the missing calculation so flash duration is programmed correctly again. Fixes: 273f52f3cbec ("media: i2c: ov9282: Convert to CCI register access helpers") Cc: Xiaolei Wang Cc: stable@vger.kernel.org Signed-off-by: Richard Leitner Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 09453b467990e8ef8fe09f45a685f9a625248d33 Author: Biren Pandya Date: Wed Jul 8 18:27:23 2026 +0530 media: i2c: ov7740: fix use-after-destroy in remove commit 5d1b3dea5a44124bab6c14a2d71b977dabed54e7 upstream. The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order. Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 6e13784452785cd8402b228bea53bc6a027ade84 Author: Biren Pandya Date: Wed Jul 8 18:35:33 2026 +0530 media: i2c: ov02a10: fix endpoint parsing use-after-free commit 94971ba0592ca77ec99b292226a4b398763315b8 upstream. The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'. Fixes: 91807efbe8ec ("media: i2c: add OV02A10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Reviewed-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 55eb48818f778f086d0364ed26dfaeeaa83b63ba Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:34 2026 +0530 media: i2c: imx415: Return test pattern write errors commit 8cd5735b88d76dda80b089031747b6f18ee0bca2 upstream. imx415_set_testpattern() accumulates failures from cci_write(), but drops the value and always returns success. Return the accumulated error so V4L2 reports failures to userspace. Fixes: d5df1c7f3f83 ("media: i2c: imx415: Convert to new CCI register access helpers") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 46c63cc1c1aefa08d3126000d5b56dabb62e801f Author: Narasimharao Vadlamudi Date: Wed Aug 5 19:26:35 2026 +0530 media: i2c: imx415: Release runtime PM reference on VBLANK error commit bea3001e0f32527a291444e527e84a7ea9b546d4 upstream. The VBLANK path returned immediately when programming VMAX failed after pm_runtime_get_if_in_use() had taken a runtime PM reference. Break out of the switch instead so the common pm_runtime_put() path is used. Fixes: 3bcae55ab96a ("media: i2c: imx415: Add read/write control of VBLANK") Cc: stable@vger.kernel.org Reviewed-by: Michael Riesch Signed-off-by: Narasimharao Vadlamudi Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 9d2e6262f65dd61eab270c660a00a2b7b22831ed Author: Martin Hecht Date: Fri May 22 13:41:12 2026 +0200 media: i2c: alvium: Fix: Correct name of register in alvium_set_ctrl_auto_exposure commit 58ca8a0bff9e78841a39863474b96e59ef60da19 upstream. Write value for auto-exposure into correct register REG_BCRM_EXPOSURE_AUTO_RW instead of wrong register REG_BCRM_WHITE_BALANCE_AUTO_RW. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Martin Hecht Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit e6f1a1ac9b8ccabfec548aef0d0d93eaf4dba4f4 Author: Shuangpeng Bai Date: Mon Jul 6 16:50:15 2026 -0400 media: go7007: defer the ALSA v4l2 put until card release commit 1bd456afeb8a515137e567967069fce6f8fcd23e upstream. go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime. Closes: https://lore.kernel.org/r/178144969601.60470.6005237146425573205@gmail.com Fixes: d5d3a7cc127d ("[media] go7007: fix unregister/disconnect handling") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 16cb1ee17e093175b4d9ae33202f68e5b108cca2 Author: Jiangong.Han Date: Tue Jun 30 22:54:34 2026 +0800 media: em28xx: fix use-after-free of dev_next->devlist on disconnect commit 826915b6b65e2d3251e7248ea54289a22d748c84 upstream. When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 ("USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed. Fixes: f410b4093fdd ("media: em28xx: split up em28xx_dvb_init to reduce stack size") Cc: stable@vger.kernel.org Reported-by: syzbot+99d6c66dbbc484f50e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=99d6c66dbbc484f50e1c Signed-off-by: Jiangong.Han Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4666197ca4f7d80cd3b0292054fe45d76be9ba04 Author: Diego Fernando Mancera Gomez Date: Thu Jul 23 12:22:42 2026 -0600 media: em28xx: defer audio-only extension registration commit 95f76f51937fdfb0fc1e14cae606b1ef574a56f3 upstream. The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next. Fixes: 4a089668ef22 ("media: em28xx-cards: rework the em28xx probing code") Cc: stable@vger.kernel.org Reported-by: syzbot+a11c46f37ee083a73deb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66ec3c83.050a0220.29194.002f.GAE@google.com/T/ Suggested-by: Fedor Pchelkin Signed-off-by: Diego Fernando Mancera Gomez Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 86d8468e9015c7ec4eb0d3c6641f1bc2ebcb555a Author: Guoniu Zhou Date: Fri Apr 24 14:49:50 2026 +0800 media: dt-bindings: nxp,imx8-isi: Drop fsl,blk-ctrl requirement for i.MX8ULP commit fc312f830d8df6c082bd6f7250aa5c0ff063eea4 upstream. The i.MX8ULP variant does not require the fsl,blk-ctrl property. Add fsl,imx8ulp-isi to the exception list alongside fsl,imx91-isi. Fixes: 288517a3c6c9 ("dt-bindings: media: nxp,imx8-isi: Add i.MX8ULP ISI compatible string") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Acked-by: Conor Dooley Link: https://patch.msgid.link/20260424-csi2_imx8ulp-v12-1-da148eabc035@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 99cd62b9b1c818d6d01a87be9a8e5796314150a2 Author: Fan Wu Date: Mon Jul 20 13:17:08 2026 +0000 media: cx23885: cancel NetUP CI work before teardown commit 4e143d662ca94888b494b2427fc9e34494eb933a upstream. netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool. Fixes: c184dcd28233 ("V4L/DVB (10798): Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card") 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 a636c72c7f522d984fa498fc0631f33a2d0be3fd Author: Bryam Vargas Date: Mon Jun 15 18:40:48 2026 -0500 media: cx231xx: reject geometry changes while the VBI queue is busy commit 627a121c15fe05a541f44d86016294b80bada75d upstream. vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: offset = lines_completed * (dev->width << 1) + ...; if (dma_q->current_field == 2) offset += dev->width * 2 * dma_q->lines_per_field; memcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer. Fixes: 7c617138b825 ("media: cx231xx: convert to the vb2 framework") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8c6610e230b9355cf7df5a338a0592c0f088c00b Author: Ruoyu Wang Date: Wed Jul 8 22:33:38 2026 +0800 media: cobalt: Avoid freeing ALSA private data twice commit 3a7d6b9c4cb5ac18cbd3f1c7f8c7b159c42ba0b1 upstream. snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85756a069c55 ("[media] cobalt: add new driver") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 81aa608ac3a56cdd4aab0bd12442ed529a24ba31 Author: Dawei Feng Date: Wed Jun 24 16:59:20 2026 +0800 media: cedrus: fix memory leak in cedrus_init_ctrls() commit 9df2fbe563194da1967a5db083442186c1323efe upstream. In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed. Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Acked-by: Jernej Skrabec Reviewed-by: Dan Carpenter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ae614f48712156fb0f55b207338d48d422c58bc0 Author: Ruoyu Wang Date: Wed Jul 8 11:01:02 2026 +0800 media: cec: Serialize exclusive follower delivery commit 1924d0788caa6c66fd320dd4704fae99487fd2c7 upstream. cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release. Fixes: 9881fe0ca187 ("[media] cec: add HDMI CEC framework (adapter)") Cc: stable@vger.kernel.org Signed-off-by: Ruoyu Wang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6e7a52d2370138d3f15edbe5aac805d74113e9e6 Author: Yi Ding Date: Thu May 28 23:00:05 2026 -0700 media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid debugfs clash commit 172c5a7d81deb922ddedd1bc920751c7fed6c43c upstream. The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become ".cec" and ".cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding Reviewed-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7ad2fec276946a0dedfa54eb26fc38c4fc6a6034 Author: Hans Verkuil Date: Thu Jun 18 13:03:19 2026 +0200 media: cec: extron-da-hd-4k-plus: add sanity check commit abac9820b26b5cfcb01eb79efe2abdd0ac7e07c3 upstream. Add check to prevent overflowing msg.msg[] in case the incoming data is malformed. Signed-off-by: Hans Verkuil Reviewed-by: Sean Young Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9c6ceb0949227c1f0cf0e19393daec72d9889871 Author: Biren Pandya Date: Sun Jun 21 10:04:37 2026 +0530 media: cec: disable delayed work before freeing an interrupted transmit commit 0fbd5c2327020858c45b2d1c65775d64cdeca523 upstream. cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled. Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work") Reported-by: syzbot+051024d603432b4ab395@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=051024d603432b4ab395 Suggested-by: Hillf Danton Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cca2407794795cecff7f8e5f5a79f4ef6b1d6f6c Author: Jonas Karlman Date: Fri May 29 09:59:26 2026 +0000 media: cec: core: Fix kmemleak due to missed rc_free_device() call commit a24ba0653f7154e671dc8d2bf64682ab2d042792 upstream. The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e3c973c912aa4ba9210d7886f1dcb2e525dc3205 Author: Eugen Hristev Date: Wed May 20 18:37:00 2026 +0300 media: bcm2835-unicam: Fix pipeline wrong validation for unpacked formats commit 4f26c8345dbfa92f19078c788be1b9bfd425ed60 upstream. The commit 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association") introduced a check to see whether the format requested is the same as the fourcc in the format list. However, this breaks the case when userspace requested an unpacked fourcc, e.g. RG10. Unicam can work with or without unpacking pixels, e.g. pRAA or RG10, depending on what userspace requests. In the unpacking case, a dedicated register is being set. If the userspace requests pRAA, this works, because the check validates the pipeline: v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=pRAA \ --stream-mmap --stream-count=1 --stream-to=frame.raw but, with v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=RG10 \ --stream-mmap --stream-count=1 --stream-to=frame.raw unicam complains at validation level: image: format mismatch: 0x300f <=> RG10 little-endian (0x30314752) This should work, because MEDIA_BUS_FMT_SRGGB10_1X10 can be packed into either RG10 or pRAA depending on the packing register. To fix this, modified the condition check to also allow in the case when requested format (fmt->pixelformat) is equal to fmtinfo->unpacked_fourcc. Fixes: 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association") Cc: stable@vger.kernel.org Signed-off-by: Eugen Hristev Reviewed-by: Jai Luthra Reviewed-by: Dave Stevenson [Sakari Ailus: Added Cc: stable.] Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit a6a568171d18918e594c351359ded52f151ae721 Author: Ming Qian Date: Thu Jun 11 17:17:00 2026 +0900 media: amphion: Remove obsolete frame_count check in venc_start_session commit 2be6ee86385badab95b1bace984735bde6e0fec0 upstream. The dev_err() log warning about no input when starting was originally meaningful when min_queued_buffers was set, as it indicated an abnormal condition. However, since commit 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") removed the min_queued_buffers assignment, having frame_count == 0 at start is a normal condition. Remove this misleading log that no longer serves any purpose. Fixes: 5633ec763a2a ("media: amphion: Drop min_queued_buffers assignment") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c6749ac8f59cc80eb1b2d52f167fdf13e12655cc Author: Valery Borovsky Date: Sat May 23 19:53:49 2026 +0300 media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref commit 2f378dc45e685fc825d2dd08e7864666d6fcc009 upstream. airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cc2bc29770b312d1caff6bcd5c4c395e64d98831 Author: Danilo Krummrich Date: Sun Jun 28 16:53:21 2026 +0200 rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream. References to dev, data, and file in the declare_drm_ioctls! macro are created via unsafe pointer dereferences, producing unbounded lifetimes. If an ioctl handler explicitly annotates its parameters with 'static, the compiler accepts this, allowing the handler to stash references that outlive the ioctl call. Fix this by adding a higher-ranked function pointer coercion that enforces the handler accepts universally quantified lifetimes: let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func; Since the handler must be coercible to a function pointer accepting any lifetime 'a, it can no longer demand 'static on any parameter. Cc: stable@vger.kernel.org Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/ Suggested-by: Gary Guo Reviewed-by: Alexandre Courbot Reviewed-by: Lyude Paul Tested-by: Deborah Brouwer Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit c4357ebeee63cb8da1446fc936573a34e68b0f71 Author: Jérémy Jean Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Avoid preempt count underflow without probe commit 72ce4b24676e8b3b75376c4c559dd81c1ac52d5a upstream. LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline. Cc: stable@vger.kernel.org Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Link: https://lore.kernel.org/loongarch/1670575981-14389-3-git-send-email-yangtiezhu@loongson.cn/ Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c048b0a3c0836c4b1bef4b51d355d27090bf6790 Author: Wentao Guan Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: Do not save/restore percpu base register in rethook trampoline commit c3f2feace5e4f4b01b68b9f947b19adb4155c32e upstream. The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it. Cc: stable@vger.kernel.org # v6.3+ Fixes: 3f5536860086d ("LoongArch: Add kretprobes support") Assisted-by: Kimi:Kimi-K3 # debug and root-cause analysis Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit fbf6ed7d827b4a7c682f4ec3aa3df263907b2520 Author: Nathan Chancellor Date: Fri Sep 4 21:44:23 2026 +0800 LoongArch: Do not select HAVE_RUST when KASAN is enabled commit 63b6a48c951d63bf39d44603ada48a987ccf66eb upstream. After commit 2625480a1bf7 ("hardening: Default randstruct off with rust for better allmodconfig support"), which allows Rust to be enabled for allmodconfig, ARCH=loongarch allmodconfig starts failing with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:741: rust/core.o] Error 1 For the same reason as the commit 84a0f7caafc679f7 ("ARM: Do not select HAVE_RUST when KASAN is enabled"), do not select HAVE_RUST when KASAN is enabled until the loongarch64-unknown-none-softfloat target in rustc supports KASAN. Cc: stable@vger.kernel.org Fixes: 90868ff9cade ("LoongArch: Enable initial Rust support") Acked-by: Miguel Ojeda Signed-off-by: Nathan Chancellor Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6311b8c471afa33c18adbe4eb16f862936b71ca3 Author: Bibo Mao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Fix acpi_package_ids[] array overflow commit 2a2367d46d7a4ee4122b7a86e57125542dbbe963 upstream. With LoongArch virt machine, a typical setting is one core per socket, there will max 256 sockets (packages) on one VM. With PPTT acpi table, array acpi_package_ids[] will be overflowed. Here change the array size of acpi_package_ids[] with the max value of MAX_PACKAGES and KVM_MAX_VCPUS. Cc: stable@vger.kernel.org # 6.7+ Fixes: 4e8f58620f67 ("LoongArch: Retrieve CPU package ID from PPTT when available") Reviewed-by: Tao Cui Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 90b84201cb651356b2c91a717014cf4223945dea Author: Tiezhu Yang Date: Fri Sep 4 21:44:43 2026 +0800 LoongArch: BPF: Fix off-by-one error for insn_is_cast_user() commit 30419a0aa128135a81be917eaa3bd2f1a10c9ca3 upstream. In the LoongArch BPF JIT code, the branch offset represents the number of instructions. An offset of 1 means the target of the "beq" is the current PC plus 1 instruction (PC + 4 bytes). This matches the exact same path as the sequential non-branch execution, the "or" instruction is always executed for the cast_user JIT arm in build_insn(). If the pointer is not NULL, there is no side effect. But if the pointer is NULL, it is incorrectly combined with the base address and turns into a non-zero address, meaning a zero arena offset no longer casts to NULL. Fix this by changing the branch offset from 1 to 2, which properly skips the "or" instruction and jumps directly to the "move_reg" instruction if the pointer is NULL, ensuring the destination register is safely cleared to 0. Cc: stable@vger.kernel.org Fixes: 4fdb5dd8aeba ("LoongArch: BPF: Implement bpf_addr_space_cast instruction") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit f0e4d069cb47cf4f8dc4f6bc104e0671155aa3b9 Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Move arena register slot below TCC context commit cd7e356b07a27e91394838cf3fb655862b519294 upstream. Currently, the stack layout places the optional arena register slot above the tail call counter context. When arena_vm_start is dynamically enabled, it shifts the relative offset of the tcc_ptr slot within the stack frame, causing hardcoded tracking macros to mismatch and leading to memory misalignment or corruption potentially. To fix this, move the arena register save and restore sequences below the tail call counter context slots in both build_prologue() and the epilogue. Update __build_epilogue() to insert a proper offset decrement to safely skip the unneeded tcc_ptr reading block while accurately aligning with the relocated arena slot at the very bottom. With this patch, the tcc_ptr slot is always positioned at a fixed distance directly underneath the base callee-saved registers that is independent of whether the arena features are on. Cc: stable@vger.kernel.org Fixes: ef54c517a937 ("LoongArch: BPF: Implement PROBE_MEM32 pseudo instructions") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 00cdb31f17c7cd61e5292479b2ce1bd9d6fb485d Author: Tiezhu Yang Date: Mon Aug 17 22:07:14 2026 +0800 LoongArch: Expand module virtual address space to 2GB commit 18210a104bb97e28c26dc31fd9fc7b5c381fec62 upstream. The current 256MB module virtual address space is easily exhausted when loading massive graphics drivers such as amdgpu along with the large unstripped symbol tables, resulting in allocation failures of "execmem: unable to allocate memory". Thus, expand the module virtual address space to 2GB while keeping the current normal code model '-mcmodel=normal', rather than using the medium code model '-mcmodel=medium'. This approach avoids the extra performance overhead and larger binary size of forcing every function call into a 2-instruction sequence of 'pcaddu18i + jirl'. Given that individual module code segments rarely exceed 128MB, most jumps remain fast direct calls by using the bl instruction. For the long-distance jumps exceeding the +/-128MB limit, apply_r_larch_b26() emits PLT entries, while signed_imm_check() guarantees the run-time safety by rejecting any out-of-bound instruction offsets. There is still a risk that the distance between .init.text and .text of the same module exceeds 128MB. So we divide the 2GB virtual space to be two sub-regions: the first 256MB is for module text, and the rest is for module data. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 96f44d493c280ea161569c43d7ed0f3b0815803a Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Refactor jump offset calculation in tail call commit 37d545d12f21c4d50612ecaebd7ae1e5bf91b2d8 upstream. The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes. Fix this by calculating the offset directly on the absolute target: "ctx->offset[insn + 1] - ctx->idx". To avoid a false 16-bit range check abort during size estimation, add a "ctx->image == NULL" guard to inject a safe dummy offset. Cc: stable@vger.kernel.org Fixes: cd39d9e6b7e4 ("LoongArch: BPF: Fix jump offset calculation in tailcall") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 2a148e146993e751383e4c69d942f72f06a1f330 Author: Tiezhu Yang Date: Mon Aug 17 22:07:23 2026 +0800 LoongArch: BPF: Optimize redundant TCC loads in epilogue commit fd3cb1bfeb9d98618bd709bfee9c1133e9f189e6 upstream. The legacy epilogue implementation pops the tail call counter (TCC) context via a redundant double-load pattern. It first decrements the load_offset by 2 slots to fetch 'tcc_ptr', and then immediately bumps it back up by 1 slot to load the original 'tcc' value into REG_TCC, unnecessarily overwriting the register. Optimize this sequence by adjusting the load_offset by only 1 slot. This aligns the offset directly with the higher stack slot containing the entry TCC counter (or caller state), allowing us to restore the REG_TCC register safely with a single load. This removes one redundant instruction from the epilogue hot path, improves code readability, and ensures the correct TCC register context is handed back cleanly upon normal return. Cc: stable@vger.kernel.org Fixes: c0fcc955ff82 ("LoongArch: BPF: Fix the tailcall hierarchy") Fixes: ef54c517a937 ("LoongArch: BPF: Implement PROBE_MEM32 pseudo instructions") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 55e18311c705cceef6c34d522ea387b1f0069bab Author: Han Gao Date: Mon Aug 17 22:07:05 2026 +0800 LoongArch: Add DIRECT_MAP_PHYSMEM_END definition commit 2677f97a67fdbc62a82ce1faa67791f54451d36f upstream. get_free_mem_region() and mhp_get_pluggable_range() bound their search to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is (1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpu_pabits, probed from CPUCFG1). The vmemmap window only covers physical space below 2^(cpu_pabits+1) (i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return a ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then wraps the memmap range around and maps it into low memory, silently corrupting the page tables. The same search also picked the top-of- address-space region that crashed memmap_init_zone_device() with amdkfd on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") keeps that region in bounds on current Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g. the Loongson-2K series) are still affected. Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, (1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END"). [1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/ Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Han Gao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 83715a40a2d30d23719e0b25380ba82ff905195b Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Validate MSI data before routing it to EIOINTC commit 501514d6ebd2111c353a1296f25dbe22fbd64657 upstream. pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as the irq number. The MSI data comes from userspace, that either via a KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked against EIOINTC_IRQS. eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value >= 256 reads and writes memory past the end of those arrays, i.e. any process holding a VM fd can corrupt kernel memory beyond the allocation of loongarch_eiointc. Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC path is unaffected as it decodes the vector from the address and masks it. Cc: stable@vger.kernel.org Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/ Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit bc7a6849b4395f45a602db91b0fb2fb2e9ed4bba Author: Zeng Chi Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY commit 27a9bfee3bbcb3cabb77797354f07e0e44e49831 upstream. kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb505b2a ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui Reviewed-by: Tao Cui Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 3bf6f5e2e1007d38a5f35bd37e94ab645a0c40bc Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Free init resources if kvm_init() fails commit f7a1064cce3b100b54780c68529176232d8eb01e upstream. kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac687261 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 26bda95b64e8f867c926a21a8ee0899de36be211 Author: Tao Cui Date: Fri Sep 4 21:45:13 2026 +0800 LoongArch: KVM: Fix TOCTOU race on pv_features commit 9296375902579f9b0e456bbb76e5cf179e5a4e0b upstream. In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit de54ab63ef12736fb3323d03262fca1f109d506d Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:54 2026 +0800 LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path commit 910132bc7d72f26a8b288c2a38c32445a48d5be0 upstream. kvm_loongarch_env_init() allocates the per-CPU kvm_context (vmcs) and kvm_loongarch_ops, registers the perf callbacks, and then registers the IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices. If any of those device registrations fails, the function returned the error directly, leaving everything acquired so far in place: vmcs and kvm_loongarch_ops are never freed, the perf callbacks stay registered, and all previously registered KVM device operations remain registered. kvm_loongarch_init() propagates the errors without calling kvm_loongarch_env_exit(), so nothing else cleans up either. Unwind the error path in reverse order of registration, so that each failure only undoes what had actually been set up. Use the same helpers in kvm_loongarch_env_exit() to remove the device registrations during normal teardown as well. Cc: stable@vger.kernel.org Fixes: c532de5a67a7 ("LoongArch: KVM: Add IPI device support") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 4595c9b2bdb0d42703fcde84540b1816d6dbe974 Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Add unregister helpers for the KVM interrupt devices commit 4af22177032ab2357bf551fbfcdebc8fd9f2502d upstream. The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that registers their kvm_device_ops, but there is no counterpart to remove them, so a caller that needs to undo a registration has to open-code kvm_unregister_device_ops() with the matching device type. Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device() next to the existing register helpers. kvm_unregister_device_ops() is a no-op when the corresponding device type is not currently registered. No functional change, as there are no callers yet. Cc: stable@vger.kernel.org Suggested-by: Bibo Mao Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 8e61f76e74583b4e3f24983426c1e0dd05008e6b Author: Zeng Chi Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Fix PC double advance in kernel MMIO read fast path commit fd4021529faa931818186b6e83bd46f5de7517eb upstream. In the in-kernel MMIO read fast path of kvm_emu_mmio_read(), kvm_complete_mmio_read() already advances the guest PC via update_pc(). The explicit update_pc() call right after it advances the PC a second time, so PC moves forward by 8 bytes instead of 4, and the instruction following the MMIO read is silently skipped. The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run() calls kvm_complete_mmio_read() only once, and the MMIO write fast path advances the PC exactly once as well. Here remove the redundant update_pc() so the kernel MMIO read fast path advances the PC by a single instruction. Cc: stable@vger.kernel.org Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation") Reviewed-by: Bibo Mao Reviewed-by: Tao Cui Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit f56060b0e10fa5633fac1dc243a25da3a5cdafb1 Author: Bibo Mao Date: Mon Aug 10 12:21:57 2026 +0800 LoongArch: KVM: Fix uninitialized stack variable issue with dmsintc commit 81aa3a58b542ed88819115c80a17acd86eacb89d upstream. Variable vector[] is declared on stack in function dmsintc_inject_irq() and sometimes it is used without initialized. Here fix this issue. Cc: stable@vger.kernel.org Fixes: 03de5eecb0f0 ("LoongArch: KVM: Add DMSINTC inject msi to vCPU") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 46aa64821f6c092d94fbb45be396c07554eb7362 Author: Bibo Mao Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set commit 32d05564a6128d59ea876cf9078fe6866a809e14 upstream. In function kvm_make_vcpu_request(), it will send IPI to physical CPU when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set. Otherwise IPI will send to wrong old physical CPU where vCPU is running. Cc: stable@vger.kernel.org Fixes: 2fc3bd86db4b ("LoongArch: KVM: Implement basic vcpu interfaces") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 2de38f0448b45d27eba984fc0d9edb7a138972c2 Author: Marc Zyngier Date: Mon Aug 10 18:06:16 2026 +0100 KVM: arm64: Correctly cap TLBI Range to the architural limit commit 69a598288195947a1662b53de702eb6976af96b7 upstream. TLB Invalidation by Range has a fairly powerful way of encoding pretty large ranges in a small number of bits. This range can be based on an arbitrary VA, which means it is pretty easy for a guest to generate an overflow should the hypervisor be naive enough to add the range to the base... Make sure the range is capped to the limit dictated by the address bit that determines the VA range. For an IPA invalidation, this is further corrected down the line to ignore the upper range. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: Wei-Lin Chang Link: https://lore.kernel.org/r/yifz3wn5gk5sr6mapi32trgk5m5kp33bquctsjmkifebnsnndt@fix6u4rthx4g Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Wei-Lin Chang Link: https://patch.msgid.link/20260810170616.746100-1-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 36df368861d2664291298feeb37dfef43fcae670 Author: Fuad Tabba Date: Fri Aug 7 11:40:59 2026 +0100 KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save commit c6c156d931c33b92362383cf76f6d6e1291dcbfe upstream. MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 2bf6e59be382a752b1aea33691c04b7f08aa5d42 Author: Fuad Tabba Date: Sun Aug 2 16:08:45 2026 +0100 KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failure commit 43347154e7ab642474c886bc54ad090166c0d9c9 upstream. kvm_vgic_create() sets vgic.in_kernel before allocating the per-vCPU private IRQs, but the allocation-failure path resets only vgic_model and leaves in_kernel set. As irqchip_in_kernel() is !!in_kernel, the VM is left with an in-kernel irqchip but no model, and the -EEXIST guard at the top of kvm_vgic_create() rejects every retry, so userspace cannot recover from a transient -ENOMEM. Reset in_kernel alongside vgic_model on the failure path. Fixes: 9435c1e1431003 ("KVM: arm64: gic: Set vgic_model before initing private IRQs") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Acked-by: Marc Zyngier Link: https://patch.msgid.link/20260802150845.3485757-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit b6c2abf620a45da86fb1f2b2dc0f82e11240d78a Author: Kajetan Puchalski Date: Mon Aug 10 11:29:24 2026 +0100 KVM: arm64: vgic: Fix detection of MI on no pending LR commit a342faadc5acbd5d9fd894fd4499d4fd614dfcf6 upstream. As per the ARM GICv3 spec, the maintenance interrupt identified by ICH_MISR_EL2.NP is asserted when it is enabled and no List register is in pending state. This is further described in the document as "no List registers with the State field set to 0b01 (pending)". By checking only the pending bit of the LR (bit 62), KVM currently asserts the MI when there are no LRs in "pending" or "pending and active" states. Fix the detection logic to consider only the "pending" state. Cc: stable@vger.kernel.org Fixes: 96c2f03311de ("KVM: arm64: nv: Plumb handling of GICv3 EL2 accesses") Signed-off-by: Kajetan Puchalski Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260810102923.2426475-2-kajetan.puchalski@arm.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit d3a2d20b7248ea67465af1cf79c79f90ff70926c Author: Qihang Date: Fri Aug 7 10:55:34 2026 +0800 KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables commit f5b8f203bfc07a5a257dff859e66d2c500f9f509 upstream. vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI. The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes. A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes. Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code. Cc: stable@vger.kernel.org Signed-off-by: Qihang Reviewed-by: Marc Zyngier Link: https://patch.msgid.link/20260807025534.34125-1-q.h.hack.winter@gmail.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 3feb83918e30f0472e058224b926ebfe8a064fac Author: Marc Zyngier Date: Thu Aug 6 10:10:24 2026 +0100 KVM: arm64: Sign-extend VA for range-based TLBI invalidation commit 2393470085649f0b973ecceb26fe8fc71edde0c1 upstream. When the decode_range_tlbi() helper was moved to be used for S1 TLBIs, the required sign extension was omitted. Add it. As a result, special care must be taken to not overflow PA bits when this is used for S2 invalidation. Fixes: 85bba00425ae0 ("KVM: arm64: nv: Move TLBI range decoding to a helper") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130337.EB2BA1F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-7-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 87c2bbf189829dce4aaada8f82e3d54ccc037976 Author: Marc Zyngier Date: Thu Aug 6 10:10:19 2026 +0100 KVM: arm64: Remove VM-wide VNCR mapping counter commit c55bc773b6e814406658fae7dc5c15f639ed816e upstream. The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reviewed-by: Yuan Yao Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Acked-by: Lorenzo Stoakes (ARM) Link: https://patch.msgid.link/20260806091026.620700-2-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 11ee3faab4f1755d126bead9f882e75a7a677860 Author: Marc Zyngier Date: Thu Aug 6 10:10:25 2026 +0100 KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry commit 2b7324f3a0c1072b9d578b8d42f199506753f26e upstream. A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1. Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130454.5D9F11F00AC4@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-8-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 9065c1261f8a05c6a7a2d90048c7c0665ab2896d Author: Marc Zyngier Date: Thu Aug 6 10:10:23 2026 +0100 KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping commit 38640bc32be3fcf9526d477155bc19d3f146231f upstream. While VNCR TLB invalidation always occurs under the MMU lock, vcpu_put() doesn't, while it unmaps the VNCR page. The problem is that the invalidation evaluates vncr_tlb::cpu to decide whether an unmapping needs to take place (cpu != -1) before performing it. On the other hand, this_cpu_reset_vncr_fixmap() unconditionally unmaps if L1_VNCR_MAPPED is set. These two obviously can race, with a TOCTOU pattern on the TLBI path, and a BUG_ON() on the vcpu_put() path. And the two can end-up calling vncr_fixmap(-1), with extra lethal effects. Move the reset of vncr_tlb::cpu to -1 to a common function, and make this update atomic so that only a single thread can reset the field and perform the corresponding unmap. The vcpu_put() still need to unconditionally unmap the current VNCR to close another ugly race. Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync with the actual mapping, similar to L1_VNCR_MAPPED being set. Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/r/20260801130237.0FD8F1F00ACA@smtp.kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Yuan Yao Link: https://patch.msgid.link/20260806091026.620700-6-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit c624731ca6fe59ad8909ce4108301aa7560a91d6 Author: Marc Zyngier Date: Thu Aug 6 10:10:22 2026 +0100 KVM: arm64: Correctly handle end of VA space TLBI invalidation commit 34af2c3e31f91a739dc175459fdbd99ed952b457 upstream. Our TLB invalidation by VA code is based on comparing two ranges, one defined by the TLB, and one defined by the TLBI instruction. Each range is defined by a start and a size. However, the way the comparison is done doesn't account for address rollover, as it compares an address with (base + size). This works nicely until this expression represent the last page/block in the TTBR1 VA space, as the result is a big fat 0. And a failed TLB invalidation. Rewrite the comparison in a way that is immune to the address rollover (making the end address inclusive instead of exclusive), and move this into a common helper that is used by both VA and IPA invalidations, as suggested by Hyunwoo Kim (although the IPA version didn't suffer from this particular problem, obviously). Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Reviewed-by: Yuan Yao Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-5-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 1c9fca34b9625a67a7f1a03c8604f3df760c6c49 Author: Marc Zyngier Date: Thu Aug 6 10:10:20 2026 +0100 KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation commit 8053393680d4fa3eb962667d2be95dd39f0940e5 upstream. Computing the effects of a TLB invalidation involves looking at the size of the mapping cached by the TLB. For S1 mappings such as VNCR, this is deducted from the combination of the base granule size and the mapping level. However, this implies that the S1 MMU is *on*. When the MMU is off, we indicate this with the level being set to a "creative" value of -127 (S1_MMU_DISABLED). This ends-up being misinterpreted by pgshift_level_to_ttl() as it doesn't handle negative levels at all (the level is immediately cast to a u8 and only the bottom two bits considered), leading to an invalidation size of 0. Not helpful. Tidy-up pgshift_level_to_ttl() to handle these negative levels, and ttl_to_size() to always return SZ_1G when no valid TTL is present. This allows the removal of open-coded checks for similar situations. Note that the check for a negative value not explicitely checking for S1_MMU_DISABLED is deliberate, so that actual negative levels introduced with LVA2 and D128 can take the same path if we ever support them. Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 66c36dd6599543e8bc0c149b266b4ec38409b604 Author: Marc Zyngier Date: Thu Aug 6 10:10:21 2026 +0100 KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page commit 8c774604b6ecaca495fa3d27c21593269627f48f upstream. We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make our life easier. But this is not something that the architecture anticipate. As a consequence, a hypervisor is free to set VNCR_EL2 to some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with the same VA. Yes, this is odd, but apparently legal. A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being flipped. But doing this is a not a good idea for us (we'd need to trap SCTLR accesses), and wouldn't scale as we nest deeper. Instead, use the fact that the S1 MMU being off at the point of translation is cached in our TLB, and if it doesn't match the current MMU state, leave the VNCR unmapped. Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260806091026.620700-4-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit f3064dde05527951efba65ea3a54206d76c92f62 Author: Christian Borntraeger Date: Tue Aug 11 17:37:38 2026 +0200 KVM: s390: Restore sigset on error path commit c44d36d8e6501c4934412d9014e5e02da9efdb8f upstream. kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3a131f7758d33a212e7b7e316da7fd05c06158c9 Author: Christian Borntraeger Date: Tue Aug 11 17:37:37 2026 +0200 KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP commit 1e3c8e7b3465fb8a49d3623d2d0f449c0b5b48f3 upstream. The rc/rrc value is copied to the cmd location of the cmd in the kvm_pv_cmd structure. Fix the offset. Fixes: 8aba09588d2a ("KVM: s390: Add CPU dump functionality") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit ae452b990e0544425f77045351c56e77158858e7 Author: Christian Borntraeger Date: Tue Aug 11 17:37:35 2026 +0200 KVM: s390: keyop: use mmu_lock to read gmap->asce commit da07a751efa4583385f9f0f47113549fe8871242 upstream. Every other dat_* consumer in this file (kvm_s390_get_skeys, set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads kvm->arch.gmap->asce *inside* the mmu_lock read-side. keyop is the only outlier. gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit() and keyop might use a stale asce value for walking as KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result in memory corruption. Fixes: 0ee4ddc1647b ("KVM: s390: Storage key manipulation IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-2-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 7077ec953996acc04b49d1dfc43df1c1a2a74395 Author: Christian Borntraeger Date: Thu Aug 6 16:58:35 2026 +0200 KVM: s390: Fix memory corruption by not reinjecting CK machine checks commit 546dde823a36d7283dcf46127c2f3d093443860f upstream. Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Acked-by: Heiko Carstens Acked-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260806145835.31818-1-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit f8ed98e97a460decbd452b35efef3bdf3000aabc Author: Christian Borntraeger Date: Wed Aug 5 13:04:50 2026 +0200 KVM: s390: Zero initialize irq in reinject_machine_check commit b239410c7653ff6781d4cf1d63cfc52a1bb71788 upstream. kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 134f235e0e8de54611a72d3cc3f63e5f31246baa Author: Christian Borntraeger Date: Wed Aug 5 13:04:49 2026 +0200 KVM: s390: Zero initialize data structures for inject_pfault_token commit 4e2c7f7cbc27418f9a290399b986c1b85ff93b90 upstream. __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure. Fixes: 383d0b050106 ("KVM: s390: handle pending local interrupts via bitmap") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-3-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 4c05bf21d1806853e662cc19e744736a3408f155 Author: Christian Borntraeger Date: Wed Aug 5 13:04:53 2026 +0200 KVM: s390: Take srcu when importing watchpoint data commit a4e482def8533ebace517d9f67f1465841b1f982 upstream. __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-7-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit e4d8b7f176b976474e0800ba71ee2dfa3ce263c9 Author: Christian Borntraeger Date: Wed Aug 5 13:04:54 2026 +0200 KVM: s390: Free guest debug data on vcpu destroy commit e7f698b09d4a7c36b299acf680fc50fe868e2bcd upstream. kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-8-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 46cb8a273e2f853f89a78b59dbdff8787b6e1c86 Author: Christian Borntraeger Date: Wed Aug 5 13:04:52 2026 +0200 KVM: s390: Fix old_data leak in guest debug error path commit aa9c8e8baf1e765fa65b93212522c636f25d846f upstream. __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-6-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 581be9f6085834188cef1ad2f07babf3b421e409 Author: Christian Borntraeger Date: Wed Aug 5 13:04:51 2026 +0200 KVM: s390: Fix memory leak in guest debug handling commit 121ea1de927c8b9bfdf53c31cad27b86d5de0293 upstream. bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit 3fe801db90bdeefb0bbdda42d832846b53f64f8a Author: Christian Borntraeger Date: Wed Aug 5 13:04:55 2026 +0200 KVM: s390: Fix length check __import_wp_info() commit 4c07680a467e2f7697245bcd11691bffb2a6f0ed upstream. struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER. Fixes: 27291e2165b6 ("KVM: s390: hardware support for guest debugging") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-9-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit ac943db6e5fac8d7eec1692d9bcb5401a2cd6f57 Author: Yosry Ahmed Date: Mon Jul 13 18:10:16 2026 +0000 KVM: x86: Move enabling EFER.SVME and EFER.LMSLE to generic EFER setup commit 6ccc19d4c1eb97a994180af8afcab58422cb409d upstream. Move SVM-specific EFER bit enablement to generic x86 code, with the rest of EFER bit enablement. Unifying the code for EFER bit enablement allows for a later change to re-initialize EFER bits on module init. No functional change intended. Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713181020.2735367-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a97d4eb883d3ca997560c5f945f79255a6d4b5db Author: Sean Christopherson Date: Thu Jul 9 13:49:36 2026 -0700 KVM: x86: Ensure runtime reads of disabled_quirks are resolved once commit ed15cb21999217e549414c128b4a0485debf6278 upstream. Wrap the sole reader of disabled_quirks with READ_ONCE(), and wrap the post-VM-creation write to disabled_quirks with WRITE_ONCE(), to ensure checking the status of a quirk doesn't re-read disabled_quirks *if* the caller needs such a guarantee. This will allow splitting the "fast" MMU zap into front and back halves, without potentially skipping the back half if SLOT_ZAP_ALL were concurrently disabled (which would be "fine" in the current code base, but far from ideal). Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-7-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 92e24ca69e0f8e4ac28c09fd56d9a008d990e17c Author: Sean Christopherson Date: Thu Jul 9 13:49:35 2026 -0700 KVM: x86: Serialize writes to disabled_quirks using kvm->lock commit ba76b23ed36ab230fc2577aba24f65851114902f upstream. Protect writes to disabled_quirks with kvm->lock to ensure KVM doesn't clobber state in the unlikely scenario that userspace disables disparate quirks from multiple tasks. More importantly, this will allow wrapping accesses with {READ,WRITE}_ONCE without "needing" to also guard the writer with a useless and confusing READ_ONCE (since the RMW wouldn't be atomic anyways). Ideally, KVM would disallow disabling quirks once quirks are "live", but that would be a potentially breaking userspace ABI change, and while all existing quirks are fully live only after vCPUs have been created, several MMU-related quirks, IGNORE_GUEST_PAT and SLOT_ZAP_ALL, are partially live at all times. Because populating MMUs requires a vCPU, the guest-visible behavior of IGNORE_GUEST_PAT and SLOT_ZAP_ALL requires a vCPU, but for KVM itself, processing the quirk (or not) has functional impact, i.e. for all intents and purposes, KVM can't prevent those quirks from being disabled after they've been consumed. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit bdb732ebee545b7e3bee7060efc754a8d99818b9 Author: Carlos López Date: Tue Jul 14 15:32:13 2026 +0200 KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock commit 0ca49fbd2883cd53d32d85b50feef17fa04d0fbf upstream. Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d077 R09: 1ffffffff1f87a0e R10: dffffc0000000000 R11: fffffbfff1f87a0f R12: dffffc0000000000 R13: 0000000000000000 R14: ffff8880b8628240 R15: 1ffff92000814e64 hrtimer_start include/linux/hrtimer.h:259 [inline] stimer_start arch/x86/kvm/hyperv.c:682 [inline] kvm_hv_process_stimers+0xd0a/0x16a0 arch/x86/kvm/hyperv.c:893 vcpu_enter_guest arch/x86/kvm/x86.c:11193 [inline] vcpu_run+0x2240/0x76b0 arch/x86/kvm/x86.c:11639 kvm_arch_vcpu_ioctl_run+0x1148/0x1c90 arch/x86/kvm/x86.c:11984 kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4492 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+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f635278f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f635365c038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f63529e5fa0 RCX: 00007f635278f749 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00007f6352813f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f63529e6038 R14: 00007f63529e5fa0 R15: 00007ffd5b219358 Fix this by clamping the deadline computation to KTIME_MAX, which preserves the intent of arming a timer very far in the future. ktime_add_safe() already does this type of clamping, so use it after checking that that multiplying by the 100ns time tick also does not overflow. Reviewed-by: Vitaly Kuznetsov Reported-by: syzbot+3d5461510f8dc4adfe30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d5461510f8dc4adfe30 Fixes: 1f4b34f825e8 ("kvm/x86: Hyper-V SynIC timers") Cc: stable@vger.kernel.org Signed-off-by: Carlos López Link: https://patch.msgid.link/20260714133212.3916611-3-clopez@suse.de [sean: tag for stable] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 8edb3c09e43f7cd8a5dfd291c6e0fc9c74d4621d Author: Phil Rosenthal Date: Mon Jul 20 13:45:49 2026 -0400 KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk commit e428f9779a43737d830111238816f1928b07aefb upstream. __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: * Elide the lock if the rmap is empty, as lockless walkers (read-only * mode) don't need to (and can't) walk an empty rmap, nor can they add * entries to the rmap. I.e. the only paths that process empty rmaps * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code. Fixes: af3b6a9eba48 ("KVM: x86/mmu: Walk rmaps (shadow MMU) without holding mmu_lock when aging gfns") Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: Phil Rosenthal Link: https://patch.msgid.link/20260720-rmap-age-elided-submit-v2-1-668973030d47@phil.gs Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 655694a1cba2da170cf26674aab353549c1ef84e Author: Sean Christopherson Date: Mon Jul 27 17:22:35 2026 -0700 KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU commit 3d679b7cb31f74bf2303123ce4ee3266eeee999a upstream. Use LOCK CMPXCHG instead of LOCK AND to clear the Accessed bit when aging SPTEs in the TDP MMU, as doing a LOCK AND can corrupt a FROZEN SPTE and allow a third CPU to effectively overwrite the FROZEN SPTE. As pointed out by AI of some kind, because the magic FROZEN_SPTE value is a "full" SPTE, not a single bit, and includes the Accessed bit, clearing the Accessed bit in a FROZEN SPTE will result in is_frozen_spte() getting a false negative. E.g. if CPU0 freezes an SPTE, and CPU1 clears the Accessed bit in the frozen SPTE, then CPU2 could come along and overwrite the frozen SPTE with a shadow-present SPTE. Thankfully, the false negative is largely benign, because outside of TDX, which doesn't support aging, KVM only freezes leaf SPTEs when removing an upper level shadow page. So while KVM could clobber a frozen SPTE back to a shadow-present SPTE, and could even use the new SPTE, the subsequent TLB flush will make the orphaned, shadow-present SPTE unreachable. Failure to ever zap the orphaned leaf SPTE would show up in KVM's stats, but otherwise is benign (because KVM no longer keeps an elevated refcount for leaf SPTEs). Opportunistically add a comment to warn future developers away from using kvm_tdp_mmu_write_spte_atomic() and tdp_mmu_clear_spte_bits_atomic(), as they are generally unsafe. Keep the helpers, e.g. instead of open-coding the atomic64_fetch_and() in tdp_mmu_clear_spte_bits(), as scary warnings usually are more effective deterrent against recidivism than removal of the dangerous code. Alternatively, KVM could use different bits for the magic FROZEN_SPTE value, e.g. setting the Dirty bits (with effective IPAT and Global aliases) would likely be "ok", as IPAT/Global are extremely unlikely to be cleared without doing a full SPTE write, and KVM's clearing of Dirty bits shares logic with Write-Protection, which must do a full SPTE write (via cmpxchg64() in the TDP MMU) to ensure KVM isn't clobbering state. But there is zero reason to carry that risk (beyond stubbornness in wanting to preserve a "cute" idea), as the cost of LOCK CMPXCHG and LOCK AND are within 1-2 uops of each other on modern hardware. Fixes: b146a9b34aed ("KVM: x86/mmu: Age TDP MMU SPTEs without holding mmu_lock") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Reviewed-by: James Houghton Link: https://patch.msgid.link/20260728002236.869865-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 9941850e8adf164d005dbd3774c4b79e91a3cb8e Author: Yosry Ahmed Date: Tue Jun 16 21:46:52 2026 +0000 KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU commit 6d00e67326d831e6e610933a3800712f4ffe6ec1 upstream. When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs(). Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-4-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 62c3ee4c9f0e2efef5157358b3549e50ede96d73 Author: Yosry Ahmed Date: Wed Jul 22 23:01:28 2026 +0000 KVM: nVMX: Service local TLB flushes on failed nested VM-Enter commit 05a0b701d1089fb57beeb8982f23c3bbafe0fa8b upstream. KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated. Fixes: 5c614b3583e7 ("KVM: nVMX: nested VPID emulation") Cc: stable@vger.kernel.org Reported-by: Sashiko # Internal review Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260722230128.1587363-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit bbec4adc2f340d85f4a77a9ddcddaa6b1f4639c5 Author: Sean Christopherson Date: Thu Jul 23 17:47:52 2026 -0700 KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit commit 11722439fb206c88e6f31be54173efa9880b4ccb upstream. Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the "check" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME. Fixes: b4f69df0f65e ("KVM: x86: Make Hyper-V emulation optional") Cc: stable@vger.kernel.org Reported-by: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260724004757.131420-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 7fda9304d0d85c0b662a05bdf938aa26e3cfff81 Author: Sean Christopherson Date: Tue Jun 16 21:46:51 2026 +0000 KVM: nVMX: Decouple INVVPID operand checks from flushing of vpid02 commit 32912404b4b1ee98400744941c78f019a63d6e8f upstream. Separate the INVVPID operand checks from the actual flushing of vpid02 so the flushing can be adjusted to do the right thing when vmcs02 was last loaded on a different pCPU, without having to duplicate the logic across multiple case-statements. Opportunistically let the VM-Fail paths poke out past 80 chars. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260616214652.2157032-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 121991d150735f3c0f7401678ce4d35c5b4ac898 Author: Yosry Ahmed Date: Tue Jun 16 21:46:50 2026 +0000 KVM: nVMX: Always flush vpid02 on first use commit f0772389413dce9657c7d6950abf3edbbd511356 upstream. Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Reviewed-by: Kai Huang Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20260616214652.2157032-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit bb9f763d7aed4657dacdf88241d6875c4aeccdf0 Author: Amit Machhiwal Date: Tue Jul 14 23:24:32 2026 +0530 KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode commit 884ea0283f4effac97ee8f451464a7d1be480d7c upstream. On IBM POWER systems, newer processor generations can operate in compatibility modes corresponding to earlier generations. This becomes relevant for nested virtualization, where nested KVM guests may need to run with a specific processor compatibility level. Currently, when running a nested KVM guest (L2) inside a Power11 pSeries logical partition (L1) booted in Power10 compatibility mode, the guest fails to boot while setting 'arch_compat'. This happens because the CPU class is derived from the hardware PVR (via mfspr()), which reflects the physical processor generation (Power11), rather than the effective compatibility mode (Power10). As a result, userspace may request a Power11 arch_compat for the L2 guest. However, the L1 partition, running in Power10 compatibility, has only negotiated support up to Power10 with the Power Hypervisor (L0). When H_GUEST_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor rejects the request, leading to a late guest boot failure: KVM-NESTEDv2: couldn't set guest wide elements [..KVM reg dump..] This situation should be detected earlier and rejected by KVM. Without proper validation, if userspace ignores the error, the guest may continue to boot in Power11 raw mode on a Power10 compatibility host, which should not be allowed. Introduce a validation mechanism that detects unsupported arch_compat values early in the guest initialization path. When an unsupported arch_compat is requested (e.g., Power11 on a Power10 compatibility mode host), kvmppc_set_arch_compat() uses cpu_has_feature(CPU_FTR_P11_PVR) to detect the mismatch and sets arch_compat to PVR_ARCH_INVALID (0xffffffff). This sentinel value is architecturally safe: PAPR specifies that valid logical PVR values must have 0x0f as the first byte, ensuring 0xffffffff lies permanently outside the specification-defined range. Setting this value triggers kvmppc_sanity_check() to mark the vCPU as invalid by setting vcpu->arch.sane to false. On the next vCPU run, kvmppc_vcpu_run_hv() checks this flag and returns -EINVAL, preventing the guest from running with an invalid processor compatibility configuration. With this, when a Power11 arch_compat is requested on a Power10 compatibility mode host, the guest fails early during boot with: error: kvm run failed Invalid argument This provides a much clearer failure mode compared to the previous behavior where the guest could boot in Power11 raw mode (if userspace ignored the error) or fail late during H_GUEST_SET_STATE. Suggested-by: Vaibhav Jain Reviewed-by: Vaibhav Jain Tested-by: Anushree Mathur Acked-by: Gautam Menghani Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260714175432.86388-1-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit d393ef49d94f59e378023854cf383be8070f41ed Author: Nikhil Gautam Date: Tue Jul 14 17:01:34 2026 +0530 iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask commit d64bfd9f3352b9d9bdeca06de1a0a1c1bd47b896 upstream. GENMASK(h, l) requires h >= l, but OPT4001_CTRL_FAULT_COUNT is defined as GENMASK(0, 1). The define is currently unused so there is no functional impact, but fix it before anyone builds on it, and add the _MASK suffix for consistency with the neighbouring definitions. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fb21a4113e9119c7a9f3c1a129773af0cbd67a51 Author: Nikhil Gautam Date: Tue Jul 14 17:01:33 2026 +0530 iio: light: opt4001: Reject integration times with a non-zero seconds part commit d0f21621f8b2b46661ea066d20705dbf7253db87 upstream. opt4001_write_raw() only looks at val2 when setting the integration time, so a write such as 1.000600 is silently accepted as 600 us. Return -EINVAL if val is non-zero. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2fb1e09451aef2a39ad32f4f8b2f48d8fdf0c201 Author: Nikhil Gautam Date: Tue Jul 14 17:01:32 2026 +0530 iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem() commit afa28741c9a2cf6edb2e41e25ff146a562160bb3 upstream. div_u64_rem() takes a u32 * for the remainder but is passed val2, which is an int *. There is no functional impact as int and u32 have the same size and representation on all supported architectures and the remainder is always smaller than the divisor, so it fits in the positive range of int. Fix the type mismatch by using a local u32 for the remainder and assigning the result to *val2. Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4157573b37f648dd640ad7b30a9d8e100fbbe9dd Author: Nikhil Gautam Date: Tue Jul 14 17:01:31 2026 +0530 iio: light: opt4001: Fix power down clearing bits of the wrong register commit 3b2cd82c524c75a2173f2e3f874652a75f81cd1d upstream. opt4001_power_down() intends to clear the operating mode bits in the CTRL register but reads OPT4001_DEVICE_ID instead of OPT4001_CTRL, so the value written back to CTRL contains device ID bits rather than the current configuration. Fix and simplify this by using regmap_clear_bits() on the CTRL register directly in the devm action, and drop opt4001_power_down() which has no other users. Suggested-by: Jonathan Cameron Fixes: 9a9608418292 ("iio: light: Add support for TI OPT4001 light sensor") Signed-off-by: Nikhil Gautam Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0107ac927b1e7270a83a3adb61fabd6837a1ed30 Author: Vidhu Sarwal Date: Wed Jul 15 06:45:44 2026 +0530 iio: light: opt4060: Fix incorrect register name in threshold read error message commit ad367638212a9f2495ecfa59c886f0cfb7934e9c upstream. opt4060_get_thresholds() correctly reads OPT4060_THRESHOLD_HIGH, but logs "Failed to read THRESHOLD_LOW." if the read fails. This is a copy-and-paste mistake, as the preceding low-threshold read already uses the correct error message. Update the error message to reference OPT4060_THRESHOLD_HIGH. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7d2ddfee2952ed6d0d6f641ab1a0df5a4c500d0e Author: Vidhu Sarwal Date: Wed Jul 15 06:45:42 2026 +0530 iio: light: opt4060: Reject integration times with a non-zero seconds part commit b7e6e9af0d723afdec92364d5e7e064eeef44c8e upstream. When setting the integration time, opt4060_write_raw() only uses val2 and ignores val. As a result, a write such as 1.000600 is accepted and programmed as 600 us, silently discarding the whole seconds part. Since all supported integration times are less than one second, any non-zero val represents an invalid input. Reject such values instead of silently accepting them. Fixes: 0c6db4506ad0 ("iio: light: Add support for TI OPT4060 color sensor") Signed-off-by: Vidhu Sarwal Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a54b53b00e0f6a59404da7795777bb0e981735b5 Author: Paul Geurts Date: Mon Jul 6 09:48:03 2026 +0200 iio: ti-ads7138: Disable STATS_EN bit while reading conversion results commit bcb721c1bcb02ab225b3937bf131a0bc6fc1fecd upstream. There is a data race in reading the STATS registers, resulting in wrong data being read. When the data in the RECENT register switches between 0x24F0 and 0x2500, occasionally value 0x2400 or 0x25F0 is read. This happens when the value is updated in between reading MSB and LSB. The data sheet says: "Until a new conversion result is available, previous values can be read from the statistics registers. Before reading the statistics registers, set STATS_EN to 0 to prevent any updates to this register block." As the STATS_EN is currently not cleared, the values of the stats registers might change mid read, giving faulty values. Disable the STATS_EN bit before reading one of the statistics registers to make sure the device does not update the register mid read. This is applicable to registers MAX_CHn_xSB, MIN_CHn_xSB and RECENT_CHn_xSB. This means reading one of the statistics registers resets the MAX and MIN registers. This is unfortunate, but necessary to get correct data from the device. Signed-off-by: Paul Geurts Fixes: 024b08fee342 ("iio: adc: Add driver for ADS7128 / ADS7138") Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6b7584b976d584fb908a8e84335260c23a49f2b8 Author: Sanjay Chitroda Date: Thu Jun 25 17:46:11 2026 +0530 iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register() commit 967d066f5334740f656577bc51c381a1bb707b61 upstream. Avoid using devm_iio_device_register(), as this driver requires explicit error handling and teardown ordering. With devm_iio_device_register(), IIO device remains registered until the devres cleanup phase. However, driver's remove() callback removes the sensor hub callback and trigger support. This can create a race window where IIO device is still visible and read_raw() requests are issued. These requests might call sensor_hub_input_attr_get_raw_value(), which waits up to 5 seconds for a response from the sensor hub callback that has already been removed. Add an explicit iio_device_unregister() call in the teardown path to ensure deterministic cleanup, so that userspace can no longer access the device once backend resources begin to be dismantled. Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support") Cc: stable@vger.kernel.org Reviewed-by: Maxwell Doose Reviewed-by: Andy Shevchenko Signed-off-by: Sanjay Chitroda Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 44063a6673a63db99b45f9b547b1ec450cbcc84a Author: Cong Nguyen Date: Mon Jul 27 22:51:15 2026 +0700 iio: srf04: fix pm_runtime handling on probe error path commit a40b2e7a17f26e38ab054363c9c7cde149588357 upstream. When pm_runtime_set_active() fails during probe, the driver logs the error and unregisters the IIO device, but then falls through and still calls pm_runtime_enable() before returning the error. Since probe returns an error, srf04_remove() is never called, so runtime PM is left enabled without a matching pm_runtime_disable(). This leaks the enable and triggers an "Unbalanced pm_runtime_enable!" warning on a subsequent bind of the device. Return the error right after unregistering the IIO device so that runtime PM is not enabled on the failure path. Fixes: 2251157b335b ("iio: srf04: add power management feature") Cc: stable@vger.kernel.org Signed-off-by: Cong Nguyen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4a84300a1033d8c48174fef7bd1497bb74e8bb12 Author: Can Peng Date: Mon Jul 20 10:43:12 2026 +0800 iio: pressure: mpl115: Fix runtime PM cleanup commit 0b5e142ced4bcf20532da051934bd694d1bbd470 upstream. mpl115_probe() enables runtime PM when a shutdown GPIO is present and then returns the result of devm_iio_device_register(). If registration fails, runtime PM remains enabled and autosuspend remains selected. The same unmanaged runtime PM state is also left behind on driver unbind, as the IIO device registration is managed but the runtime PM setup is not. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on probe failure and driver unbind, and check pm_runtime_set_active() so setup errors are reported. Set the autosuspend parameters before enabling runtime PM. Once probe has completed, the driver core queues an idle request for the device, so an explicit pm_runtime_get_noresume()/pm_runtime_put() pair is not needed to start autosuspend. Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio") Cc: stable@vger.kernel.org Suggested-by: jonathan.cameron@oss.qualcomm.com Signed-off-by: Can Peng Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3fa189573cca284ae663bfd2d5b9ed755bec5e9d Author: Rupesh Majhi Date: Sun Jul 19 03:07:52 2026 +0300 iio: pressure: dps310: fix NULL pointer dereference on ACPI probe commit 26e9213898fc949923188ef0aeea31fc87708836 upstream. When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe. The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup. Fixes: 72ff282819d0 ("iio: pressure: dps310: Add ACPI HID table") Cc: stable@vger.kernel.org Signed-off-by: Rupesh Majhi Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 80e7381e8cccb543397572af153865f34aaf4353 Author: Vidhu Sarwal Date: Mon Jul 13 07:58:29 2026 +0530 iio: light: ltrf216a: fix runtime PM reference leak in error path commit c132aef0e757a39036b1d40faf0569f2e343b13e upstream. ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path. Fixes: 83f0bcd40d5c ("iio: light: Add support for ltrf216a sensor") Signed-off-by: Vidhu Sarwal Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c2c83ecb1ef7d5d507587714d0b5769481588375 Author: Laxman Acharya Padhya Date: Sat Jul 4 14:19:12 2026 +0545 iio: light: gp2ap002: Disable regulators on resume failure commit a41000ba3a230bed1e422f283486ff8f77fe0d30 upstream. If enabling VIO fails after VDD has been enabled, runtime resume returns without disabling VDD. Likewise, if device reinitialization fails, both supplies remain enabled. The runtime PM core keeps the device suspended when its resume callback fails, so the supplies must be restored to the suspended state. Disable the supplies enabled by the callback before returning an error. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Assisted-by: Codex:gpt-5 Signed-off-by: Laxman Acharya Padhya Reviewed-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c1870bbfcfdd2ada5f8fda30fb4af89ff7d37e4a Author: Giorgi Tchankvetadze Date: Fri Jul 31 17:20:48 2026 +0400 iio: light: cm32181: return zero after writing calibscale commit 8756acd30919a3e9f547ea4a1d4b7f7895f4d340 upstream. The write_raw callback is documented to return 0 on success or a negative error code. However, the IIO_CHAN_INFO_CALIBSCALE case returns 'val' (the user-supplied value) instead of 0. Fix it by returning 0 on success, matching the behavior of other calibscale implementations in the subsystem. Fixes: 971672c0b3cc ("iio: add Capella CM32181 ambient light sensor driver.") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3ce75e455dd6eaa775fb0badb31c0b100c7a01fe Author: Moksh Panicker Date: Sun Aug 2 19:07:01 2026 +0000 iio: light: apds9306: fix PM reference leak in apds9306_read_data() commit d378fceaafd79e0dc59d3546bda251a3058062c0 upstream. apds9306_read_data() calls pm_runtime_resume_and_get() but several error paths return directly without calling pm_runtime_put_autosuspend(), leaking the runtime PM reference and preventing the device from autosuspending. Use PM_RUNTIME_ACQUIRE_AUTOSUSPEND() and PM_RUNTIME_ACQUIRE_ERR() to automatically handle runtime PM reference release on all return paths. Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor") Signed-off-by: Moksh Panicker Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bc5fbf9868ca1c43ee741050a8a480874947aa4e Author: Francesco Lavra Date: Fri Jul 31 19:47:02 2026 +0200 iio: imu: st_lsm6dsx: Update enable mask when using sensor fusion commit 4a56c646e1bd4f22a2dcd65ef3723af957c651a9 upstream. The enable_mask struct member keeps track of which sensors are enabled in the IMU. When enabling and disabling the sensor fusion functionality, the driver does not properly update this struct member. This prevents a correct calculation of the number of samples that should be read from the hardware FIFO; as a result, reads from the FIFO can be unnecessarily split into multiple transactions, some of which can read past the FIFO length. Fixes: cd4e1141bff8 ("iio: imu: st_lsm6dsx: Add support for rotation sensor") Signed-off-by: Francesco Lavra Acked-by: Lorenzo Bianconi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 14db27a2f11af62f1a724b9c705c8ede7e1686a1 Author: Cong Nguyen Date: Sun Aug 2 13:55:40 2026 +0700 iio: gyro: mpu3050: fix sign of raw angular velocity readings commit 06fab97602fe400bea843176f485bbac07a668e2 upstream. The MPU-3050 gyroscope output registers hold 16-bit two's complement values; the angular velocity channels are declared with .sign = 's'. When mpu3050_read_raw() handles IIO_CHAN_INFO_RAW it reads the register via a big-endian regmap_bulk_read() and assigns it with: *val = be16_to_cpu(raw_val); be16_to_cpu() yields an unsigned 16-bit quantity, so negative rates (bit 15 set) are reported to userspace as large positive integers (e.g. -1 becomes 65535) instead of the correct negative value. Cast to s16 before the assignment, matching the temperature channel a few lines above which already handles the sign correctly. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Linus Walleij Reviewed-by: Joshua Crofts Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit daa1674ce8736f1c43ba6a3b06a353c52e79fb08 Author: Joshua Crofts Date: Wed Jul 8 21:50:28 2026 +0200 iio: dac: mcp47feb02: add missing 'select REGMAP_I2C' to Kconfig commit 739aac87638f06fcf851df41ecd52d30ab7b0570 upstream. The Kconfig entry for the MCP47FEB02 is missing a 'select REGMAP_I2C', causing build failures. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9fe22f563b2a0fdb11fd3711a8c39c023629c08a Author: Erick Henrique Date: Fri Jul 3 17:52:36 2026 -0300 iio: dac: m62332: Fix regulator reference count imbalance commit a130404ce0b69ca1438126bd81c1985d3b4d2e6f upstream. m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails. Fixes: b87b0c0f81e8 ("iio: add m62332 DAC driver") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260418130322.106769-1-erick.henrique.rodrigues%40usp.br Cc: stable@vger.kernel.org Signed-off-by: Erick Henrique Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 36f17988eb86c8e680cd058c13b9fecac0ae3cf6 Author: Can Peng Date: Tue Jul 14 17:18:45 2026 +0800 iio: dac: ad5446: fix OF module device table commit a3c03cf36a083893dedad928915471dc8c10692e upstream. The ad5446 I2C driver exports its OF match table with MODULE_DEVICE_TABLE(OF, ...). The device table type is used by modpost when generating module aliases, and scripts/mod/file2alias.c matches the lowercase "of" type. Using "OF" prevents the OF table from being recognized, so no OF module alias is generated for the I2C driver. Use the lowercase "of" type so OF-based module autoloading works. Fixes: 876d94024087 ("iio: dac: ad5446: Separate I2C/SPI into different drivers") Signed-off-by: Can Peng Reviewed-by: Joshua Crofts Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 98bbd0844aeda2c067d311ae457d0bd9de80540a Author: Babanpreet Singh Date: Sat Jul 18 18:22:36 2026 +0000 iio: dac: ad3552r-hs: fix scnprintf() buffer bound in data source show commit f2c5c76306fadb834dd5ea76cab0b7cd447e6035 upstream. ad3552r_hs_show_data_source_avail() formats the available data source names into a 128-byte stack buffer, but bounds each scnprintf() with PAGE_SIZE instead of the buffer size, so the bound does not protect the destination at all. This cannot overflow today - dbgfs_attr_source[] has two entries, "normal" and "ramp-16bit", 18 bytes formatted - but the bound stops protecting the stack the day the table grows. Use sizeof(buf) so the bound matches the destination. Found by smatch: drivers/iio/dac/ad3552r-hs.c:593 ad3552r_hs_show_data_source_avail() error: scnprintf() 'buf[len]' too small (128 vs 4096) Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Babanpreet Singh Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 44d52c8b1c6da7ac1b0dffeeff6de68370746775 Author: Linmao Li Date: Wed Jul 22 15:48:37 2026 +0800 iio: chemical: sgp30: Handle IAQ thread creation failure commit 1135d6875d2dbda3f6ec718f3421a6ce4378bd63 upstream. kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead. Fixes: ce514124161a ("iio: chemical: sgp30: Support Sensirion SGP30/SGPC3 sensors") Signed-off-by: Linmao Li Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 30b0d44c978bbc857bd68b71dab371805653de70 Author: Fan Wu Date: Sun Aug 2 07:18:58 2026 +0000 iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF commit be61c8c6252671ecf1fee0ad90f87669e0be1e20 upstream. The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool. Fixes: 7103b99b031c ("iio: chemical: atlas-ph-sensor: reorg driver to allow multiple chips") Cc: stable@vger.kernel.org # v6.4+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 777e8ebfe6b3fa733694977f0f4cf849e07e925c Author: Moksh Panicker Date: Mon Jul 13 03:00:46 2026 +0000 iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable commit bcd3f72e26314edfce7eaf8d7160b3119c7b7fed upstream. atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference. Fixes: 0e4f336f50de ("iio: chemical: atlas-sensor: Balance runtime pm + pm_runtime_resume_and_get()") Cc: stable@vger.kernel.org Signed-off-by: Moksh Panicker Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8b3e221590181a8beb3735bbabf166df02c839b5 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:44 2026 -0700 iio: buffer: Tie IIO dma fence lock lifetime to the fence commit f25ec4627d935dedfb5fe83bd2c2678cdcc19611 upstream. The `iio_dma_fence` implementation currently uses a lock embedded in the `iio_dmabuf_priv`. But the `iio_dma_fence` can outlive the `iio_dmabuf_priv`, which can cause a use-after-free. Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct. We can't just hold a reference to the `iio_dmabuf_priv` from the `iio_dma_fence` since `iio_buffer_dmabuf_release()` might sleep and the fence release callback is not allowed to sleep. Note that the `dma_fence` framework now has an internal lock that gets used when the passing `NULL` for `lock` in `dma_fence_init()`, but in order to allow this patch to be backportable use an external lock. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 11cef99491117d4264603df159c4ff5f3845a059 Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:45 2026 -0700 iio: buffer: Make IIO DMA fence release RCU-safe commit 8662e56c31cf23b61ca3d11b516efb94c35b8026 upstream. The `dma_fence` documentation states that if a custom release implementation is provided, the `dma_fence` object must be freed in an RCU-safe way. The current `iio_dma_fence` implementation uses `kfree()`, which might result in a use-after-free. Remove the custom `release` implementation. This makes the DMA fence core fall back to `dma_fence_free()`, which calls `kfree_rcu()` on the fence. This requires that the fence be the first member of `struct iio_dma_fence`. Using the default release method for extended DMA fence structures is a common pattern. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6d4bdbf7bad63e759bf20259c527f69a1209e3dd Author: Lars-Peter Clausen Date: Wed Jul 15 08:42:43 2026 -0700 iio: buffer: Fix potential use-after-free in anonymous buffer release commit 6288b593e76eb10329326f2cd51e32557203b9e5 upstream. An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2]. Reported-by: codex:gpt-5.6 Fixes: 3e26d9f08fbe ("iio: core: Add new DMABUF interface infrastructure") Signed-off-by: Lars-Peter Clausen Link: https://lore.kernel.org/linux-iio/20240605110845.86740-4-paul@crapouillou.net #[1] Link: https://lore.kernel.org/linux-iio/20240618100302.72886-4-paul@crapouillou.net #[2] Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit af113b29f884faf36268bfb52b6f6fdc96e63e58 Author: Cong Nguyen Date: Sun Aug 2 14:12:46 2026 +0700 iio: adc: pac1921: fix wrong channel used in trigger handler read commit 3364c56b20c1c496bdb8c8df32f96a9947dbf98e upstream. pac1921_trigger_handler() walks the enabled channels with iio_for_each_active_channel(), which yields the scan index (bit) of each active channel, while ch is a separate counter used to pack the samples contiguously into the scan buffer. The register to read was looked up with the packing counter instead of the scan index: ret = pac1921_read_res(priv, idev->channels[ch].address, &val); pac1921_channels[] is ordered by scan index, so channels[bit] is the channel that is actually enabled, whereas channels[ch] is merely the ch-th array entry. These coincide only when the enabled channels form a contiguous prefix (e.g. all channels enabled). With a sparse scan mask - for example when only the power channel (scan index 3) is enabled - the handler reads the wrong register (VBUS instead of VPOWER) and pushes it to userspace as the enabled channel's data. Index the channel array by the scan index (bit) to read the correct register, keeping ch only for contiguous packing into the scan buffer. Fixes: 371f778b83cd ("iio: adc: add support for pac1921") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Acked-by: Matteo Martelli Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 90a2810faefb52da615e256fe6050db49bb2ca0d Author: Joshua Crofts Date: Wed Jul 8 07:34:13 2026 +0200 iio: adc: max34408: add missing 'select REGMAP_I2C' to Kconfig commit 947f1079074a260ba200419d5cba6b8549d5ac0c upstream. The Kconfig entry for the MAX34408 is missing a 'select REGMAP_I2C', causing build failures. Fixes: cf27775838c5 ("iio: adc: Add driver support for MAX34408/9") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 776bb4fb57bab77e76a5baaf7cd854485c082f01 Author: Joshua Crofts Date: Wed Jul 8 07:34:14 2026 +0200 iio: adc: max14001: add missing 'select REGMAP' to Kconfig commit b7c969d0d445c415b8e9f32627d7e8f092c7e916 upstream. The Kconfig entry for the MAX14001 is missing a 'select REGMAP', causing build failures. Fixes: 59795109fa67 ("iio: adc: max14001: New driver") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fc8a0d0eb346df03c238b19e69364aa79a1447d2 Author: Antoniu Miclaus Date: Mon Jul 13 11:40:42 2026 +0300 iio: adc: adi-axi-adc: add data size support for AD408X backend commit 60f6f7fd5f89c7f55991c5dc59f3ccc74cd6efd7 upstream. The AD408X AXI core can pack the sample data on the bus using different word widths. Expose this through the data_size_set backend operation so that frontends can program the packet format field (bits 3:2 of the CNTRL_3 register) according to the ADC resolution: 20-bit, 16-bit and 14-bit map to packet format values 0, 1 and 2 respectively. Signed-off-by: Antoniu Miclaus Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9c408b3309ee8421d51185d8880be62a544d1912 Author: Antoniu Miclaus Date: Mon Jul 13 11:40:43 2026 +0300 iio: adc: ad4080: configure backend data size commit d39afd249d1ef5cb03b6f1dc22a68e6385de413d upstream. The AXI backend needs to know the ADC word width in order to pack the sample data correctly on the bus. During channel setup, program the backend packet format via iio_backend_data_size_set() using the channel resolution, so the data is transferred according to the device's realbits. The backend packet format field defaults to 20-bit packing, so the 20-bit parts (AD4080/AD4081/AD4082, AD4880) were unaffected. The 16-bit (AD4083/AD4084/AD4085, AD4884) and 14-bit (AD4086/AD4087/AD4088) parts, however, were left packing data at the wrong width, producing corrupt buffered captures. Fixes: 6c3e7265734b ("iio: adc: ad4080: add support for AD4084") Signed-off-by: Antoniu Miclaus Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 87c0fb907c4155d66a2f6ff94c1bd7172acdac57 Author: Peter Ujfalusi Date: Wed Aug 5 12:13:27 2026 +0300 ASoC: tas2783-sdw: sort the register default table commit b45fc97ebcfb27ec250025329a4f79ce5e327ec3 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). tas2783_reg_default[] is grouped by SDCA entity name instead, so the binary search does not find 120 of its 196 entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805091327.23944-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit adf51dd6e11b9d350eb43c8ebda7c23643412982 Author: Peter Ujfalusi Date: Wed Aug 5 12:13:26 2026 +0300 ASoC: tas2783-sdw: drop duplicate reg_default entry commit ceba07ca24fab54e0e38ec96d196fca3e638d671 upstream. TAS2783_AMP_LEVEL is defined as TASDEV_REG_SDW(0x0, 0x00, 0x03), so tas2783_reg_default[] lists that register twice. Drop the open coded second entry. Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805091327.23944-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 622319a4ac9f6cfe19540147227468cefac91a1a Author: Peter Ujfalusi Date: Wed Aug 5 13:41:48 2026 +0300 ASoC: tas2780: sort the register default table commit e725093e9e53db9298e38e7332a44dcaac2fd135 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). TAS2780_DVC (0x1a) is listed before TAS2780_CHNL_0 (0x03), which makes it unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: eae9f9ce181b ("ASoC: add tas2780 driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805104149.9795-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 86870ada907fdcdb7f0b9bcc7dde3f0f116698bb Author: Peter Ujfalusi Date: Wed Aug 5 13:41:47 2026 +0300 ASoC: tas2764: sort the register default table commit e7643c3f7eb3292f8a98c2ddbf46ba78d848b83d upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). TAS2764_DVC (0x1a) is listed before TAS2764_CHNL_0 (0x03), which makes it unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805104149.9795-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fee19164109121e7dfd711c425a391e7ab91d7e5 Author: Peter Ujfalusi Date: Wed Aug 5 13:41:46 2026 +0300 ASoC: tas2552: sort the register default table commit 1cc0cb62d306bb7c42e3d4649863df7c279ac850 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). TAS2552_OUTPUT_DATA (0x07), TAS2552_PDM_CFG (0x11), TAS2552_PGA_GAIN (0x12) and TAS2552_BOOST_APT_CTRL (0x14) are listed before TAS2552_RESERVED_0D (0x0d), TAS2552_LIMIT_RATE_HYS (0x0e) and TAS2552_CFG_2 (0x02), which leaves 7 of the 21 entries unreachable. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5df7f71d5cdf ("ASoC: tas2552: Support TI TAS2552 Amplifier") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805104149.9795-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a2ec67511c156d1563e8753f6cb746c25e50bea3 Author: Peter Ujfalusi Date: Wed Aug 5 15:28:11 2026 +0300 ASoC: sti-sas: sort the register default table commit bbd73fb224caa1badfe2aa338fe9c9dcf40a6e96 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). STIH407_AUDIO_DAC_CTRL (0xa8) is listed before STIH407_AUDIO_GLUE_CTRL (0xa4), which makes the latter unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 165a57a3df02 ("ASoC: sti-sas: clean legacy in sti-sas") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122811.13713-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit abf06bc6ac17cb220c6fc25d96e6dededcda6d6b Author: Peter Ujfalusi Date: Wed Aug 5 15:27:27 2026 +0300 ASoC: sgtl5000: sort the register default table commit 437fbdeb60693b8f2e8250d44d29e513a95df298 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). SGTL5000_CHIP_SHORT_CTRL (0x003c) is listed before SGTL5000_CHIP_ANA_TEST2 (0x003a), which makes the former unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 29aa37cddfb9 ("ASoC: sgtl5000: Fix the cache handling") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122728.12362-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 856f0648beb7f60f7ee3dadd79872abb1995d10c Author: WenTao Liang Date: Sat Jun 27 11:52:51 2026 +0800 ASoC: samsung: aries_audio_probe: double of_node_put due to direct assignment without of_node_get commit fb5d1b1c5f8a920ee697545fa6dee16825085717 upstream. In aries_audio_probe(), aries_dai[0].platforms->of_node is assigned the same pointer as aries_dai[0].cpus->of_node (from of_parse_phandle) without calling of_node_get(). When the sound card is deregistered, the ASoC framework calls of_node_put() on both cpus->of_node and platforms->of_node, causing a double put on the same node and a refcount underflow. Add of_node_get(aries_dai[0].cpus->of_node) before the assignment. Cc: stable@vger.kernel.org Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260627035251.60172-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 55b5e9fc08223a9886d16461bd5c0b4003a04ffd Author: Peter Ujfalusi Date: Wed Aug 5 12:02:36 2026 +0300 ASoC: rt721-sdca-sdw: sort the register default table commit 70e0481c196e4822e683bca384e6bda89d944839 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt721_sdca_reg_defaults[] is grouped by SDCA function instead, so the binary search does not find 12 of its entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 86ce355c1f9a ("ASoC: rt721-sdca: Add RT721 SDCA driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-14-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b4eb588408717e42ea188f6267d5f86e9193343f Author: Peter Ujfalusi Date: Wed Aug 5 12:02:33 2026 +0300 ASoC: rt715: sort the register default table commit d729804a92dc4e74b8fb69da162f74660ea64385 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). At the end of rt715_reg_defaults[] the 0x82xx and 0x83xx entries are interleaved with the 0x72xx and 0x73xx entries they belong to, and 0x385e is listed before 0x3859. This leaves 25 of the 323 entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: d1ede0641b05 ("ASoC: rt715: add RT715 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-11-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a099f59e8c1d2fa2e613e6ee1fa31e68a9312b63 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:35 2026 +0300 ASoC: rt715-sdca: sort the register default tables commit 61a0321e4bc2ff9ecb38cda7d5a32ffacef71a75 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). Both tables group the entries by SDCA entity instead: in rt715_reg_defaults_sdca[] the CX_CLK_SEL control is listed before the ADC8_9, ADC10_11 and ADC7_27 mute controls (7 of 78 entries unreachable), and in rt715_mbq_reg_defaults_sdca[] the AMIC_GAIN_EN CH_08 entry is listed before the DMIC_GAIN_EN entries (1 of 32 entries unreachable). regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort both tables by register address. Fixes: 20d17057f0a8 ("ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-13-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f735844b71afbdd7e9653725c5521443bfe66b4e Author: Peter Ujfalusi Date: Wed Aug 5 12:02:34 2026 +0300 ASoC: rt715-sdca: drop duplicate reg_default entries commit c9875bba469c19ad7f771b91b1e4c6f1c0f0a07d upstream. The last two entries of rt715_reg_defaults_sdca[] repeat the ADC7_27 volume mute controls for CH_01 and CH_02, which are already listed a few lines above with the same value. Drop the duplicates. No functional change, regcache_lookup_reg() only ever finds one of the two copies. Fixes: 20d17057f0a8 ("ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 418da4d4ccb803a480f7ba139d5f958563280def Author: Peter Ujfalusi Date: Wed Aug 5 12:02:32 2026 +0300 ASoC: rt712-sdca-sdw: sort the register default table commit efd430c4d0426e60fbec400c5a8ce62d886f6e21 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt712_sdca_reg_defaults[] is grouped by SDCA function instead, so the binary search does not find 4 of its entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. One of them is the Mic Array Clock Source 0x1C Sample Frequency Index control, which a part without that function rejects: soundwire_intel.link.0: Msg ignored for Slave 6, addr: 0x8e00 Sort the table by register address. Fixes: 936abb09c1c7 ("ASoC: rt712-sdca: add the function for version B") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 836df0d31a9a15955fcca1d9deca45a0a24f6701 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:31 2026 +0300 ASoC: rt712-sdca-dmic: sort the register default table commit b9339ee3fccc79e751a2f7bde42c5dd57b38b2a9 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt712_sdca_dmic_reg_defaults[] is grouped by SDCA entity instead, so the binary search does not find 3 of its entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 63a511284c9e ("ASoC: rt712-sdca: Add RT712 SDCA driver for Mic topology") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cf6017e0feee729213af6262c7c5bf87b4b2f66f Author: Peter Ujfalusi Date: Wed Aug 5 12:02:29 2026 +0300 ASoC: rt711: sort the register default table commit 55fe63530772fe95a99abe9497872975f3161a56 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). At the end of rt711_reg_defaults[] the 0x83xx entries are interleaved with the 0x73xx entries they belong to, which leaves 5 of the 269 entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 320b8b0d13b8 ("ASoC: rt711: add rt711 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b7f7451a29c373e638a05d809c8e43ffba0e06f2 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:30 2026 +0300 ASoC: rt711-sdca: sort the register default tables commit b8fdd467bb5d2eb89b665331065e9e3ade964a3e upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). Both tables group the entries by SDCA entity instead: in rt711_sdca_reg_defaults[] the CS01 sample frequency index is listed before the FU05 controls (1 of 54 entries unreachable), and in rt711_sdca_mbq_defaults[] the MIC_ARRAY FU1E volumes are listed before the JACK_CODEC FU0F volumes (2 of 25 entries unreachable). regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort both tables by register address. Fixes: 7ad4d237e7c4 ("ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e15783332f4517f4203ccc1333960e567a13804b Author: Peter Ujfalusi Date: Wed Aug 5 12:02:28 2026 +0300 ASoC: rt700: sort the register default table commit 18f21e34493b812d9c8ab9f083871470b016bed4 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). At the end of rt700_reg_defaults[] the 0x83xx entries are interleaved with the 0x73xx entries they belong to, which leaves 6 of the entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 7d2a5f9ae41e ("ASoC: rt700: add rt700 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a35b77dc8e26534d10a8fd0b903606576fe9816c Author: Peter Ujfalusi Date: Wed Aug 5 12:02:27 2026 +0300 ASoC: rt700: drop duplicate reg_default entry commit 90ad6a29809dc53e8c1af23fc51bafe2133da035 upstream. rt700_reg_defaults[] lists register 0x7303 twice with the same value. The identical rt711 table has the entry only once, so this is a copy-paste error. Drop the duplicate. No functional change, regcache_lookup_reg() only ever finds one of the two entries. Fixes: 7d2a5f9ae41e ("ASoC: rt700: add rt700 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3954b3b21742001c6f9625e13fd5f0073e49470c Author: Peter Ujfalusi Date: Wed Aug 5 12:02:26 2026 +0300 ASoC: rt298: sort the register default table commit aa4c472b0f4a469c2e4599406fa4cff9de3e02bd upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). Four entries were appended to the end of rt298_reg[] instead of being inserted at their sorted position and the 0x01470100 entry is listed after 0x01470c00, which leaves 7 of the 39 entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 6adcafae6ed2 ("ASoC: add rt298 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b50de175dd03a67df811e80715c294afcb15b95d Author: Peter Ujfalusi Date: Wed Aug 5 12:02:25 2026 +0300 ASoC: rt286: sort the register default table commit c30771968b5355617843a0ddfa0b9dcbcfd3ea84 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). Four entries were appended to the end of rt286_reg[] instead of being inserted at their sorted position and the 0x01470100 entry is listed after 0x01470c00, which leaves 7 of the 39 entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 07cf7cbadb4d ("ASoC: add RT286 CODEC driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b454c7ed1cf9e6874f8bf21b1d17756386471a94 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:24 2026 +0300 ASoC: rt274: sort the register default table commit 6a147d177819b0d831831d19fbb9c23f08a03734 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). Four entries were appended to the end of rt274_reg[] instead of being inserted at their sorted position, which leaves 7 of the 33 entries unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: c7e79b2b2d2d ("ASoC: rt274: add rt274 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 74fe7483e6eb2995946422f8cbc0aa43de7ed75c Author: Peter Ujfalusi Date: Wed Aug 5 12:02:39 2026 +0300 ASoC: rt1318: sort the register default table commit 2a8e4b7114f6493314348bda7e3d2141d218ef61 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). The 0xdd93 and 0xdd94 entries are listed after 0xddc8 in rt1318_reg[], which leaves them unreachable for the binary search. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fe1ff61487ac ("ASoC: rt1318: Add RT1318 audio amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-17-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 876d3276fd9c4a0b6c00823bce7ab489d1eb0cd1 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:40 2026 +0300 ASoC: rt1318-sdw: sort the register default table commit 3673b33633a5daf2f52aff03b57f7b25352fe234 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt1318_reg_defaults[] is not in address order, so the binary search does not find 3 of its entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 6ad73a2b42ea ("ASoC: rt1318: Add RT1318 SDCA vendor-specific driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-18-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ec7064d07e24c7c2f37a7fa09c3871fefb4b5274 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:38 2026 +0300 ASoC: rt1316-sdw: sort the register default table commit 7b48eccfbb9bf15e9b7377a5296bfd01815c62d8 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt1316_reg_defaults[] is not in address order, so the binary search does not find one of its entries. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 2b719fd20f32 ("ASoC: rt1316: Add RT1316 SDCA vendor-specific driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-16-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5a45169cbf916cc42dad2544a1e1598b7b7db95 Author: Peter Ujfalusi Date: Wed Aug 5 12:02:37 2026 +0300 ASoC: rt1017-sdca-sdw: sort the register default table commit 5b48ce0356b134155722a61f7196516a7c2e66c5 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). rt1017_sdca_reg_defaults[] places the SDCA controls before the lower vendor registers instead, so the binary search does not find 4 of its entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 2b7aecd58528 ("ASoC: rt1017: Add RT1017 SDCA amplifier driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805090240.16991-15-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2f972da629f6a92344ccf1e09e394c4854939141 Author: Peter Ujfalusi Date: Wed Aug 5 14:39:11 2026 +0300 ASoC: pm4125-sdw: sort the register default table commit 8dd18d9956bfd74531bfd7088e59586e3e115789 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). PM4125_SWR_HPHPA_HD2 (0x3090) is listed before PM4125_ANA_HPHPA_SPARE_CTL (0x308e), which makes the latter unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 8ad529484937 ("ASoC: codecs: add new pm4125 audio codec driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805113911.21723-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fc569468e874de08aa4310c2408746f5ab436226 Author: Peter Ujfalusi Date: Wed Aug 5 13:41:45 2026 +0300 ASoC: pcm512x: sort the register default table commit 767d9ae714e3e9b0ae86237c410fbfca7056570a upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). PCM512x_AUTO_MUTE (page 0, register 59) is listed before PCM512x_ERROR_DETECT (page 0, register 37) and PCM512x_VCOM_CTRL_2 (page 1, register 9) is listed before the page 0 clocking block, so the bsearch() descends into the wrong half of the table. 24 of the 45 entries are unreachable, among them every PLL coefficient and clock divider default. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5a3af1293194 ("ASoC: pcm512x: Add PCM512x driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805104149.9795-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0381caa253cb9f576807c2dbfe2909287c437000 Author: Peter Ujfalusi Date: Wed Aug 5 15:28:08 2026 +0300 ASoC: ml26124: sort the register default table commit d4d0e6e2355a6fe6517e5a0c3d9a0b8ab073b0b6 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). The Mic Select Control register (0xe8) is listed in the analog path control group, between 0x5a and 0x60, which makes it unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Move the entry to the end of the table, where it belongs by address. Fixes: d808fe9f3e7f ("ASoC: Add LAPIS Semiconductor ML26124 driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122811.13713-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 207f95aed374f2fabdbff351fbf210f4811057d2 Author: Peter Ujfalusi Date: Wed Aug 5 15:28:10 2026 +0300 ASoC: max9860: sort the register default table commit 5c4cf173b7eba9bd1e8824b75380412cae2e026b upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). MAX9860_PWRMAN (0x10) is listed as the first entry, before MAX9860_INTEN (0x02), which makes MAX9860_INTEN unreachable. regcache_reg_needs_sync() then cannot compare it against its default and reports that a sync is needed, so it is written to the device on every regcache_sync() even when it was never touched. Sort the table by register address. Fixes: 3b2af7f79968 ("ASoC: max9860: new driver") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122811.13713-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bb1602908c67db7197ab001638573262bccc6ca2 Author: Binbin Zhou Date: Fri Jun 26 10:27:03 2026 +0800 ASoC: loongson: Fix error handling in ACPI property parsing commit 0eb0e3c623ac1da8b85d518043fef7660af7805d upstream. In loongson_card_parse_acpi(), the return value of device_property_read_string() for the `codec-dai-name` property was ignored. If the property is missing or invalid, an uninitialized pointer would be used later, potentially leading to undefined behavior. Fix this by checking the return value and propagating the error appropriately. Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/cover.1780538113.git.zhoubinbin@loongson.cn?part=5 Fixes: ddb538a3004b ("ASoC: loongson: Factor out loongson_card_acpi_find_device() function") Signed-off-by: Binbin Zhou Link: https://patch.msgid.link/08e44a54708eae053be148524346bb8dfcd55b03.1782439646.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4731e2d22e4be8c9f7ed7068627e920cd5602833 Author: Haoxiang Li Date: Mon Jun 22 17:16:20 2026 +0800 AsoC: intel: sst: fix PCI device reference leak on probe failure commit 016f29997ebd29d6ab59c8162ce0e7f73bd1e517 upstream. intel_sst_probe() takes a reference to the PCI device with pci_dev_get(). If sst_platform_get_resources() fails afterwards, the probe error path cleans up the driver context but does not drop the PCI device reference. Add a pci_dev_put() error path for failures after pci_dev_get(). Fixes: f533a035e4da ("ASoC: Intel: mrfld - create separate module for pci part") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622091620.897478-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cb6b0b1a9d5a61ef841739d42c6211094e9c8e2c Author: Haoxiang Li Date: Mon Jun 22 22:56:45 2026 +0800 ASoC: hdac_hda: Fix hlink refcount leak on component registration failure commit 6ad4892c4f5cb437a928a02f5b7d37d496aa9268 upstream. hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure. Fixes: 6bae5ea94989 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622145645.1184986-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a201b5bcdfd61589e70e916132d6811368547cdd Author: Peter Ujfalusi Date: Wed Aug 5 15:27:28 2026 +0300 ASoC: fsl_easrc: sort the register default table commit 84c5d79aebe6c45e12e3112d14e68972f33c210a upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). The four REG_EASRC_RRL() entries are listed as a block before the four REG_EASRC_RRH() ones, but the two registers of a context alternate in the address map (RRL(n) at 0x110 + 8 * n, RRH(n) at 0x114 + 8 * n). This leaves REG_EASRC_RRL(1), REG_EASRC_RRL(2) and REG_EASRC_RRL(3) unreachable. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122728.12362-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3e50bcfe6212f06bf688fb9f4f252c76f54fe3c1 Author: wangdicheng Date: Fri Jul 17 17:15:42 2026 +0800 ASoC: fsl_easrc: Use div64_u64 for 64-by-64 division commit a46ccc71877e962783e0fffa105e41615904c511 upstream. Fix a coccinelle warning about do_div() truncating a 64-bit divisor: sound/soc/fsl/fsl_easrc.c:2061:2-8: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead. In fsl_easrc_m2m_calc_out_len(), val1 is computed as: val1 = (u64)in_rate << frac_bits; // frac_bits up to 39 do_div(val1, out_rate); val1 += (s64)ctx_priv->ratio_mod << (frac_bits - 31); val1 = val1 >> 12; In the worst case (in_rate=384000, out_rate=8000, frac_bits=39): val1 = 384000 << 39 / 8000 = 26,388,279,068,672 val1 >> 12 = 6,440,497,829 (33 bits, exceeds 32-bit range) val1 is then used as the divisor in do_div(val2, val1), where do_div() silently truncates it to 32 bits, producing incorrect results. Use div64_u64() to perform a proper 64-by-64 division. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260717091542.721877-4-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cbb3444113a8f99c254cf87c61cc73d954b960b1 Author: Haoxiang Li Date: Mon Jun 22 17:48:22 2026 +0800 ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure commit 3a89ddcf0c3d9a068631e8c24d5c9e81d1e6512a upstream. mpc5200_audio_dma_create() creates the DMA resources before registering the component. If snd_soc_register_component() fails, the function returns directly and leaves the DMA resources allocated. Call mpc5200_audio_dma_destroy() before returning from this error path. Fixes: f515b67381de ("ASoC: fsl: mpc5200 combine psc_dma platform data") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622094822.926166-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 99d5973d7a0f9b11370b1b77ff5fe239de6bfea4 Author: Peter Ujfalusi Date: Wed Aug 5 15:28:09 2026 +0300 ASoC: cx2072x: sort the register default table commit b927853f70078262780a4e623631584a25eb7284 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). The table is grouped by function rather than by address: for every node the amplifier gain registers (0x41c0, 0x45c0, ...) are listed before the power state and stream format registers of the same node (0x4014, 0x4414, ...). This leaves 75 of the 132 entries unreachable. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: a497a4363706 ("ASoC: Add support for Conexant CX2072X CODEC") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260805122811.13713-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 07a86575edc308e66b6c8873ed4a93ef3a063e55 Author: Runyu Xiao Date: Fri Jun 12 00:15:53 2026 +0800 ASoC: cs35l34: drain threaded IRQ before runtime suspend commit 4105a4c0678b2808fc8046b60321b4f1cc7dae75 upstream. cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-3-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 84cf6acd01a1ec8f30276578a039216327af782e Author: Runyu Xiao Date: Fri Jun 12 00:15:52 2026 +0800 ASoC: cs35l33: drain threaded IRQ before runtime suspend commit e074c12c428c633e079154301207a6079a208583 upstream. cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it. Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260611161553.3378721-2-runyu.xiao@seu.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 86f47316e536cff9f5fe88a05e7bace7a36e424c Author: Peter Ujfalusi Date: Wed Aug 5 15:27:13 2026 +0300 ASoC: adau1761: sort the register default table commit cc606b6c2328b4864885db6afcad7e78c0ac7a73 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). The table lists the ADAU1761 specific registers (0x4008 and up) before the block shared with the ADAU1381/ADAU1781, which starts at ADAU17X1_CLOCK_CONTROL (0x4000), so bsearch() descends into the wrong half and 28 of the 52 entries are unreachable. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: dab464b60b24 ("ASoC: Add ADAU1361/ADAU1761 audio CODEC support") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Acked-by: Nuno Sá Link: https://patch.msgid.link/20260805122713.11376-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1c9a77101f2d13cafb87f1395cfa89ebd2a198a2 Author: Linkai Gong Date: Thu Aug 13 17:56:17 2026 +0800 i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure commit 62edb8ca0aa44517cc23cfa26cd8a51f15ea92fe upstream. of_parse_phandle() takes a reference on the parent node. If a later devm_kstrdup() fails, err_rollback only releases nodes for indices 0..i-1, so the current node is leaked. of_node_put() the current parent before rolling back. Fixes: 7c0195fa9a9e ("i2c: mux: demux-pinctrl: check the return value of devm_kstrdup()") Signed-off-by: Linkai Gong Cc: # v6.6+ Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260813095617.2246320-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit b2956d578e87a26718db2ba4fd89ed07a3ec0823 Author: Stephan Gerhold Date: Mon Jul 6 17:02:15 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks commit e111ddda092ad961870a634e4c9263c10a3e8485 upstream. The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer match nowadays is gcc-msm8909. Looking at the differences between gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the definitions for the BIMC PLL. It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was used for GPLL2. In practice, the BIMC PLL is exclusively controlled by the RPM firmware and Linux should not touch it. So far, it was defined to model the full clock hierarchy, but even in read-only mode with CLK_GET_RATE_NOCACHE this is problematic since the RPM will silently change the clock parents without notifying Linux about it. The clock framework reads the clock parent only once during boot, so the resulting rates will still be often wrong. Follow the example of more recent SoCs and drop the BIMC PLL and all remaining related clocks to avoid reporting stale status data. This means we cannot determine the rate of these clocks anymore. This is not a big problem in practice, since these are NoC-related clocks that are independently managed through the interconnect subsystem. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Signed-off-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-8-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit fb3438a00799c0ae460e35a17af1154c0c29a6c4 Author: Stephan Gerhold Date: Mon Jul 6 17:02:11 2026 +0200 clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk commit ca7e6cc30cde4f0cbeff2e205a84bedf431e9156 upstream. gcc_apss_axi_clk specifies a halt_reg of 0x4601c, but this is already used by gcc_apss_ahb_clk. The correct value according to the downstream driver is 0x46020. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-4-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 76ff1eff735890e8a8342cca99fd0478a1f55357 Author: Stephan Gerhold Date: Mon Jul 6 17:02:10 2026 +0200 clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk commit 944d0fb38cffe57a1d1ebf82c5c077bad82dcdbb upstream. MDM9607 is similar to MSM8909, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-3-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 30223154daacfe13f886024c1db56173b10f85c5 Author: Stephan Gerhold Date: Mon Jul 6 17:02:14 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src commit 17784427df923a0573a7ea83f9198456ff1ec1a5 upstream. This clock does not exist on MDM9607. Reading/writing the registers always results in 0. Presumably, this definition was mistakenly copied from gcc-msm8916. On MSM8916, this root clock is used for multimedia subsystems (camera, display, video). MDM9607 has none of that, so this clock was probably omitted in the hardware. There are no users inside gcc-mdm9607, so we can just drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-7-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 691d472c9509ff9ace4f60da38b6a1fd6d09625b Author: Stephan Gerhold Date: Mon Jul 6 17:02:13 2026 +0200 clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src commit 38d06956f60675f906dc3f5b70b3b52103b86a7d upstream. This clock does not exist on the specified address on MDM9607. Reading/writing the registers always results in 0 or crashes. The math in the frequency table is also broken. GPLL2 on MDM9607 runs at 480 MHz, so: - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz Presumably, this definition was mistakenly copied as-is from gcc-msm8916 (which uses 930 MHz for GPLL2). There are no branch consumers of this root clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as parent instead of this clock), so we can just drop it. It seems like this clock does exist on this SoC on a different address, but since there is no user and reference code for it, it is still better to drop it. Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-6-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 4865ff30e91891aad71a1c725f8e75af87cd1a30 Author: Heiko Stuebner Date: Wed Mar 4 13:14:25 2026 +0100 clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src commit 13b10571cc353448275365ede1a5396d20dfe839 upstream. dclk_vop2_src currently has the CLK_SET_RATE_PARENT flag set, which is very different from dclk_vop0_src or dclk_vop1_src, which don't have it. With this flag in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop this flag from dclk_vop2_src. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable@vger.kernel.org Tested-by: Quentin Schulz # RK3588 Tiger w/ DP Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Tested-by: Chris Morgan Link: https://patch.msgid.link/20260304121426.1184680-2-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit c6679c13e3c360b8aa20d4eefa9dab78c42f0125 Author: Stephan Gerhold Date: Mon Jul 6 17:02:09 2026 +0200 clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk commit fc611445b021262b0d4ace6f716a360663816287 upstream. MSM8939 is similar to MSM8916, where the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-2-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 508d6150d9405654cf5948993e00ad5e8660a8a8 Author: Stephan Gerhold Date: Mon Jul 6 17:02:08 2026 +0200 clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk commit c5339edc6abb601ea10df910ea0b1592fa1016f3 upstream. According to the APQ8016E TRM, the GCC_BLSP1_SLEEP_CBCR register is read-only and only has the CLK_OFF bit to check if the clock is running. This is a shared vote clock, the correct way to enable it is to vote for BLSP1_SLEEP_CLK_ENA (BIT(9)) in GCC_APCS_CLOCK_BRANCH_ENA_VOTE (0x45004). Cc: stable@vger.kernel.org Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-1-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 8eb29dc9a9ad8fc94954b24ceb9ec774df6e725d Author: Pedro Kopper Date: Fri Aug 14 10:22:13 2026 +0100 clk: microchip: mpfs: fix regmap_update_bits() mask/val order commit fbfa013eeac299ecc015cb14fa40e382a23fb489 upstream. mpfs_cfg_clk_set_rate() passes the mask and value arguments to regmap_update_bits() in the wrong order. The resulting write becomes reg = orig_reg | val, causing bits to not be cleared if the clock divider changes. Pass the arguments in the correct order so the divider field is updated as intended. Fixes: c6f2dddfa7f9 ("clk: microchip: mpfs: use regmap for clocks") Signed-off-by: Pedro Kopper Reviewed-by: Conor Dooley Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit bf85bd6e550c17ffa585606fcc18eb5b7c95bbce Author: Martin Blumenstingl Date: Tue Jun 23 22:19:56 2026 +0200 clk: meson: align gxbb_32k_clk_sel number of parents with actual count commit 628b6fee9fca292f12d07f0f1bcf1edefa949d81 upstream. The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future). Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent") Reported-by: Christian Hewitt Cc: stable@vger.kernel.org Tested-by: Christian Hewitt Signed-off-by: Martin Blumenstingl Link: https://patch.msgid.link/20260623201956.1324992-1-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Greg Kroah-Hartman commit bf538cdc9bb45344a64ed14616cd39e547178ba8 Author: Akari Tsuyukusa Date: Fri May 22 22:30:23 2026 +0900 clk: mediatek: mt8196: Select REGMAP_MMIO for vlpckgen commit f63aecdb45e9dd19c340fd62df698374d95b9024 upstream. The MediaTek MT8196 vlpckgen clock driver uses __devm_regmap_init_mmio_clk() by devm_regmap_init_mmio(), which is defined in drivers/base/regmap/regmap-mmio.c. However, the driver's Kconfig entry does not select REGMAP_MMIO. This causes a linker error when REGMAP_MMIO is not enabled. Fix this by selecting REGMAP_MMIO in the Kconfig entry. Fixes: 2f8b3ae6f0cb ("clk: mediatek: Add MT8196 vlpckgen clock support") Cc: stable@vger.kernel.org Signed-off-by: Akari Tsuyukusa Reviewed-by: Brian Masney Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit 9a511980e81b19ec9455952c057ef920b2ed56db Author: Pavel Löbl Date: Fri Jun 5 15:03:40 2026 +0200 clk: clocking-wizard: fix integer overflow in rate calculation commit 4adf593c6fc5aed4639add011f71a074a1bd3966 upstream. When using driver on Zynq-7000 (32-bit) determine_rate calculation overflows. For instance requesting 32MHz with 100MHz parent clock results in 100000000*(4*1000+0) 32-bit multiplication. Replace the expression with mult_frac which is already used in clk_wzrd_recalc_ratef. Cc: stable@vger.kernel.org Fixes: 7681f64e6404 ("clk: clocking-wizard: calculate dividers fractional parts") Signed-off-by: Pale Löbl Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Greg Kroah-Hartman commit edf86952488fa653a1ab10a3f66f837da7ce94b5 Author: Sven Eckelmann Date: Sun Jul 5 22:21:50 2026 +0200 batman-adv: bla: prevent CRC corruptions after claim flush commit 89f3502ff6878798be96461b2eebd64ba3c3874c upstream. When batadv_bla_del_backbone_claims() tried to remove all claims of a backbone, it sets the CRC to 0. It assumes that the it had the last reference of the claims because batadv_claim_release() (which runs after the last reference was released), is XORing the crc16 of the claim address with the backbone CRC. If there would be a parallel holder of any of these references, it could happen that the backbone CRC is (0 ^ crc16(delayed_released_claim)). Which is the wrong starting point for the new claims it may receive when the remote answers the claim request from batadv_bla_send_request(). This reinitializations can be completely dropped to avoid this problem. batadv_claim_release() will take care of fixing the backbone CRC. Cc: stable@vger.kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 9a0c47023d3254048a1588534755d4476bcc3abc Author: Sven Eckelmann Date: Wed Jul 22 12:08:09 2026 +0200 batman-adv: bla: fix freeing of claims on meshif deletion commit 8d128c932bced74e3b1625ba3d7c78ef122a88a7 upstream. When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 0c2df865338bbf92aa45b9253e5f9b8ef2d9992f Author: Sven Eckelmann Date: Mon Jul 6 19:46:37 2026 +0200 batman-adv: dat: avoid unaligned fault in IP extraction commit 0121afa52cdb88cfb4d5d7bd126a23a9100121d8 upstream. Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 5c3a0e553593 ("batman-adv: Distributed ARP Table - add ARP parsing functions") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 2879177539e3ece483a8e5406970373698e9a6c5 Author: Sven Eckelmann Date: Thu Jul 9 21:26:13 2026 +0200 batman-adv: mcast: linearize skbuff for packet generation commit 6a30a59e2660afd03c975f1b8eae6a2301161197 upstream. batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape() Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit e4af59a2dc95699d70652766841d162ce778b02a Author: Sven Eckelmann Date: Thu Jul 9 21:17:08 2026 +0200 batman-adv: mcast: ensure unshared skb for multicast packets commit 82bf207f48ebb7a38157f1d91dac884fc9b8cfd8 upstream. When a packet is transmitted via a batman-adv interface and has already enough room for the header then nothing will make sure that the skbuff is unshared. But it is not allowed to modify a currently shared skbuff. Always make sure that the pskb_expand_head() is not only called for a too small header but also for shared skbuffs. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b9c2d3a5043fc40f31deaf233dde2d5f58abc19d Author: Sven Eckelmann Date: Thu Jul 9 20:44:24 2026 +0200 batman-adv: fix TX priority extraction for BATADV_FORW_MCAST commit 7aedb59b80993c912ab45ce24386a2775150962b upstream. batadv_mcast_forw_mode_by_count() pushs the skb->data for BATADV_FORW_MCAST forwarding via batadv_mcast_forw_mcsend(). But the batadv_skb_set_priority() expects the ethernet header directly before (skb->data + offset). With the moved skb->data, just some random data would be accessed to get the priority data. Move the batadv_skb_set_priority() before the decision about the handling multicast packets and potential header modifications. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 2dffc8c44b6e3347b3719c6419c07b4a18fea895 Author: Zhiling Zou Date: Fri Jul 31 11:18:49 2026 +0800 batman-adv: fix stale receive device on merged fragments commit ad46c907d7d9975a285c1e89a4adde652eaa93f5 upstream. Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 23e747fe585830c43095c37c85b2757231c6917f Author: Pengpeng Hou Date: Mon Jul 20 19:57:25 2026 +0800 mtd: rawnand: validate ONFI extended parameter page sections commit e5e415262330bd70f983e091d8919d9dcd99e475 upstream. nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section. Fixes: 6dcbe0cdd83f ("mtd: get the ECC info from the Extended Parameter Page") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 97f1f4cdec16fa33cd4f644a27d23c519efbdb90 Author: James Hilliard Date: Fri Aug 7 09:39:01 2026 -0600 mtd: rawnand: sunxi: fix H6/H616 controller timings commit 15a3cbce32994141252bb4ecfe3ff3a5d22d0b4f upstream. The NAND timing calculation assumes that command and address setup and hold intervals T1-T4, T7 and T11 each take one controller clock. It also uses the original A10 delay encodings for tWB, tADL, tWHR and tRHW. The H6/H616 NDFC defines the setup and hold intervals as two internal clock cycles and uses different delay encodings. Add the H616 timing characteristics and select them through the controller capability data so the clock solver and timing fields match the hardware. Fixes: 88fd4e4deae8 ("mtd: rawnand: sunxi: Add support for H616 nand controller") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 6086af3e39b0a9197a1068762dc684b79f556079 Author: James Hilliard Date: Fri Aug 7 09:39:00 2026 -0600 mtd: rawnand: sunxi: describe tADL and tWHR delays commit 147f2a5743f8864bfc265654b1856af11c8c0031 upstream. The tADL and tWHR timing fields use four encoded delays, but the driver currently derives their values with a shift. This hides the actual controller timing characteristics and lets the clock solver select a 32-cycle delay that the fields cannot encode. Describe the legacy 7, 15, 23 and 31 cycle thresholds explicitly and use the tables for both clock selection and field lookup. This prepares the driver for controllers with different encodings. Fixes: 88fd4e4deae8 ("mtd: rawnand: sunxi: Add support for H616 nand controller") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit c3d542c6204c8606d3a7d74c320f313e919e40b9 Author: James Hilliard Date: Fri Aug 7 09:38:59 2026 -0600 mtd: rawnand: sunxi: group controller delay tables commit 9f2e033754c6c023150f184b4e72bbcc5d6eea13 upstream. The tWB and tRHW timing field encodings are controller properties, but they currently live in standalone lookup tables. Group them in a timing descriptor selected through the controller capability data. Point every existing controller at the legacy values so this is a pure preparation change. Fixes: 88fd4e4deae8 ("mtd: rawnand: sunxi: Add support for H616 nand controller") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit a732ae52c6aef395727e1354c62e45cc2f983cae Author: Miquel Raynal (DAVE) Date: Fri May 29 18:29:57 2026 +0200 mtd: rawnand: pl353: Make sure we use the monolithic helpers for raw accesses commit 80ecacd054ffeb60cd28e46ed5cd6bd0d2de318b upstream. Any access not using the hardware ECC engine should be monolithic because the controller has its very own way of handling the end of a transaction during operation configuration, so we cannot easily make repeated reads. This has the side effect of fixing support for software ECC engines. Suggested-by: Andrea Scian Cc: stable@vger.kernel.org Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Miquel Raynal (DAVE) Acked-by: Michal Simek Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 00b4d5d206298bd789ff3c2744eb97964c8dbb8a Author: Pengpeng Hou Date: Wed Jul 8 09:47:12 2026 +0800 mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE() commit 5b2444b4d575d8117809c57801562ef37ca2d4af upstream. The Realtek external ECC engine driver has an OF match table wired into its platform driver, but the table is not exported with MODULE_DEVICE_TABLE(). When the driver is built as a module, the missing OF module alias prevents automatic module loading from the compatible string. Add the missing MODULE_DEVICE_TABLE() entry. Fixes: 3148d0e5b1c5 ("mtd: nand: realtek-ecc: Add Realtek external ECC engine support") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 1e5cd8bc902331ff801df88cbb299029ae062753 Author: Xu Rao Date: Mon Jul 13 13:22:03 2026 +0800 mtd: mtdoops: free page bitmap when the backing MTD is removed commit 956e7da12c114f13c63d126ab1d79c3b6a819060 upstream. mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event. Fixes: be95745f0167 ("mtd: mtdoops: keep track of used/unused pages in an array") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit d14e6298139f58a87a87d7022e26a7f37f0ddce7 Author: Pengpeng Hou Date: Wed Jul 8 09:49:06 2026 +0800 mtd: afs: validate v2 image info bounds commit e9290031f736e99ad17c25c00311c92c266843b7 upstream. The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries. Fixes: b7cf5e2830bb ("mtd: afs: add v2 partition parsing") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Acked-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 0307c2e82847aeceba1cf5fe42536127a033289f Author: Anthony Krowiak Date: Wed Aug 12 16:02:35 2026 -0400 s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object commit 5883528250be57fa92270459b33603ff52de0a91 upstream. In the vfio_ap_mdev_cfg_add function, the apm_add, aqm_add and adm_add fields of an ap_matrix_mdev object fields are modified while not holding the matrix_dev->mdevs_lock. This lock must be held while making these to guard against a race condition with another caller that may be concurrently modifying these fields or any of the fields in the matrix_mdev->matrix. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 09548edc6114f1eb1035b30795e893204ef45b85 Author: Anthony Krowiak Date: Wed Aug 12 16:02:37 2026 -0400 s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap commit bf09b9d7cd7890bc3a3b7eb63d5ece15f88bfde7 upstream. The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero(). Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 7db2511fc601ca3a6e3fb1bdce02261c3c3167c3 Author: Anthony Krowiak Date: Wed Aug 12 16:02:39 2026 -0400 s390/vfio-ap: Fix NULL deref in status_show() during queue probe commit dd6f4ef6f8a37412909ad787c837332fb070159c upstream. When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds. Fixes: 260f3ea141382 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 0fd74477d05743d4cd9b25a3b667daa278d53b93 Author: Anthony Krowiak Date: Wed Aug 12 16:02:34 2026 -0400 s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects commit 7fa61c29850d05e40ca9ed41bfdf57673023f581 upstream. In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree. Fixes: 2c1ee8983aa3 ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 04b35dd88c108b2d2ceaaa396aba1cb4049d5831 Author: Anthony Krowiak Date: Wed Aug 12 16:02:38 2026 -0400 s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed commit 917f509bfb88048094dbb85c4e9dbc4d6fe4a886 upstream. The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 4f7e869d0db24ae07b4c888fd3bc21554eef775d Author: Anthony Krowiak Date: Wed Aug 12 16:02:33 2026 -0400 s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL commit d50346801b4f144e42b49cd4f1496010498ab114 upstream. The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 2ff68bf414de167bc138e6e211ee1ad3ab3c5052 Author: Anthony Krowiak Date: Wed Aug 12 16:02:36 2026 -0400 s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove commit 6b8a02e216f6b520cc029e43ddc83956605135d5 upstream. The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit c8a9772f6dfeec9497a955b5731c5dbbcb11c335 Author: Anthony Krowiak Date: Wed Aug 12 16:02:32 2026 -0400 s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove commit b1f092d94f621307927f145e3cc31893da51fc08 upstream. The do_remove flag in vfio_ap_mdev_cfg_remove() is initialised to zero before the loop that iterates over the list of matrix mdevs, but is never reset at the start of each iteration. Since do_remove is OR-accumulated across iterations, a positive result from one mdev carries over to subsequent mdevs. The fix is to set the do_remove flag with the first call to bitmap_and; for example: do_remove = bitmap_an rather than do_remove |= bitmap_and. Fixes: eeb386aeb5b7 ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 13bfc94eef389bd664ffc67b00184919902c938a Author: Anthony Krowiak Date: Thu Aug 6 13:34:35 2026 -0400 s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() commit 4400270ec0348d05dc0439d8f0130853ce7f9e20 upstream. In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock. Fixes: 86956e70761b3 ("s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification") Cc: stable@vger.kernel.org Co-developed-by: Matthew Rosato Signed-off-by: Matthew Rosato Signed-off-by: Anthony Krowiak Acked-by: Christian Borntraeger Signed-off-by: Claudio Imbrenda Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman commit c99e2c7811bee0496a0a68deb941e73fcaf0fedd Author: Sourabh Jain Date: Mon Jul 27 11:04:16 2026 +0530 powerpc/crash: stop watchdogs before booting kdump kernel commit fb43ba4256543ce18ca0540fc37022bda438a293 upstream. On pseries LPAR systems, watchdog timers configured from userspace can remain active after a kernel panic. When a panic triggers kdump, the crashing kernel jumps directly to the kdump kernel without stopping active watchdogs. As a result, the watchdogs remain active after the kdump kernel starts. If dump capture takes longer than the watchdog timeout, PHYP resets the LPAR before the dump is fully captured, causing dump capture to fail. Fix this by issuing the `H_WATCHDOG` hcall during the crash shutdown sequence to stop all active watchdogs before booting the kdump kernel. Cc: stable@vger.kernel.org Fixes: 69472ffa6575 ("watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers") Reported-by: Mahesh Kumar G Suggested-by: Ritesh Harjani (IBM) Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-4-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 08ec4e8e3c5408d82cc0cceba440be4dcc033445 Author: Sourabh Jain Date: Mon Jul 27 11:04:14 2026 +0530 powerpc/pseries: Move H_WATCHDOG definitions to a common header commit 516a254918453ec99660201263d01189c082332c upstream. The H_WATCHDOG input and output definitions are currently local to the pseries watchdog driver. The next patch in this series also needs these definitions to issue H_WATCHDOG hypercalls outside the watchdog driver. Move the H_WATCHDOG definitions to a new common header, asm/papr-watchdog.h, so they can be shared without duplicating the PAPR watchdog definitions. No functional changes. Cc: stable@vger.kernel.org Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-2-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 8536f38107a69255d82a51174291ec347336b162 Author: Sourabh Jain Date: Mon Jul 27 11:04:15 2026 +0530 powerpc/pseries: Handle and log pseries-wdt registration failures commit e65b526affa621b50646cafdf6b06505af07032e upstream. The pseries watchdog initialization registers the pseries-wdt platform device using platform_device_register_simple(), but currently ignores its return value. Check the returned pointer for errors, log a descriptive error message when registration fails, and propagate the failure code to the caller. This avoids silently ignoring platform device registration failures. Cc: stable@vger.kernel.org Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727053416.276317-3-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 7968852a7ca3ce81477ec5b4494a28d612f35a97 Author: Muchun Song Date: Fri Jun 12 11:58:47 2026 +0800 powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population commit 89a4ae32764172468dea303eb6ae90fe6c859712 upstream. vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state. Link: https://lore.kernel.org/20260612035903.2468601-4-songmuchun@bytedance.com Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap optimization for radix") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Reviewed-by: Ritesh Harjani (IBM) Cc: "Aneesh Kumar K.V" Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport (Microsoft) Cc: Nicholas Piggin Cc: Oscar Salvador (SUSE) Cc: Usama Arif Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c4cb547f26d9b73b489c5278d0c8db837c5a174f Author: Jinjie Ruan Date: Wed Jul 29 09:29:48 2026 +0800 powerpc/kexec_file: Prevent kexec range truncation commit fa40f9dbdd4af53e7445d9135b5b207eb8adf372 upstream. Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated. Cc: stable@vger.kernel.org Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for getting memory ranges") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-4-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit 4ff3d9fd71c7bc2fc81afdac1970d9c55a5c0dea Author: Jinjie Ruan Date: Wed Jul 29 09:29:47 2026 +0800 powerpc/kexec_file: Fix null-ptr-def in extra size calculation commit 761eda315a6e1fda3e8e2185b28430771fb1ac29 upstream. A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64(). On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'. Add a NULL check for 'rmem' to prevent this crash. Cc: stable@vger.kernel.org Fixes: 0d3ff067331e ("powerpc/kexec_file: fix extra size calculation for kexec FDT") Signed-off-by: Jinjie Ruan Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-3-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman commit c513c8d173187c4618b4590411fee393539c4507 Author: Helge Deller Date: Sat Aug 15 11:59:20 2026 +0200 parisc: Fix alignment of asm statements in head.S commit 04cf68c9a76e3c6b67ad056a66a14923abf85925 upstream. All assembler statements need to be 4-byte aligned. Prevent a possible misalignment if someone changes the preceeding string and it's length is then suddenly not a multiple of 4 any longer. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 16a62a3f2128b3d86fefc082d8f631becd02bff5 Author: Pei Xiao Date: Mon Aug 17 11:29:25 2026 +0800 parisc: eisa: Fix infinite loop when parsing invalid IRQ value commit 8b585431a16cfb9d8f2955a9fa0787ce3dceb3c2 upstream. When an invalid value is passed via the "eisa_irq_edge=" kernel command line parameter (e.g. "eisa_irq_edge=16,5"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally. Signed-off-by: Pei Xiao Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 9dfa11cef4750b67591307f2c62e47a23d60e4b7 Author: Bryam Vargas Date: Sat Jun 20 16:41:31 2026 -0500 nvdimm/btt: reject an arena whose nfree is below the lane count commit 6a1f2e5ed9267ca19187038ac635393c165213ac upstream. The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant. Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Alison Schofield Tested-by: Alison Schofield Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton.me Signed-off-by: Alison Schofield Signed-off-by: Greg Kroah-Hartman commit c74eba81766ee40d063248dc6a8a264e5af3ebaf Author: Narek Jilavyan Date: Mon Aug 17 10:34:33 2026 +0000 mm/hugetlb_cgroup: call page_counter_set_max() outside VM_BUG_ON() commit eedc8474d469a2e88f4dc61f8cfe05c147478b43 upstream. hugetlb_cgroup_css_alloc() rounds the counter limit down to a multiple of the huge page size and then applies it inside an assertion: VM_BUG_ON(page_counter_set_max(fault, limit)); VM_BUG_ON(page_counter_set_max(rsvd, limit)); With CONFIG_DEBUG_VM=n, VM_BUG_ON(cond) is BUILD_BUG_ON_INVALID(cond), i.e. ((void)(sizeof((__force long)(cond)))), whose operand is never evaluated. page_counter_set_max() is not a predicate - it performs xchg(&counter->max, nr_pages) - so on every non-debug kernel the limit is never applied and the counters keep page_counter_init()'s PAGE_COUNTER_MAX. That is user-visible, because hugetlb_cgroup_read_u64_max() recomputes the same rounded value and uses equality as its "unlimited" sentinel. PAGE_COUNTER_MAX is LONG_MAX / PAGE_SIZE = 2251799813685247, which is odd, so round_down() really does change it and the two sides disagree. With CONFIG_DEBUG_VM=n: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max 9223372036854771712 and with this patch: $ cat /sys/fs/cgroup/t/hugetlb.2MB.max max A debug option should not change cgroup output. Call the function, then assert the result, as v6.12 did. Use VM_WARN_ON_ONCE() rather than restoring VM_BUG_ON(): the two are identical under CONFIG_DEBUG_VM=n, and checkpatch asks that new code not use BUG() variants. Link: https://lore.kernel.org/20260817103433.191266-1-njilav@gmail.com Fixes: 0e2759afcaf9 ("page_counter: track failcnt only for legacy cgroups") Signed-off-by: Narek Jilavyan Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 05caf140e24adaee68537870a67cfc2b2a7397dd Author: Longlong Xia Date: Fri Aug 14 16:30:27 2026 +0800 mm/hugetlb: keep max_huge_pages when dissolving surplus folios commit 267bede12d3b108ca29997ce280e927a570ec97f upstream. dissolve_free_hugetlb_folio() can remove a free folio as surplus when its node has surplus pages. In that case remove_hugetlb_folio() decrements both nr_huge_pages and surplus_huge_pages, leaving the persistent pool size unchanged. Updating max_huge_pages as if a persistent folio had been removed can therefore corrupt the persistent pool target and underflow it when max_huge_pages is zero. Keep max_huge_pages unchanged for surplus folios, including the vmemmap restoration rollback path. Link: https://lore.kernel.org/20260814083027.1419487-1-xialonglong2025@163.com Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Longlong Xia Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Jinjiang Tu Cc: Longlong Xia Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 10f616ef06c5bd2d656a0eebaf73f9b09d150c24 Author: Sourav Panda Date: Tue Aug 11 05:29:09 2026 +0000 mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio commit 7b8a8ae4dd176a232e973017d2aa3c536a7275e2 upstream. alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes. If order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL nodemask down to hugetlb_cma_alloc_frozen_folio() via alloc_gigantic_frozen_folio(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. From a userspace perspective, this bug allows an unprivileged user to crash the kernel (trigger a panic) by requesting a gigantic hugepage allocation with MPOL_PREFERRED_MANY on a system where CMA is only configured on a subset of NUMA nodes. This can be reproduced by booting a VM with two NUMA nodes, restricting CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G hugepages=0), and running a program that allocates a 1GB hugepage area without reserving, restricts allocation to Node 0 using mbind() with MPOL_PREFERRED_MANY, and triggers a page fault: void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_1GB | MAP_NORESERVE, -1, 0); unsigned long nodemask = 1; /* Node 0 */ mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask, sizeof(nodemask) * 8, 0); memset(ptr, 0, 1UL << 30); /* Trigger fault */ This results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120 Call Trace: only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160 alloc_surplus_hugetlb_folio+0x6d/0x100 alloc_hugetlb_folio+0x3c5/0x660 hugetlb_no_page+0x3d9/0x650 Link: https://lore.kernel.org/20260811052909.475635-1-souravpanda@google.com Fixes: eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages") Signed-off-by: Sourav Panda Reviewed-by: Muchun Song Reviewed-by: Anshuman Khandual Cc: David Hildenbrand Cc: Frank van der Linden Cc: Greg Thelen Cc: Johannes Weiner Cc: Kefeng Wang Cc: Michal Hocko Cc: Oscar Salvador Cc: Rik van Riel Cc: SeongJae Park Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e456129942506ae9af9f38f09bf3faf191e63143 Author: Wupeng Ma Date: Tue Jul 7 19:02:54 2026 +0800 mm/hugetlb: fix missing migratable flag on same-node hugetlb migration commit 8ee1ef0f2f8ce29338f4ab00a3d344c010208058 upstream. Commit ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") moved setting of the migratable flag and active-list placement from folio_putback_active_hugetlb(dst) into move_hugetlb_state(), so that the freshly allocated destination folio is handled where allocation is known to have succeeded. Unfortunately, the new code was appended after the existing temporary-folio block in move_hugetlb_state(), which contains an early return added earlier by commit 5af1ab1d24e08 ("mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()"): if (folio_test_hugetlb_temporary(new_folio)) { ... if (new_nid == old_nid) return; <-- skips the new code ... } /* added by ba23f58 */ folio_set_hugetlb_migratable(new_folio); list_move_tail(&new_folio->lru, ...&h->hugepage_activelist); When the destination folio is temporary (i.e. the hugetlb pool was exhausted and the migration callback fell back to alloc_migrate_hugetlb_folio()) and the migration does not cross a node -- the common case, and always true on a single-NUMA system -- move_hugetlb_state() returns before setting the migratable flag or adding the new folio to the active list. The destination folio is then installed in the page table but cannot be isolated afterwards, since folio_isolate_hugetlb() rejects folios without the migratable flag; a subsequent soft-offline, hard-offline or memory-hotplug offline of that folio fails with -EBUSY. This was reproduced on a single-NUMA arm64 VM: a second MADV_SOFT_OFFLINE on an already-migrated hugetlb page returned EBUSY and logged "hugepage isolation failed". Keep the surplus adjustment, which is the only part that depends on the node crossing, guarded by `if (new_nid != old_nid)', while making the migratable flag and active-list placement unconditional. This preserves the cleanup intent of ba23f58 and closes the early-return hole. Link: https://lore.kernel.org/20260707110254.3147686-1-mawupeng1@huawei.com Fixes: ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio") Signed-off-by: Wupeng Ma Acked-by: David Hildenbrand (Arm) Cc: Baolin Wang Cc: Muchun Song Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 99186b185c245f5987d7f8715d5504c8d8cc04a0 Author: Hui Su Date: Mon Aug 17 20:08:00 2026 +0800 mm/migrate_device: avoid out-of-bounds writes for compound folios commit dc41e961a269f2ca4196e669d6d8e05480899cd4 upstream. migrate_device_range() and migrate_device_pfns() clear the entries following a compound folio so that the PFN arrays retain their page-granular representation. If a compound folio extends beyond the end of the caller-provided range, the loops clear all following folio entries without limiting them to the number of slots remaining in the npages-sized array, causing an out-of-bounds write. Do not proceed with a compound folio if its page-granular representation does not fit entirely in the remaining PFN array. If this happens, drop any reference and lock acquired for the folio, clear the remaining entries, and stop collecting. Observed with a KASAN x86 QEMU kernel using the HMM migrate_anon_huge_zero selftest. Closing /dev/hmm_dmirror0 after migrating an anonymous huge page to device memory exercises: dmirror_fops_release() -> dmirror_device_evict_chunk() -> migrate_device_range() Link: https://lore.kernel.org/20260817120758.669807-3-sh_def@163.com Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Signed-off-by: Hui Su Cc: Alistair Popple Cc: Balbir Singh Cc: Byungchul Park Cc: David Hildenbrand Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 431402bfca1c464c6c0c1c99ac079628d31630f7 Author: Baolin Wang Date: Tue Aug 18 10:47:26 2026 +0800 mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs commit 2fd4e7693674b17807a6d082feb01a3fbf86f5f8 upstream. Lance reported that when nothing else causes the mm to be considered for khugepaged collapse, an MADV_HUGEPAGE-advised tmpfs VMA alone does not trigger scanning. After commit 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order check reads vma->flags directly. However, when MADV_HUGEPAGE is handled, khugepaged_enter_vma() is called before the VMA's flags have been updated, so the check uses stale flags and incorrectly rejects the VMA for collapse. As a result, khugepaged does not collapse the tmpfs file into PMD order in time. Fix this by calling khugepaged_enter_vma() with the new VMA flags in madvise_update_vma(). Meanwhile we can remove the khugepaged_enter_vma() in hugepage_madvise(). Link: https://lore.kernel.org/7d5b5eb27be798f89d563b06254c947ff53db0b2.1787020910.git.baolin.wang@linux.alibaba.com Fixes: 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()") Signed-off-by: Baolin Wang Reported-by: Lance Yang Closes: https://lore.kernel.org/all/20260815181632.21453-1-lance.yang@linux.dev/ Suggested-by: Lorenzo Stoakes (ARM) Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Hugh Dickins Cc: Lance Yang Cc: Liam R. Howlett Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cc5d6446ead38026c378775b147e27cf02ff174a Author: Abel Vesa Date: Wed Aug 19 08:55:08 2026 +0300 Revert "pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza" commit 9fca7779ad18538188d640b1fdcfea924459542c upstream. This reverts commit b48a0a0a76ccecec60f0568e2af4d89994b08bec, which wrongfully added the MXC and MMCX power domains on Eliza. Even though they are indeed available in cmd-db, which has been the source of information for adding these two, at hardware level they are not actually wired up. Therefore they need to be dropped. Fixes: b48a0a0a76cc ("pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza") Signed-off-by: Abel Vesa Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e19e41d1c62816a1f87a66da2bf150b1dc928df3 Author: Eric Dumazet Date: Tue Aug 25 14:25:15 2026 +0000 Revert "once: don't use a work queue to reset sleepable static key" commit 0ba6912f7e974045dcdd170f022cba19247e00bc upstream. This reverts commit e8eef69a99f185e75909adb24ab93d706e07bf27. While DO_ONCE_SLEEPABLE() is used from sleepable/process context, callers may still be holding arbitrary subsystem locks. For instance, __inet_hash_connect() uses get_random_sleepable_once() which invokes DO_ONCE_SLEEPABLE() while holding the socket lock (sk_lock): lock_sock(sk) __inet_hash_connect() get_random_sleepable_once() DO_ONCE_SLEEPABLE() __do_once_sleepable_done() static_branch_disable() static_key_disable() cpus_read_lock() Calling static_branch_disable() directly from __do_once_sleepable_done() causes static_key_disable() to synchronously acquire cpus_read_lock() (cpu_hotplug_lock) and jump_label_mutex inside the caller's lock context. This introduces an unwanted lockdep dependency: sk_lock -> cpu_hotplug_lock Because cpu_hotplug_lock depends on fs_reclaim (via workqueue CPU bringup allocating memory with GFP_KERNEL), and storage/block layers (such as NVMe-TCP) acquire sk_lock during I/O dispatch, lockdep reports circular locking dependencies: set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu This false positive previously prompted commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance") to work around the warning using per-socket dynamic keys in NVMe-TCP. That in turn broke asynchronous socket teardown and caused syzbot warnings in tcp_tsq_handler(). Restoring once_disable_jump() in __do_once_sleepable_done() ensures that static_branch_disable() is executed asynchronously from a system workqueue without holding the caller's locks. Link: https://lore.kernel.org/20260825142515.1965654-1-edumazet@google.com Fixes: e8eef69a99f1 ("once: don't use a work queue to reset sleepable static key") Signed-off-by: Eric Dumazet Closes: https://lore.kernel.org/lkml/ao0mwtt8ePAINFni@shinhome/ Reported-by: Shin'ichiro Kawasaki Cc: Tony Luck Cc: Reinette Chatre Cc: Keith Busch Cc: Nilay Shroff Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3ddf7b95818a5e86fb67b79d5bea050759b3aafb Author: caina Date: Fri Aug 21 17:17:20 2026 +0800 Revert "irqchip/mbigen: Fix mbigen node address layout" commit e67091609cf85962f64391c1b0f93d4cbfcd4e22 upstream. This reverts commit 6be6cba9c4371d27f78d900ccfe34bb880d9ee20. Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 -> all in node 9 enahisic2i1: pins 1200-1246 -> node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 <- node 9 enahisic2i1-rx5 pin 1215 count 1 <- node 9, last pin enahisic2i1-tx5 pin 1216 count 0 <- node 10, first pin enahisic2i1-rx6 pin 1218 count 0 <- node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing -- it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 -- so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. Fixes: 6be6cba9c4371d27f78d900ccfe34bb880d9ee20 ("irqchip/mbigen: Fix mbigen node address layout") Suggested-by: Marc Zyngier Signed-off-by: caina Signed-off-by: Thomas Gleixner Acked-by: Yipeng Zou Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821091720.16665-1-caina@uniontech.com Signed-off-by: Greg Kroah-Hartman commit a78d2d9a84569f8878d46c15e36f571b2acd5c74 Author: Christian Marangi Date: Fri Aug 21 10:52:15 2026 +0200 pmdomain: airoha: fix unselectable AIROHA_CPU_PM_DOMAIN kconfig commit 6d94c47a2e3a38170a0a141547e4c52fbe232cc3 upstream. The AIROHA_CPU_PM_DOMAIN config was wrongly guarded under the Mediatek PM Domains menu and was unselectable. Move it outside the menu so it's now visible and correctly selectable by default on Airoha SoC. Cc: stable@vger.kernel.org Fixes: 82e703dd438b ("pmdomain: airoha: Add Airoha CPU PM Domain support") Signed-off-by: Christian Marangi Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1cbed7538946c99e585acefd11c9ba3a0bdbae05 Author: Shivam Kumar Date: Thu Aug 27 15:24:55 2026 -0400 nvmet-tcp: reject unsolicited H2CData PDUs commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d95d342bc0ea82dc79e6362b2f1f997431750e4c Author: Shivam Kumar Date: Fri Aug 14 15:48:11 2026 -0400 nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar Cc: stable@vger.kernel.org Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit eb4f9127a2b8a152743f1ee597627e2f69cb54fe Author: Kazuki Hanai Date: Sun Aug 30 22:11:05 2026 +0900 nvmet-auth: Synchronize timeout work during SQ teardown commit eaa948c0e19b1bb2d93262207bca0c3d19cc3406 upstream. nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive. Fixes: 1a70200f404a ("nvmet-auth: expire authentication sessions") Cc: stable@vger.kernel.org Signed-off-by: Kazuki Hanai Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit bb6dafa79040357cf5043836e1db108c2af8b1e1 Author: Chao Shi Date: Mon Aug 17 13:58:59 2026 -0400 nvme: skip the zoned limits update if the zone info query failed commit 3838e80fcfb32e62baffb63c6dc0a60153665a4d upstream. nvme_query_zone_info() returns either a negative errno or a positive NVMe status code, but nvme_update_ns_info_block() only tests for the negative case: ret = nvme_query_zone_info(ns, lbaf, &zi); if (ret < 0) goto out; If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvme_set_max_append(), the positive status falls through and setup continues with the zero-initialized zone info. nvme_update_zone_info() then marks the queue zoned with chunk_sectors and ns->head->zsze set to zero. blk_validate_zoned_limits() does not check chunk_sectors, so the limits commit succeeds. blk_revalidate_disk_zones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and disk_zone_no() shifts by ilog2(0): nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative disk_zone_no include/linux/blkdev.h:747 [inline] bio_straddles_zones include/linux/blkdev.h:1058 [inline] blk_zone_wplug_handle_write block/blk-zoned.c:1423 [inline] blk_zone_plug_bio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blk_mq_submit_bio+0x18fb/0x2870 block/blk-mq.c:3196 submit_bh_wbc+0x575/0x740 fs/buffer.c:2824 __block_write_full_folio+0x728/0xdd0 fs/buffer.c:1933 Any device, firmware or NVMe-oF target that fails this one command reaches this. Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvme_query_zone_info() that return a positive status logs anything, so the failure would otherwise be silent. zi.zone_size is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles. Found by FuzzNvme. Fixes: c85c9ab926a5 ("nvme: split nvme_update_zone_info") Cc: stable@vger.kernel.org Cc: Weidong Zhu Suggested-by: Keith Busch Reviewed-by: Christoph Hellwig Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 76023560d60f10b4f808941163aa2975f1631683 Author: Tristan Madani Date: Sat Aug 15 00:14:27 2026 +0000 nvme: add missing SRCU grace period in error path commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 upstream. nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Sagi Grimberg Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit a0c389b8a495bda1eb719d2503853c924b7a8355 Author: Yehyeong Lee Date: Tue Aug 18 20:04:05 2026 +0900 nvme-tcp: check the data direction of a C2HData PDU commit f83af377c148f6ad94b41c0e8313f12adf45e1c1 upstream. nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 5f89d68c00ccd1b25151da0bf660012380c2bad9 Author: Niklas Cassel Date: Fri Aug 14 16:38:34 2026 +0200 nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails commit 56e6279266f6962bb2d38a54397e3c605165b0c5 upstream. nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 ("nvme: split device add from initialization") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del(). Fixes: 1a9e218195a5 ("nvme: split device add from initialization") Cc: stable@vger.kernel.org Reported-by: syzbot+f58e57380a6083c4041d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f58e57380a6083c4041d Signed-off-by: Niklas Cassel Tested-by: Rihyeon Kim Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d21da6cc91ba1c4f1ae5ba007f3cb89e1c0c7549 Author: Xu Rao Date: Thu Aug 13 16:31:07 2026 +0800 nvme-fabrics: fix DHCHAP secret leak on parse failure commit afdee49a1b88ed9bb44e2b30e855297c169bcc53 upstream. nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing dhchap_secret=BAD or dhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets. Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Xu Rao Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit b3e0f79af1f27339d8d2527c02cc3e8397c2f69f Author: GuoHan Zhao Date: Fri Jul 17 14:11:45 2026 +0800 accel/ethosu: fix job completion fence cleanup commit 2d2a3adc91950f9a18829dadc7317fb5180a15c5 upstream. ethosu_ioctl_submit_job() allocates done_fence before validating buffer handles. Errors after allocation call ethosu_job_err_cleanup(), which frees the job but leaks the uninitialized fence. A scheduler dependency error also lets ethosu_job_run() return before dma_fence_init(). Normal cleanup then passes a zeroed refcount to dma_fence_put(). Release done_fence in the common cleanup path and use dma_fence_was_initialized() to distinguish initialized fences from raw allocations. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260716065219.931088-1-zhaoguohan@kylinos.cn?part=1 Signed-off-by: GuoHan Zhao Link: https://patch.msgid.link/20260717061145.1478139-6-zhaoguohan@kylinos.cn [robh: also fix goto] Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit f7aad73b481194e3f0efba9688e9a5914bbd036b Author: GuoHan Zhao Date: Thu Jul 16 14:52:19 2026 +0800 accel/ethosu: check MMIO mapping errors in probe commit 7ab64476a610fe65858fdc37c7a30caa13e334ac upstream. devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors. Return the mapping error before initializing the device. Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver") Cc: stable@vger.kernel.org Signed-off-by: GuoHan Zhao Link: https://patch.msgid.link/20260716065219.931088-1-zhaoguohan@kylinos.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit f00def884a831dc49eb659dac2dd09dbfd21e67f Author: Taimuraz Kaitmazov Date: Tue Aug 18 02:06:55 2026 +0300 accel/amdxdna: return early from a zero-length flush commit dc14753664240cedf669623b27ae9922b0618b25 upstream. SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults: BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna] drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0 Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it. Nothing needs flushing for an empty range, so answer before choosing a path. Fixes: e252e3f3488a ("accel/amdxdna: Revise device bo creation and free") Cc: stable@vger.kernel.org Signed-off-by: Taimuraz Kaitmazov Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260817230655.356785-1-taimuraz@kaitmazov.com Signed-off-by: Greg Kroah-Hartman commit dd403f6a38c530e35a21856fa7a13fecbd0c94f4 Author: Vincent Donnefort Date: Tue Sep 1 16:54:42 2026 +0100 ring-buffer: Allow splice reads on static buffers commit 6365c44a824ff138e7926413932bb5c2e28a4c8c upstream. ring_buffer_read_page() rejects splice (full=1) reads on static buffers (that is user-mapped, persistent or remote) because !read check assumes unread pages must be swapped. However for those buffers we have no other choice than memcpy the data. For the memcpy case, only return an error when the writer is still on the reader page for the splice interface to wait. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901155445.1475405-2-vdonnefort@google.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Vincent Donnefort Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 50afadf1ea66597116eb14e73c24da7ae99b759f Author: Takashi Iwai Date: Fri Aug 28 13:55:39 2026 +0200 ALSA: pcm: Fix race between non-atomic ops and trigger-start commit acac7b5e07349a9d10d78873afb4b93cd1dc721f upstream. We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd209eb3136e002becbda232e399fa31a2276436 Author: Runyu Xiao Date: Sun Aug 30 14:34:11 2026 +0800 ALSA: harmony: initialize locks before requesting IRQ commit 33abb7491e89285a41565670945293dda841afc4 upstream. snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260830063411.2215691-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit faba321da0eb62503a95129c5ffd17ec22ec351f Author: HyeongJun An Date: Wed Sep 2 21:50:58 2026 +0900 ALSA: rawmidi: Return the error from snd_rawmidi_input_params() commit f4a23e17d84fd2a152d9e12369761934e1af0ee8 upstream. The snd_rawmidi_input_params() computes err for the three invalid mode combinations and for resize_runtime_buffer(), applies the new framing and clock type only when err is zero, and then returns 0 anyway. A caller that asked for parameters the kernel rejected is told the change succeeded, and the substream keeps its old buffer. The open_mutex conversion turned the early returns into assignments. It handled the output sibling correctly, which still returns err, and left this one behind. Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 34f1d4f9f5ea6becd56e4d83181cca75d97f5b78 Author: Khushit Shah Date: Mon Aug 31 10:54:44 2026 +0000 arm64: errata: pass REVIDR when matching target implementation CPUs commit 5541432e09dc2031978188f3e8a00b9fc78cf097 upstream. When target implementation CPUs are provided, is_affected_midr_range() accidentally passed the MIDR as both arguments to __is_affected_midr_range(), so the REVIDR mask check operated on the wrong register. Pass REVIDR as intended. Fixes: 86edf6bdcf05 ("smccc/kvm_guest: Enable errata based on implementation CPUs") Cc: stable@vger.kernel.org Signed-off-by: Khushit Shah Reviewed-by: Zenghui Yu (Huawei) Acked-by: Marc Zyngier Reviewed-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d2d22ff377cd43f2e9660426ff22e3cd4c534637 Author: Fuad Tabba Date: Thu Aug 27 19:59:37 2026 +0100 arm64: Don't read GMID_EL1 when MTE is disabled commit 5445d64199626974269fcdf347769ad44b0bb53b upstream. __cpuinfo_store_cpu() gates the GMID_EL1 read on the raw ID_AA64PFR1_EL1, so it reads the register even when the kernel has disabled MTE (CONFIG_ARM64_MTE=n or arm64.nomte). KVM sets HCR_EL2.TID5 in that case, and pKVM injects an UNDEF the host cannot handle: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP pc : __cpuinfo_store_cpu+0xf4/0x264 Kernel panic - not syncing: Attempted to kill the idle task! Only pKVM reaches it, and only after a CPU is offlined and brought back online: its CPU_ON relay sets the host HCR before the CPU enters EL1, while plain nVHE sets it at CPUHP_AP_KVM_ONLINE. Gate the read on the CPU's own ID_AA64PFR1_EL1 with the command-line override applied, and on CONFIG_ARM64_MTE, which no register reflects. The boot CPU stores its registers before init_cpu_features() strips an unsafe override, so clamp against the hardware value here too. Fixes: f35abcbb8a084 ("KVM: arm64: Trap MTE access and discovery when MTE is disabled") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 0f05d95b99164a9ccc4cf4a4920e0ff0228138ad Author: Karl Mehltretter Date: Fri Aug 28 19:41:31 2026 +0200 arm64: mm: Fix the lockless page-table walk in show_pte() commit a77644d009dece1104b6fcc6e322b0e4503db0d6 upstream. show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value. Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit b00ada2f55c539a14420dc77f9a8185da51a1a24 Author: Guangshuo Li Date: Wed Aug 12 17:44:25 2026 +0800 i2c: qcom-cci: fix autosuspend cleanup commit f98d4986482151a835b521a734722fe8dc5ca37d upstream. cci_probe() calls pm_runtime_use_autosuspend(), but the remove path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without undoing the autosuspend setting during teardown, this reference is not dropped and usage_count remains unbalanced. Use devm_pm_runtime_set_active_enabled() to manage the runtime PM state. Its managed cleanup disables autosuspend and runtime PM and restores the suspended state on probe failure and driver removal. Remove the now redundant manual runtime PM cleanup. This issue was found by manual code inspection. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Guangshuo Li Cc: # v5.8+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812094425.3515179-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit 694e7e6edf249723ca7d3ef77c2ca1badfc78dc4 Author: Ahmad Byagowi Date: Sun Aug 23 09:34:36 2026 -0700 i2c: mux: Fix channel node leak on adapter add failure commit 385c7af4e3b95d0769fd211831674e83b16a2ebf upstream. i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data. Fixes: bc45449b1444 ("i2c/of: Automatically populate i2c mux busses from device tree data.") Signed-off-by: Ahmad Byagowi Cc: # v3.5+ Acked-by: Peter Rosin Signed-off-by: Andi Shyti Link: https://patch.msgid.link/b3e46bbee781b3cb4029aca9a71316cc5e36dc17.1787502619.git.ahmadexp@gmail.com Signed-off-by: Greg Kroah-Hartman commit 552836be2d95c688eede6371f85532abe1a71232 Author: Vasileios Almpanis Date: Wed Aug 12 11:14:48 2026 +0200 i2c: core: fix debugfs UAF on adapter removal commit b15b548d52b43ba8ac4652bc2c7244a8dd1e9622 upstream. i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left. Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Reported-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=23ad911c819b923238b7 Signed-off-by: Vasileios Almpanis Cc: # v6.8+ Tested-by: syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-i2c-v2-1-5efaab4c3334@gmail.com Signed-off-by: Greg Kroah-Hartman commit 19cd6394f7ddc59cde16a26d614f59efdeabdc9d Author: Kathiravan Thirumoorthy Date: Wed Aug 12 14:00:55 2026 +0530 i2c: qcom-geni: update frequency table to fix timing parameters commit a4f3fbccb65de757569686baaf2b72e329096aba upstream. In IPQ5424, to meet the setup and hold timing requirements in the standard mode, update the frequency table with the values recommended by HW design team. Also remove the stray space in the I2C_MAX_FAST_MODE_FREQ entry. Fixes: 85c34532849d ("i2c: qcom-geni: fix I2C frequency table to achieve accurate bus rates") Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock") Signed-off-by: Kathiravan Thirumoorthy Cc: # v6.13+ Reviewed-by: Mukesh Savaliya Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260812-ipq5424_i2c_scl_updates-v2-1-e09cd39d01d7@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit ac257b283962b8039e71373cf99566711fd5c57e Author: Hongbo Yao Date: Wed Aug 26 15:05:47 2026 +0800 i2c: designware: Enable interrupt mask workaround for HJMC3001 commit 77549d01edecc20da73c8599e14648877198ce9b upstream. On HJMicro ARM64 servers, the DesignWare I2C controller does not retrigger a pending interrupt if the interrupt status changes after the current status bits have been cleared. The issue is exposed under heavy system load when the corresponding SPI is routed across sockets to a core in the remote socket. The interrupt is then lost and the I2C transfer times out. Enable ACCESS_INTR_MASK for HJMC3001. This toggles DW_IC_INTR_MASK before returning from the interrupt handler and retriggers any pending interrupt. Fixes: 6816ce57c479 ("i2c: designware: Add a new ACPI HID for HJMC01 I2C controller") Signed-off-by: Hongbo Yao Cc: # v6.13+ Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260826070547.268672-1-andy.xu@hj-micro.com Signed-off-by: Greg Kroah-Hartman commit 0c739f54f1c77f3a4643160cd2e031b6c2f2aab6 Author: Yilin Zhang Date: Tue Sep 1 00:21:55 2026 +0800 perf: Fix use-after-free when perf mmap() revival races with the last munmap() commit 58a8108bc73de0740d5b88150465d6690ea5f85f upstream. perf_mmap_close() drops rb->mmap_count *without* holding event->mmap_mutex (the refcount_dec_and_test() right before the refcount_dec_and_mutex_lock() of event->mmap_count). A concurrent perf_mmap_rb() can slot its entire "revival" path into that window (perf_mmap holds event->mmap_mutex for its whole duration, including rb_alloc): munmap side (perf_mmap_close) mmap side (perf_mmap_rb) ----------------------------------- -------------------------------- rb->mmap_count 1 -> 0 (no lock) (holds event->mmap_mutex) inc_not_zero(rb->mmap_count) fails ring_buffer_attach(event, NULL) rb_alloc() + attach new rb refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> frees the *new* rb The revival's refcount_set(&event->mmap_count, 1) is an invisible 1 -> 1 write: the close frees the just-revived buffer although the other process still has it mapped -- a page-level use-after-free allowing local privilege escalation to root by any unprivileged user (default kernel.perf_event_paranoid=2). Swap the order of the two counter updates: event->mmap_count is dropped first via refcount_dec_and_mutex_lock(), so its 1 -> 0 transition and the ring_buffer_attach() stay serialized with perf_mmap(). rb->mmap_count == 0 then implies every event using the buffer is detached already, so the result of the rb->mmap_count drop can gate the remaining teardown directly and detach_rest is no longer needed. An earlier fix for this race from Kyle Zeng and David Lee takes event->mmap_mutex around both counter updates [0]; here the not-last close stays lockless. Fixes: 59741451b49c ("perf: Identify the 0->1 transition for event::mmap_count") Reported-by: Kimi Security Team Suggested-by: Peter Zijlstra Co-developed-by: Weiming Shi Signed-off-by: Weiming Shi Signed-off-by: Yilin Zhang Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/linux-perf-users/20260804060931.711308-1-david.lee@trailofbits.com/ [0] Cc: Cc: stable@vger.kernel.org # 6.18+ Link: https://patch.msgid.link/20260831162155.1437652-1-yilinzhang@moonshot.ai Signed-off-by: Greg Kroah-Hartman commit 517b02eaf30ddd5b0fcfc03f581cdcf10afc9fd9 Author: Haiyong Sun Date: Fri Sep 4 21:45:27 2026 +0800 perf build: Add clang and rust target flags for LoongArch commit a2628ce4ddb6873e35380a42396d17a66e704a1a upstream. Add missing CLANG_TARGET_FLAGS_loongarch and RUST_TARGET_FLAGS_loongarch so that perf can be built with clang and enable rust cross compilation. Cc: stable@vger.kernel.org Acked-by: Miguel Ojeda Acked-by: Dmitrii Dolgov <9erthalion6@gmail.com> Signed-off-by: Haiyong Sun Signed-off-by: WANG Rui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit d9a9da94c9da6b808404a282f39766c72fa37572 Author: Sizhe Liu Date: Thu Jul 30 14:27:07 2026 +0800 perf hisi-ptt: Fix PTT trace TLP header parsing commit 2b8a2e5d424f0b3369054305d0bf6a5b9faee6c1 upstream. TLP Headers traced by HiSilicon PCIe tune and trace device (PTT) in 4DW format are shown in the document as below: bits [31:30] [ 29:25 ][24][23][22][21][ 20:11 ][ 10:0 ] |-----|---------|---|---|---|---|-------------|-------------| DW0 [ Fmt ][ Type ][T9][T8][TH][SO][ Length ][ Time ] DW1 [ Header DW1 ] DW2 [ Header DW2 ] DW3 [ Header DW3 ] Problem: The DW0 bit field layout of the hisi_ptt_4dw union does not match the actual bit ordering in little-endian memory, causing incorrect field decoding. Test on Kunpeng 930 SOC, generating data flow with `iperf` commands: - server side: iperf -s - client side: iperf -c $ip_addr -t 30 Trace the TLP headers with hisi_ptt on server side at the same time: perf record -e hisi_ptt12_0/type=4,filter=0x05101,direction=2,format=0/ \ --max-size 50M -o perf.data & The trace aims to capture completion TLPs, learn more in the document: https://docs.kernel.org/trace/hisi-ptt.html Decode perf.data with hisi_ptt decoder: perf report -D The hisi_ptt decoder produces the following result: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 68 87 20 94 Format 3 Type 1a T9 0 T8 1 TH 1 SO 1 Length 10 Time 4a1 . 00000004: 40 00 00 00 Header DW1 . 00000008: 40 00 01 51 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] According to PCIe r5.0 sec 2.2.1, the Fmt & Type of Cpl/CplD is supposed to be 8b'00001010' / 8b'01001010' However, the Format & Type decoder analyzing result is 8b'01111010'. It does not match field encodings of any TLP. Correct decoder result should be: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 94 20 87 68 Format 2 Type a T9 0 T8 0 TH 0 SO 1 Length 10 Time 768 . 00000004: 00 00 00 40 Header DW1 . 00000008: 51 01 00 40 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] To solve the problem: 1. Drop the union and C bitfield struct, store the raw DW value in a plain uint32_t, and extract the fields with FIELD_GET() against GENMASK/BIT masks declared in the header so they can be reused by other translation units. The masks are portable across endianness and compilers. 2. Print all DW hex values in big-endian byte order for readability, matching the bit field layout shown in the 4DW format diagram. 3. Read the DW value with get_unaligned_le32() instead of an unaligned pointer cast, avoiding both strict-aliasing violations and alignment hazards on hosts that do not support unaligned access. Cc: stable@vger.kernel.org Fixes: 5e91e57e6809 ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet") Reviewed-by: James Clark Signed-off-by: Sizhe Liu Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit ecd69a46c029c62479660bf0be5d7a9121322f5e Author: Viktor Malik Date: Tue Jul 7 08:52:47 2026 +0200 perf trace: Refactor augmented_raw_syscalls using bpf_for commit ea6992784d65ef2c01f3525217dbf3a44afa9917 upstream. The loop for processing syscall args in augment_raw_syscalls has a history of breaking with Clang updates, see e.g. commit 013eb043f37b ("perf trace: Fix BPF loading failure (-E2BIG)") from Clang 15 to 16. Now, a similar thing happened between Clang 21 and 22. While the issue is mitigated on the main line by a recent verifier update, it remains broken on the 6.12 and 6.18 stable branches: [linux-6.18.y]# sudo perf trace true libbpf: prog 'sys_enter': BPF program load failed: -E2BIG libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG -- [...] BPF program is too large. Processed 1000001 insn processed 1000001 insns (limit 1000000) max_states_per_insn 40 total_states 37941 peak_states 232 mark_read 0 -- END PROG LOAD LOG -- libbpf: prog 'sys_enter': failed to load: -E2BIG libbpf: failed to load object 'augmented_raw_syscalls_bpf' libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -E2BIG Error: failed to get syscall or beauty map fd [...] The reason is that the loop is quite complex and the BPF verifier often struggles to prove that it terminates. Fix the issue by replacing the standard for loop with the bpf_for macro, which uses a numeric BPF iterator. This should prevent future breakages of this kind since the verifier has a much easier job proving that the loop terminates. Small adjustments were necessary for the loop to make it work. The main problem is that the verifier sometimes has problems with bpf_for loops that use a carry-over state, such as the `payload_offset` and `output` vars here, since the verifier tries to track their values too precisely and cannot prove loop convergence. To resolve the issue, we (1) explicitly recompute `payload_offset` in every iteration and (2) use a trick with adding a global zero to `output` to help the verifier forget its precise state and use a range instead. Finally, to keep backwards compatibility with older kernel versions that don't have bpf_for (i.e. numeric iterators), fall back to standard loop. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Suggested-by: Andrii Nakryiko Fixes: a68fd6a6cdd3 ("perf trace: Collect augmented data using BPF") Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 92ad79c286f63dc89a63497ff5d05674bde03dc9 Author: Viktor Malik Date: Tue Jul 7 08:52:46 2026 +0200 perf trace: Factor out BPF loop body commit acff3e1a9cc29a6a039b76b81a438c56016bc0e3 upstream. The BPF program in augmented_raw_syscalls uses a for loop to iterate all syscall arguments. The loop body is quite complex and often poses problems for the BPF verifier. As a preparation step for addressing this issue, factor out the loop body into a separate function. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit a820237b037852e8353f0a3866cf0293bb50c63a Author: Dapeng Mi Date: Tue Jun 16 12:46:47 2026 +0800 perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities commit 8767b4d73018bd3143f4c55b672064fad292f11b upstream. AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of PERF_CAPABILITIES MSR. It's not a good practice to define a bit to represent "anythread deprecation" in perf_capabilities. It leads to the anythread_deprecated bit could be overwritten by the real value of PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does. if (!intel_pmu_broken_perf_cap()) { /* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */ rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities); } It leads to the anythread_deprecated bit is cleared to 0 and the "any" attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on these support Perfmon v6 platforms, like Clearwater Forest. $ grep . /sys/devices/cpu/format/* /sys/devices/cpu/format/acr_mask:config2:0-63 /sys/devices/cpu/format/any:config:21 /sys/devices/cpu/format/cmask:config:24-31 So remove the anythread_deprecated bit from perf_capabilities structure and directly depends on CPUID.0AH:EDX[15] to judge if anythread is deprecated. Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional") Reported-by: Namhyung Kim Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Zide Chen Reviewed-by: Thomas Falcon Acked-by: Namhyung Kim Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-2-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 68c4b780b266a435261a1e029bede5ee3c2735cc Author: Dapeng Mi Date: Tue Jun 16 12:46:50 2026 +0800 perf/x86/intel: Fix kernel address leakages in LBR stack commit e2b0575900ff72aa82748af96e7bd564ade5157a upstream. Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: Ian Rogers Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616044654.3468742-5-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a5c7962e64fff837f848f07b834731c4d606a945 Author: Lad Prabhakar Date: Fri Aug 21 22:10:21 2026 +0100 rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers commit 51458d5b0a1cfb1b6013400abc95aadf16ed2a57 upstream. rzn1_rtc_set_alarm() updates RZN1_RTC_ALM, RZN1_RTC_ALH and RZN1_RTC_ALW using separate MMIO writes without first disabling the alarm interrupt. If a previous alarm is still enabled, the interrupt can fire while the alarm registers contain a mixture of old and newly written values. Fix this by disabling the alarm interrupt before reprogramming ALM, ALH and ALW with a call to rzn1_rtc_alarm_irq_enable(). Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-7-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit ea318a4675ee94533b3e8f2b28c203d7179e5467 Author: Lad Prabhakar Date: Fri Aug 21 22:10:19 2026 +0100 rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm commit 457b5dbce31209e65e1184716ed3af59cb1c0372 upstream. RZN1_RTC_ALW is a weekday bitmask where bit N represents weekday N. When no alarm has been configured, the register has its power-on-reset value of zero. rzn1_rtc_read_alarm() uses fls() to convert the weekday bitmask into a weekday number. When RZN1_RTC_ALW is zero, fls(0) returns zero and fls(wday) - 1 evaluates to -1. This invalid weekday is then used to calculate the alarm date and can either leave tm_wday set to -1 or produce a fabricated alarm date. Treat a zero RZN1_RTC_ALW value as an unset alarm weekday and return without calculating the alarm date. Move reading RZN1_RTC_CTL1 before this check so that alrm->enabled is updated for both configured and unconfigured alarms. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 75c1e64b7b14e36b0cf4037034a0e89df384bb45 Author: Lad Prabhakar Date: Fri Aug 21 22:10:18 2026 +0100 rtc: rzn1: Fix weekday underflow when alarm crosses month boundary commit 022a2839a52006531804a8db55d3228084400b48 upstream. rzn1_rtc_set_alarm() calculates the alarm weekday from the difference between the alarm day and the current day of the month. When the alarm crosses a month boundary, this difference can become negative. Since days_ahead is unsigned, it underflows and results in an incorrect weekday being programmed into RZN1_RTC_ALW. The RTC core already provides a fully populated struct rtc_time for the alarm, including the correct tm_wday. Use tm->tm_wday directly instead of recalculating the weekday from the day-of-month. This avoids the underflow and ensures alarms scheduled across a month boundary use the correct weekday. Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Suggested-by: Wolfram Sang Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 2f249681089040e4bdb90518428150fc56a282fc Author: Lad Prabhakar Date: Fri Aug 21 22:10:17 2026 +0100 rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt commit 708546aa39560a11cf44c7ba99492c8395a6c2fb upstream. Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle the deferred probe request properly. Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER indicates that the interrupt subsystem is not yet ready. Intercept this specific error condition, assign it to the return value, and jump to the dis_runtime_pm label to avoid ignoring a valid probe deferral. Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://patch.msgid.link/20260821211032.13554-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5ec8f629a300cc40e746d6178f724bdff7683fa7 Author: Shakeel Butt Date: Tue Aug 11 13:31:55 2026 -0700 memcg: make the v1 soft limit knob inert commit a3417097fb107cea3358b19bcbb4eb655fd67f8c upstream. The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd. Link: https://lore.kernel.org/20260811203203.3456029-2-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/ Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d44c3c5986c7a4a5f913a813e18cda08a838f91b Author: Shakeel Butt Date: Tue Jul 28 19:46:12 2026 -0700 memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done commit 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7 upstream. At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds. Link: https://lore.kernel.org/20260729024612.3369005-1-shakeel.butt@linux.dev Link: https://lore.kernel.org/7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com/ [1] Signed-off-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: David Rientjes Cc: Muchun Song Cc: Nhat Pham Cc: Rik van Riel Cc: Roman Gushchin Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6165478eaa3094eaee1d5e33b12520064faf043d Author: Shakeel Butt Date: Fri Aug 7 07:24:05 2026 -0700 memcg: keep folio's objcg same as its node commit bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26 upstream. memcg_reparent_objcgs() has an inherent assumption that a folio's objcg is the objcg of the folio's node. Folio migration across nodes breaks that assumption: the new folio simply inherits the old folio's objcg while living on a different node. Once the assumption is broken, the reparenting of the folio's objcg and the reparenting of the folio's LRU list are no longer atomic. memcg_reparent_objcgs() handles one node per iteration and drops all the locks in between, so the objcg gets reparented in the iteration for the objcg's node while the LRU list gets spliced in the iteration for the folio's node. Any LRU operation on that folio in between resolves its lruvec through the objcg, and thus takes the lru_lock of the wrong memcg, not the lru_lock of the list the folio is actually on. Fix this by selecting the objcg by folio_nid() at charge time, and by re-deriving it for the destination node in mem_cgroup_migrate() and mem_cgroup_replace_folio(). Link: https://lore.kernel.org/20260807142406.443516-1-shakeel.butt@linux.dev Fixes: f1cf8d2f36dc ("mm: memcontrol: eliminate the problem of dying memory cgroup for LRU folios") Signed-off-by: Johannes Weiner Signed-off-by: Shakeel Butt Reported-by: Karl Erik Hofseth Closes: https://lore.kernel.org/all/anMmd1ADrDVwMO6v@work/ Co-developed-by: Johannes Weiner Acked-by: Muchun Song Acked-by: Qi Zheng Cc: Michal Hocko Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2943f1f4b7f2816177060eb9f551f2e6d8b629ba Author: Eric Dumazet Date: Fri Aug 21 17:04:07 2026 +0000 mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave() commit 540e583b66d6402bf556fde5e53c817a54c1afe5 upstream. syzbot reported a sleeping function called from invalid context splat in bucket_table_alloc(). When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the passed GFP_ATOMIC flags. If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy, alloc_pages_bulk_weighted_interleave() is called and currently hardcodes GFP_KERNEL when allocating the temporary weights array, triggering a might_alloc() splat in atomic/RCU contexts. Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator zone modifiers like __GFP_HIGHMEM) received by alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding GFP_KERNEL. Since the weights buffer is immediately initialized in full, kmalloc() is sufficient. Link: https://lore.kernel.org/20260821170407.3721004-1-edumazet@google.com Fixes: fa3bea4e1f82 ("mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving") Signed-off-by: Eric Dumazet Reported-by: syzbot+0dbf6d295b3350944f0b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a88837e.ae6ddae5.3da009.0040.GAE@google.com/T/#u Reviewed-by: Andrew Morton Reviewed-by: Gregory Price (Meta) Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Byungchul Park Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9435cddf1378d149d826bd7bd1448a44bf96868d Author: Usama Arif Date: Wed Aug 19 03:12:22 2026 -0700 mm/huge_memory: transfer the pmd dirty bit to the folio on zap commit fe6cf984939d8e12cb33a99673c8d026c5135e68 upstream. zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way. Link: https://lore.kernel.org/20260819101222.3732660-1-usama.arif@linux.dev Fixes: b5072380eb61 ("thp: support file pages in zap_huge_pmd()") Signed-off-by: Usama Arif Acked-by: David Hildenbrand (Arm) Reviewed-by: Kiryl Shutsemau Acked-by: Hugh Dickins Tested-by: Lance Yang Reviewed-by: Zi Yan Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Nhat Pham Cc: Rik van Riel Cc: Ryan Roberts Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d69841dbd92afd011a0b5237cce9b5669dc00fb2 Author: Baineng Shou Date: Mon Aug 17 13:04:55 2026 +0800 misc: fastrpc: don't publish fd before copy_to_user() succeeds commit a4a1a2bfcb29785292d634d7787edc6fb550714d upstream. fastrpc_ioctl_alloc_dmabuf() calls dma_buf_fd() which installs the fd into the caller's fd table before copy_to_user() copies the fd number back to userspace. If copy_to_user() fails, the fd is already visible to other threads in the same process but the ioctl returns -EFAULT. The existing comment in the code even acknowledges the problem: "The usercopy failed, but we can't do much about it, as dma_buf_fd() already called fd_install()..." Now that dma_buf_fd_install() is available (introduced to fix the same issue in dma-heap), apply the same pattern here: reserve the fd with get_unused_fd_flags(), attempt copy_to_user(), and only on success call dma_buf_fd_install() to publish it atomically with the tracepoint. On copy_to_user() failure, put_unused_fd() and dma_buf_put() cleanly unwind without any user-visible side effects. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Cc: stable@vger.kernel.org Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-3-shoubaineng@gmail.com Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 6e62cf983a2bd547e6bbd3f935539233e5f97f8f Author: Masami Hiramatsu (Google) Date: Sun Aug 30 23:27:23 2026 +0900 kprobes: Protect kprobe_blacklist with RCU commit 0c4256196b3a105307e2235fbfd85e768bbcdd0f upstream. __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period. Link: https://lore.kernel.org/all/178810004323.64882.16493230858653316962.stgit@devnote2/ Fixes: 376e242429bf ("kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260807155802.F06041F000E9@smtp.kernel.org/ Assisted-by: Antigravity:gemini-3.7-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 732510e13ee59a5feb970f6a2f9db63f3d358d12 Author: Ju Nan Date: Fri Aug 21 10:47:57 2026 +0800 irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout commit d31fbbade43f880b7e59e2b3a72722fe2725d93f upstream. HWSPNLCK_TIMEOUT is passed to hwspin_lock_timeout_in_atomic(), whose timeout argument is in milliseconds, not microseconds: atomic_delay += HWSPINLOCK_RETRY_DELAY_US; if (atomic_delay > to * 1000) return -ETIMEDOUT; So stm32mp_exti_set_type() asks for a 1 second timeout where the comment next to the macro says it wants 1 millisecond. The semaphore is polled with udelay() from a section that holds chip_data->rlock, a raw_spinlock_t, so preemption stays disabled for the whole wait on every configuration, PREEMPT_RT included. The hwspinlock core documents this explicitly: If the mode is HWLOCK_IN_ATOMIC (called from an atomic context) the timeout is handled with busy-waiting delays, hence shall not exceed few msecs. Fixes: 5257169ade8c ("irqchip/stm32-exti: Use the hwspin_lock_timeout_in_atomic() API") Signed-off-by: Ju Nan Signed-off-by: Thomas Gleixner Reviewed-by: Radu Rendec Reviewed-by: Antonio Borneo Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821024756.24927-2-junan76@163.com Signed-off-by: Greg Kroah-Hartman commit d62a84a78de5f29c642fa3bd4eee072ba7289cb4 Author: Bradley Morgan Date: Thu Aug 27 17:43:38 2026 +0000 ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() commit 8861f6d5c0678a7c5089c7b272509fc5931b8437 upstream. dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing. Fixes: 4f2946aa0c45 ("IMA: introduce a new policy option func=SETXATTR_CHECK") Cc: stable@vger.kernel.org Reported-by: syzbot+5ebeb3089ea6439c37be@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a8f89e5.1d9ded08.62e62.00bf.GAE@google.com/ Signed-off-by: Bradley Morgan Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit e5b64bd7e57fbf97ad6c8cbd0b24142e81b7fd86 Author: Hajo Noerenberg Date: Mon Aug 31 14:43:03 2026 +0200 ata: ahci: work around lost interrupts on Marvell 88SE61xx commit dc3565a4ae538e584e5e63b3b3cd1eaf502593c1 upstream. ahci_single_level_irq_intr() services the ports first and clears the global HOST_IRQ_STAT afterwards, as recommended by AHCI 1.1 section 10.6.2. The Marvell 88SE6111/6121/6145 family stops reporting interrupts for a port when HOST_IRQ_STAT is cleared while PxIS still holds bits: PxIS keeps its content, HOST_IRQ_STAT reads back as 0, the port is never looked at again, and the command in flight only ends in a timeout. Measured on a Seagate Blackarmor NAS440 (Marvell 88F6281 Kirkwood, 88SE6121 rev B2 behind PCIe) by polling the AHCI registers from userspace while an IDENTIFY was outstanding: t=303.046 irqs 127 PxIS 0x00000000 PxCI 0x00000001 IDENTIFY issued t=303.057 irqs 128 PxIS 0x00000020 PxCI 0x00000000 CI cleared, DPS set, one interrupt taken ... PxIS stays 0x00000020, HOST_IRQ_STAT stays 0 ... t~308.05 qc timeout after 5000 msecs The command had completed - PxCI was clear and PxIS had DPS set - so ahci_qc_complete() would have completed it. It never got the chance because the handler read HOST_IRQ_STAT as 0 and returned IRQ_NONE. Marvell's own driver for these chips clears the two registers in the opposite order and says so ("clear global before channel"), and ahci_xgene handles its broken edge latch the same way. Since the reordering costs at most one spurious interrupt per valid one on conforming controllers, do it in a private interrupt handler selected for board_ahci_mv instead of changing libahci for everyone. With this applied, SATA-2 and SATA-3 disks work at 3.0 Gbps on the 88SE6121 without the drive-side 1.5 Gbps jumper that was needed before. Time from link up to a successful IDENTIFY: WDC WD5000AADS-00S9B0 port 0 7 ms (never identified before) WDC WD3202ABYS-01B7A0 port 1 28 ms WDC WD30EFRX-68EUZN0 port 1 200 ms (3 TB, HPA detection ok) Only the 88SE6121 was tested; board_ahci_mv also covers the 88SE6145, which Marvell's driver treats identically. Fixes: cd70c26617f4 ("[libata] AHCI: Add support for Marvell AHCI-like chips (initially 6145)") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-ide/db6b48b7-d69a-564b-24f0-75fbd6a9e543@noerenberg.de/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216094 Signed-off-by: Hajo Noerenberg Reviewed-by: Damien Le Moal Acked-by: Pali Rohar Link: https://lore.kernel.org/r/20260831124303.920391-1-hajo-linux-ide@noerenberg.de Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit df1a97d5313fccadb08390306d49b194fb027392 Author: Max Kellermann Date: Mon Aug 24 18:47:07 2026 +0200 ceph: lock mutex in ceph_mds_check_access() commit a61c6ae1dae2611082b831b4aaa780878099c012 upstream. MDS session OPEN handling replaces mdsc->s_cap_auths under mdsc->mutex, freeing the previous array and its strings. ceph_mds_check_access() traverses this array without holding the mutex. A concurrent session reopen can therefore free the array while it is being inspected, resulting in a use-after-free like this: Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE [..] pc : ceph_mds_check_access+0xd4/0x550 lr : ceph_mds_check_access+0xc8/0x550 [...] Call trace: ceph_mds_check_access+0xd4/0x550 (P) ceph_atomic_open+0x138/0xbe8 path_openat+0xa24/0xfa8 do_filp_open+0x94/0x158 do_sys_openat2+0x88/0xf8 Cc: stable@vger.kernel.org Fixes: 596afb0b8933 ("ceph: add ceph_mds_check_access() helper") Signed-off-by: Max Kellermann Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a5b5e62baceff9e252c6535cf42a027d04f226cf Author: Hui Su Date: Fri Aug 7 01:56:00 2026 +0800 bpf: Fix infinite loop in pcpu_freelist push with one possible CPU commit efebf6496685c93150df5bb0794363ae70c5f58a upstream. __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused. Fixes: f2ac0e5d1c4d ("bpf: Convert percpu_freelist.c to rqspinlock") Signed-off-by: Hui Su Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260806175600.1993595-1-sh_def@163.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit 683fa887e19f399712c6dcc248b133142f03c6b2 Author: Chen Pei Date: Wed Sep 2 14:14:51 2026 +0800 bpf, riscv: Make arena support depend on ZACAS commit 536b523b407397c8d3967c020ce7aad70a0ea030 upstream. The arena range tree allocates its nodes with kmalloc_nolock() since commit f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree"). kmalloc_nolock() requires slab caches with cmpxchg128 support (__CMPXCHG_DOUBLE); on riscv cmpxchg128 is provided by the ZACAS extension. On systems without ZACAS every arena map creation fails with a misleading -ENOMEM. Report the missing support instead: make bpf_jit_supports_arena() return system_has_cmpxchg128() where it is defined, so arena map creation fails with -EOPNOTSUPP on systems without ZACAS. The macro is only defined when both CONFIG_RISCV_ISA_ZACAS and CONFIG_TOOLCHAIN_HAS_ZACAS are enabled, so guard it with #ifdef the same way mm/slab.h consumes it, and reject arena otherwise. This matches how arena BPF_CMPXCHG instructions are already gated on ZACAS in bpf_jit_supports_insn(). Fixes: f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree") Signed-off-by: Chen Pei Acked-by: Pu Lehui Acked-by: Björn Töpel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260902061451.1416-1-cp0613@linux.alibaba.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit fdbaeae9313b27faba52694dd90debd53096f4ba Author: Damien Le Moal Date: Mon Aug 31 11:50:50 2026 +0900 block: flag zoned disks with GENHD_FL_NO_PART commit 3f9c7a108c0e8f14425384912017071b71341e3b upstream. Zoned block devices do not support partitions. However, the partition table is nevertheless still inspected, and any partition found ignored with a warning in add_partition(). While this is generally not a problem, and in fact beneficial to the user as it indicates an invalid use of a zoned block device, scanning for a partition table on the device may result in issuing read operations to offline zones (e.g. after a disk head is depopulated for disks that support head management operations). Since partitions are ignored anyway, completely disable partition scanning for zoned gendisks by setting the flag GENHD_FL_NO_PART in __add_disk(). The existing check in add_partition() is left as-is to ensure that we still get a warning if for whatever reason, despite GENHD_FL_NO_PART, we still endup trying to add partitions. Flagging zoned disks with GENHD_FL_NO_PART also has the benefit to expose through sysfs the ext_range attribute with the value of 1 instead of the default DISK_MAX_PARTS, thus correctly advertizing the fact that zoned disks do not support partitions. Fixes: 5eac3eb30c9a ("block: Remove partition support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260831025050.667758-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9b7c322cf29ed2a3a67b08fda815d58aaa397e76 Author: Ulf Hansson Date: Wed Aug 26 10:45:32 2026 +0200 cpuidle: psci: Fix support for probe deferral by dropping the faux device commit 0606f2114e2dc88fe293858fd991cda2688b8c3a upstream. At the conversion to the faux driver/device we broke the support for probe deferral. In hindsight, the move to the faux device seems questionable, as it simply makes the code more complicated and for no good reason. To fix the support for the probe deferral let's therefore restore the old code and drop the faux device. Fixes: af5376a77e87 ("cpuidle: psci: Transition to the faux device interface") Fixes: 5836ebeb4a2b ("cpuidle: psci: Avoid initializing faux device if no DT idle states are present") Fixes: 39cdf87a97fd ("cpuidle: psci: Fix uninitialized variable in dt_idle_state_present()") Cc: stable@vger.kernel.org Reviewed-by: Abel Vesa Signed-off-by: Ulf Hansson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3394c7ba23336bdb7ece29127130fd01731d42d8 Author: Linkai Gong Date: Fri Aug 21 15:57:28 2026 +0800 cpuidle: dt_idle_genpd: kfree() the original name allocation commit 2b0ac85512b7f67479127b2713254490662eb13d upstream. dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Linkai Gong Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e79449be26ac864c1926c2358f0eced0b00dfe69 Author: Koichiro Den Date: Fri Jul 31 01:07:01 2026 +0900 dmaengine: dw-edma: Mark emulated IRQ as level-triggered commit 0d995da5fb97e8c312834575604d4423eb6225b7 upstream. The interrupt-emulation virtual IRQ uses handle_level_irq(), but the IRQ descriptor has not been marked with IRQ_LEVEL. The interrupt emulation is somewhat unusual: the eDMA interrupt handlers dispatch the virtual IRQ for every edma_int[] interrupt because software cannot reliably tell an interrupt-emulation event from one caused solely by DONE/ABORT status. If an interrupt arrives before the doorbell handler is registered for the virtual IRQ, the IRQ core marks it pending. When the IRQ is later started, check_irq_resend() treats it as non-level and replays the pending interrupt, causing the newly registered handler to run for a stale event. Mark the virtual IRQ with IRQ_LEVEL so the stale pending state is cleared without being replayed. This was observed in pci_endpoint_test as two doorbell handler calls when the DMA-variant test ran before DOORBELL_TEST. Fixes: d9d5e1bdd180 ("dmaengine: dw-edma: Add virtual IRQ for interrupt-emulation doorbells") Cc: stable@vger.kernel.org Reported-by: Niklas Cassel Closes: https://lore.kernel.org/r/ampndLtU32ODmncX@ryzen Tested-by: Niklas Cassel Signed-off-by: Koichiro Den Reviewed-by: Frank Li Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260730160701.3550710-1-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit d91fb6c0d10dad32929dc5c6850f89df34e1bfcd Author: Koichiro Den Date: Tue Jul 21 15:28:05 2026 +0900 dmaengine: dw-edma: Initialize IRQ data before requesting IRQs commit 647217abea849d3d45f8cb0b8ee5b78d50f26985 upstream. dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260721062815.4117887-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3044460e2d310da8da28df4cdbd2d42b098c3eb8 Author: Koichiro Den Date: Sat Jul 18 03:06:34 2026 +0900 dmaengine: dw-edma: Complete descriptors before pausing commit c154060016a9db2ac889bfdb0a3c1322f9be8ded upstream. If PAUSE is requested while the final burst of a descriptor is in flight, the DONE interrupt takes the PAUSE path without checking whether the descriptor has been depleted. The depleted descriptor remains on the issued list and the channel enters EDMA_ST_PAUSE. On resume, dw_edma_start_transfer() can select that depleted descriptor again even though no burst remains, leaving the channel in an invalid busy state. Check for descriptor completion before acknowledging PAUSE. If there is no work to start on resume, leave the channel idle. Also ignore DONE interrupts while the channel is paused so a stale or repeated interrupt cannot change its state or start queued work. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-5-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 8cd010697b79b27419cacf3ef08b059aea8dc1a9 Author: Koichiro Den Date: Sat Jul 18 03:06:31 2026 +0900 dmaengine: dw-edma: Fix HDMA channel status register access commit ef1b080e03acc83d5bde841da67036985acd50dc upstream. GET_CH_32() takes the direction before the channel ID, but dw_hdma_v0_core_ch_status() passed them in the opposite order. This can make the status callback read another HDMA channel status register. Use the same argument order as the other HDMA register accesses. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260717180639.2643243-2-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2a3801ae5c344473e648006c5b03a9216ac54a6a Author: Martin Kaiser Date: Sat Jul 18 14:58:48 2026 +0200 dmaengine: fsl-edma: tracing: no ptr dereference during log output commit 2ea04dca8e627f722caa7a2037cfbae0257f3501 upstream. The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility. Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support") Cc: stable@vger.kernel.org Reviewed-by: Steven Rostedt Signed-off-by: Martin Kaiser Reviewed-by: Frank Li Link: https://patch.msgid.link/20260718130024.341243-1-martin@kaiser.cx Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit feeb2ef775081a6c188cdd10e7a45369a07ce531 Author: Aneesh Kumar K.V (Arm) Date: Fri Jul 17 23:34:19 2026 +0530 dma-direct: return struct page from dma_direct_alloc_from_pool() commit 94a04ad732c9f8b9554270fc4038a06737de5c22 upstream. Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller. Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") Cc: stable@vger.kernel.org Tested-by: Michael Kelley Tested-by: Mostafa Saleh Reviewed-by: Jason Gunthorpe Signed-off-by: Aneesh Kumar K.V (Arm) Reviewed-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260717180442.110954-2-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 0d4a5d218055db29b50cc07d3d73d27007c2a391 Author: Baineng Shou Date: Mon Aug 17 13:04:54 2026 +0800 dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds commit 30d0aff2c65a277135cfd8ea28fa1ee75e0ea4e0 upstream. DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable@vger.kernel.org Reviewed-by: T.J. Mercier Acked-by: Christian König Acked-by: Sumit Semwal Signed-off-by: Baineng Shou Link: https://lore.kernel.org/r/20260817050457.1005285-2-shoubaineng@gmail.com Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 94380ecd5ff9b2a2b9f6e8a0b5c465159ccfaf71 Author: Mikulas Patocka Date: Mon Jul 27 22:26:36 2026 +0200 dm: fix resume-vs-remove race commit 44b43ec132f1cf3275ecc182d0c82f50c3c4c3d5 upstream. If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 00ad6f9ed27f91925d4d3fb7aab50a60d774f998 Author: Mikulas Patocka Date: Mon Jul 27 22:27:07 2026 +0200 dm: fix race when loading and unloading a table commit 5380c7f6335cc6d77eb77d065105e81155c4d9d3 upstream. If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0cdc6cb242dd8d2731956fdf3390de094482a4b2 Author: Ibrahim Hashimov Date: Mon Jul 13 11:34:14 2026 +0200 HID: wacom: validate report length in wacom_intuos_pro2_bt_irq commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d upstream. wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 48934c2927414a37a7fadeb6091113177c0b2038 Author: Wei Jie Law <98lawweijie@gmail.com> Date: Tue Aug 25 18:31:17 2026 +0800 HID: rmi: fix OOB access with undersized RMI reports commit 4956993bb3befdf791d71a4952d8d13bcfd44c7b upstream. The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles a reply carrying fewer bytes than requested, and a write longer than the output report was overrunning the buffer already. Verified on v6.12.69 and on v6.12.105 built with CONFIG_KASAN=y and booted kasan_multi_shot, whose hid-rmi.c is identical to mainline here. An emulated RMI4 device driven over /dev/uhid, and the same device again over dummy_hcd plus raw-gadget, give identical results: BUG: KASAN: slab-out-of-bounds in rmi_hid_read_block+0x409/0x750 [hid_rmi] Read of size 21 at addr ffff88800bf33bba by task kworker/0:3/285 __asan_memcpy+0x23/0x60 rmi_hid_read_block+0x409/0x750 [hid_rmi] rmi_f01_probe+0x5dd/0x1dc0 [rmi_core] BUG: KASAN: slab-out-of-bounds in rmi_hid_write_block+0x1a9/0x350 [hid_rmi] Write of size 35 at addr ffff88810a2b24ac by task kworker/1:10/666 __asan_memcpy+0x3c/0x60 rmi_hid_write_block+0x1a9/0x350 [hid_rmi] rmi_driver_set_irq_bits+0x1f6/0x4d0 [rmi_core] rmi_driver_probe+0x636/0xbf0 [rmi_core] rmi_input_configured+0x184/0x2e0 [hid_rmi] rmi_probe+0x952/0xcf0 [hid_rmi] and, for the zero-length reply, a probe worker left in D state in rmi_hid_read_block() after 225 replies at 200 ms intervals. After this change the undersized descriptor is refused at probe with "rmi reports too small (out=2 in=2)", the oversized read and write are both rejected, the zero-length reply fails the read with -EIO while later reads on the same device keep working, and a device declaring reports large enough for a 21-byte register read still probes normally and reports its real product id. A device bound through new_id with RMI_DEVICE in its driver_data no longer reaches rmi_set_page() with an unallocated writeReport either. Link: https://lore.kernel.org/linux-input/20260822121007.153988-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260824122708.76168-1-98lawweijie@gmail.com/ Link: https://lore.kernel.org/linux-input/20260825060954.104890-1-98lawweijie@gmail.com/ Fixes: 9fb6bf02e3ad ("HID: rmi: introduce RMI driver for Synaptics touchpads") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit bfb7939788f3c8dd080a4dd81e38d625b35d194e Author: Shen Yongchao Date: Mon Aug 3 22:31:57 2026 +0800 HID: bpf: serialize device reference release in struct_ops destroy path commit 9cdc7e6dc7a99ad7311ad5e7c145f2b9ce4e24b0 upstream. __hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock. Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it: - device destruction: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program; - BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration. The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory. The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal. Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference. Fixes: ebc0d8093e8c ("HID: bpf: implement HID-BPF through bpf_struct_ops") Cc: stable@vger.kernel.org Signed-off-by: Shen Yongchao Assisted-by: Hermes:kimi-k3 Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit b260b54f11405e63afce3a9afe23e3bf6c4807a0 Author: Steven Rostedt Date: Wed Sep 2 09:55:01 2026 -0400 ftrace: Synchronize the initialization of ftrace_ops commit 4617721c502b2ddaa4e324e86da4997edf738fa5 upstream. There's some internal state that ftrace_ops needs to have set, but since it can be declared outside of the ftrace.c code, it calls ftrace_ops_init() on the ops in every global function. The issue is that if two tasks call it on the same ops at the same time it is possible to have the initialization of one corrupt the initialization of the other call. Create a ops_mutex to use to synchronize every initialization of the ftrace_ops. The mutex is taken within checking the ftrace_ops flag that states it was initializied but the flag is checked again after the mutex has been taken. Checking first outside the mutex allows it to shortcut having to take the mutex. But then the check needs to be done again after the mute is taken in case of races. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock") Reported-by: sashiko-bot@kernel.org Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit cee8f286794df916553d8d445eac5c323ec5b0f8 Author: Steven Rostedt Date: Fri Aug 28 22:39:01 2026 -0400 ftrace: Take trace_array reference before accessing its ftrace_ops commit 9100191e5acb2e5ea2313f436667bb5fce129f47 upstream. The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828223901.29e26edb@robin Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions") Reported-by: Breno Leitao Tested-by: Breno Leitao Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b715872ef0ccc00daaa4b714c5a60a5067ac1e9b Author: Sebastian Andrzej Siewior Date: Tue Sep 1 15:54:51 2026 +0200 futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling commit 912edebe8501a36c6bedcef03bd238ab90a7e060 upstream. There is rt_mutex_{pre|post}_schedule() around rt_mutex_wait_proxy_lock() to ensure that sched_submit_work()/ sched_update_worker() is invoked before we schedule out and block on rt_mutex while waiting for it become available. The reason is that blocking on rt_mutex assigns a pi_waiter for the PI chain and sched_submit_work() will also assign a pi_waiter if it blocks on lock but a this point we already have a waiter assigned. We can't skip sched_submit_work() entirely because I/O relies on the fact that I/O queue is flushed while it blocks on a sleeping lock. Therefore sched_submit_work() is moved before we block on the lock. Sleeping lock in this context means mutex or rw_semaphore not spinlock_t on PREEMPT_RT. Because the mutex abstraction on PREEMPT_RT uses the same abstraction as the futex proxy lock, the futex code ended up using rt_mutex_{pre|post}_schedule(), too. Using it is/ was just to keep the task_struct::sched_rt_mutex assertion happy. Futex proxy lock is used only in the syscall context of a task. At this point it never got any I/O that needs to be flushed and it can't be a workqueue that needs to notify that it will be scheduled out. Therefore sched_submit_work() does nothing here. By mistake futex_wait_requeue_pi() -> rt_mutex_wait_proxy_lock() did not get the rt_mutex_{pre|post}_schedule() annotation. This was not noticed because in this callchain the lock is (usually) not contended and so rt_mutex_slowlock_block() does not schedule, triggering the assert. Adding rt_mutex_pre_schedule() here looks wrong (as noted by PeterZ) because at this point there is a pi_waiter recorded and invoking sched_submit_work() with a possible lock contention would be wrong. Add rt_mutex_futex_{pre|post}_schedule() which toggles the sched_rt_mutex assert and does not involve sched_submit_work(). Add asserts here to ensure that sched_submit_work() would do nothing. Use it only in futex proxy lock case which is rt_mutex_wait_proxy_lock(). Remove it from futex_lock_pi(). Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers") Reported-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-2-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/20260717084922.4153317-2-yaokai34@huawei.com Signed-off-by: Greg Kroah-Hartman commit e4a4ccfa470f910b747b3ee8d18670ed8ac8a236 Author: Yao Kai Date: Tue Sep 1 15:54:52 2026 +0200 futex: Prevent rcuwait use-after-free during requeue PI commit a3b8d46fe401cba3a5c46dea610e6eb3dc15370e upstream. On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message] Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Signed-off-by: Yao Kai Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman commit 3b4f72bdddff69819d665395376329ef21f37a06 Author: Lorenzo Stoakes (ARM) Date: Wed Aug 26 17:30:35 2026 +0100 mm/secretmem: properly account locked pages commit 97d34aa65c29cca85e3e9050f4c936389b38a054 upstream. secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream. Link: https://lore.kernel.org/20260826-secretmem-accounting-v3-1-94cb04399510@kernel.org Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: Daehyeon Ko <4ncienth@gmail.com> Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/ Reviewed-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand (Arm) Tested-by: Daehyeon Ko <4ncienth@gmail.com> Cc: Alexei Starovoitov Cc: David Hildenbrand Cc: David S. Miller Cc: Hagen Paul Pfeifer Cc: Jakub Kacinski Cc: James Bottomley Cc: Jesper Dangaard Brouer Cc: John Fastabend Cc: Liam R. Howlett Cc: Michal Hocko Cc: Stanislav Fomichev Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0b8faf28d1374bb5aa87988b724f491dbe40d461 Author: SJ Park Date: Fri Jul 17 17:14:35 2026 -0700 mm/damon/core: initialize damos->last_applied commit af5f76aeb9c9aa9c77d5e1d94e0ee4618c805239 upstream. Patch series "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs". Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit tests that do invalid memory access under test failures. The bugs are better to be fixed and eventually merged into stable@ kernel. That said, the fixes are arguably not urgent. Patch 1 only introduces negligible DAMOS efficiency degradation in occasional cases. Kunit fixes could introduce quite bad consequences but those are test code that affect only test run setups. This patch (of 7): Multiple DAMON regions could exist across a folio. If they fulfill the condition to apply a DAMOS scheme, the scheme could be applied multiple times to the folio. To avoid this, each DAMOS scheme stores the folio that the scheme was applied to last time in the damos->last_applied field and skips repeatedly applying the same scheme to the same folio. The field is being used without initialization, though. Hence, the mechanism could wrongly skip applying a scheme to a folio at the very first time of DAMOS run. The user impact is trivial. DAMON might unexpectedly skip applying DAMOS action for one folio for the first time per scheme. In the DAMON's best-effort world, this is never a real problem. No critical consequences such as kernel panic or memory corruption happen. It is a clear bug, though, and the fix is straightforward. Fix the issue by initializing the field in DAMOS scheme creation function, damon_new_scheme(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-1-sj@kernel.org Link: https://lore.kernel.org/20260718001442.87129-2-sj@kernel.org Link: https://lore.kernel.org/20260714055436.120034-1-sj@kernel.org [1] Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 463ebd63e8ee3d73022a18915ea43320dad8aad7 Author: SJ Park Date: Sun Jul 19 08:54:40 2026 -0700 mm/damon/core: handle region split failure in apply_min_nr_regions() commit c608748607620f331196ed0ba9fe4017892c1457 upstream. damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260719155442.88794-1-sj@kernel.org Link: https://lore.kernel.org/20260717011834.120715-1-sj@kernel.org [1] Fixes: b1029f29eb1d ("mm/damon/core: split regions for min_nr_regions") Signed-off-by: SJ Park Cc: # 7.1.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 54ef3a3f14e9b72b45b192bffc634bef4d16bcd7 Author: SJ Park Date: Fri Jul 17 17:14:41 2026 -0700 mm/damon/core-kunit: skip wrong region walk in commit_target_regions() commit 488cf81c49955f83b7682dda880e9920c173e617 upstream. damon_test_commit_target_regions_for() traverses expected values array after damon_commit_target_regions() call. It assumes damon_commit_target_regions() made expected number of regions. It might not. Because the traversal is made based on the region count, it could do out of bounds access to the expectation value array. The consequent user impact (out-of-bound access) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-8-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 603f67eb91e0 ("mm/damon/tests/core-kunit: add damon_commit_target_regions() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bbbf6a9781fdac400b2e2b91cb3ca4fc22cf63d3 Author: SJ Park Date: Fri Jul 17 17:14:40 2026 -0700 mm/damon/core-kunit: skip wrong quota goal walk in commit_quota_goals() commit 867bbe6dbd5a68eb58e79cc7f068a6cf184c40d8 upstream. damos_test_commit_quota_goals_for() traverses damos quota goals after damos_commit_quota_goals() call. It assumes damos_commit_quota_goals() made expected numbers of goals. It might not. Because the traversal is made based on destination struct length, it could do out of bounds access for source expectation value array. The consequent user impact (out-of-bound access ) is quite bad. The realistic user impact would be limited though. It would affect only test run setups. Fix it by testing if the number of goals was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-7-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: d9adfb8a28e7 ("mm/damon/tests/core-kunit: add damos_commit_quota_goals() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bee189b41f9d0788b78ee57857bdcbd4082e2095 Author: SJ Park Date: Fri Jul 17 17:14:39 2026 -0700 mm/damon/core-kunit: skip wrong dest walk in commit_dests_for() commit 7e2f2c41b27f64caad6599073aaa0ccdd08745e1 upstream. damos_test_commit_dests_for() traverse damos action destinations after damos_commit_dests(). It assumes damos_commit_dests() made expected numbers of destinations for source and destination structures. It might not. Because the traversal is made based on destination struct length, it could do out of bounds access for source value expectation. The consequent user impact (out-of-bound access ) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by exiting early for the number of regions test failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-6-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: eec573b8dd65 ("mm/damon/tests/core-kunit: add damos_commit_dests() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 03a8f891723657b66cfd586ec48fffb3036fc801 Author: SJ Park Date: Fri Jul 17 17:14:38 2026 -0700 mm/damon/core-kunit: handle region split failure in filter_out() commit 3423fe70395210e2f0cd795270292f6a27cd57b5 upstream. damos_test_filter_out() test checks if damos_filter_match() of an address filter splits the region as expected under a given condition. But, the test continued regardless of the split successes. As a result, the later part of the test could dereference invalid pointers that returned from damon_next_region(). Further, it could corrupt memory from damon_destroy_region(). The consequent user impact (memory corruption) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by exiting early for the number of regions test failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-5-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.6.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4deb1ec699936b159810e2f4fa41bac51322c1ca Author: SJ Park Date: Fri Jul 17 17:14:36 2026 -0700 mm/damon/core-kunit: check region count before testing in split_at() commit 9b18ef3c3aa1ce24176e340061caf15fa2742564 upstream. damon_test_split_at() test next region that is assumed to be created by damon_split_region_at() invocation. But the split might fail. In this case, the succeeding test may dereference invalid pointers returned by damon_next_region(). The invalid pointer may not cause a really bad user impact, because of the implementation detail. It would only read wrong contents in the belonging damon_target struct. Depending on the future change of the offset from the link header to the accessing field, this could also be really dangerous, though. Still, the realistic user impact would be limited. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-3-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 54439210c91e45c412d2db1b10da4b7d992db3f0 Author: SJ Park Date: Sun Jun 28 15:01:10 2026 -0700 mm/damon/sysfs: kobject_del() target (normal), context and kdamond dirs commit 263af33a72d1995ae6cdc22b08d527e2bda17259 upstream. Patch series "mm/damon/sysfs: kobject_del() directories that users can create/remove". DAMON sysfs interface allows users to create and remove arbitrary number of directories on sysfs, using a few files having 'nr_' prefix. For example, 'nr_kdamonds'. When the user writes a number 'N' to the files, directories having name starting from '0' to 'N - 1' are created in the same directory. The pre-existing number-named directories are removed before creating the new directories. For the removal of the existing directories, DAMON sysfs interface use only kobject_put(). Because DAMON sysfs interface is the only kernel component that manages the directories, there is no problem in normal situations. However, if CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the removal of dirs are delayed. Let's suppose a user writes a non-zero number to the 'nr_*' files while there are pre-existing number-named directories, on the config enabled kernel. DAMON sysfs interface decreases the reference counts of the existing directories and immediately creates new directories. Because the removal of the sysfs directories is delayed, it shows some pre-existing directories of the same names when it tries to create the new directories, and fails. For example, the issue can be triggered like below: # grep DEBUG_KOBJECT_RELEASE /boot/config-$(uname -r) CONFIG_DEBUG_KOBJECT_RELEASE=y # ls nr_kdamonds # echo 1 > nr_kdamonds # echo 1 > nr_kdamonds bash: echo: write error: File exists # dmesg [...] [ 300.880458] kobject: kobject_add_internal failed for 0 with -EEXIST, don't try to register things with the same name in the same directory. [...] Some of the error handling paths of the directories also lack the kobject_del() call. If the user uses nr_* file right after the errors, similar issues can happen. This doesn't cause catastrophic issues like kernel panics or memory corruptions. Users can work around by removing all directories first (write 0 to the nr_* files) and then create new directories after confirming the old directories are gone. But, this is definitely a bug that causes a bad user experience. Fix the issues by calling kobject_del() before creating new directories. This patch (of 11) On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for normal creation paths of target, context and kdamond directories, and error paths of context and kdamond directories by adding kobject_del() calls. Note that this fix for target directories is not complete since it has a similar issue in the damon_sysfs_targets_add_dirs() error path. Because the normal path issue and the error path issue are introduced by different commits, this commit is fixing only the normal path issue. A commit for the error path will be added next. Link: https://lore.kernel.org/20260628220121.97360-1-sj@kernel.org Link: https://lore.kernel.org/20260628220121.97360-2-sj@kernel.org Fixes: c951cd3b8901 ("mm/damon: implement a minimal stub for sysfs-based DAMON interface") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e94f9f9478af3c38757bb6b6b23e27ad73c43c7f Author: SJ Park Date: Sun Jun 28 15:01:11 2026 -0700 mm/damon/sysfs: kobject_del() region and target (error) dirs commit 2603ef6f6ec3d3f7de2d6a07e7c9a683cebac419 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for the normal creation path of region directories and the error path of target directories, by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-3-sj@kernel.org Fixes: 2031b14ea757 ("mm/damon/sysfs: support the physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 11ce1b269aac592c19369317188b74de386ad96f Author: SJ Park Date: Sun Jun 28 15:01:13 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme region dirs commit f3ec3271210781c255e737498b84d5790e8176b4 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme region directories by adding kobject_del() calls. This issue was discovered [1] by Sashiko, though its analysis was partially incorrect. Link: https://lore.kernel.org/20260628220121.97360-5-sj@kernel.org Link: https://lore.kernel.org/20260517205828.6204-1-sj@kernel.org [1] Fixes: 9277d0367ba1 ("mm/damon/sysfs-schemes: implement scheme region directory") Signed-off-by: SJ Park Cc: # 6.2.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5091760ab2ac4d75bcf28896308b5e1c54b89028 Author: SJ Park Date: Sun Jun 28 15:01:15 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs commit 0d4397ca921ceaf80fc3eca4c8194812ff79a979 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme quota goal directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-7-sj@kernel.org Fixes: 7f262da0a30d ("mm/damon/sysfs-schemes: implement files for scheme quota goals setup") Signed-off-by: SJ Park Cc: # 6.8.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit eca049e5b5e5643270653889f0a6e0720e30c312 Author: SJ Park Date: Sun Jun 28 15:01:14 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme filter dirs commit 3c453bddacd4c04ecb38cf79dbfa41e7dfe0531b upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme filter directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-6-sj@kernel.org Fixes: 472e2b70eda6 ("mm/damon/sysfs-schemes: connect filter directory and filters directory") Signed-off-by: SJ Park Cc: # 6.3.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit df7a40102ae43418c42871aeba962785f3c7cb53 Author: SJ Park Date: Sun Jun 28 15:01:12 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme dirs commit 05fb6ac98c49be870c5f9ccdfdf95f0107e564ae upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-4-sj@kernel.org Fixes: 7e84b1f8212a ("mm/damon/sysfs: support DAMON-based Operation Schemes") Signed-off-by: SJ Park Cc: # 5.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 43b33bdace2c513a1b3a2f66e772da55e3106238 Author: SJ Park Date: Sun Jun 28 15:01:16 2026 -0700 mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs commit 286380c78bc51e6c578621b9ae660bf9e5ad2563 upstream. On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme action destination directories by adding kobject_del() calls. Link: https://lore.kernel.org/20260628220121.97360-8-sj@kernel.org Fixes: 2cd0bf85a203 ("mm/damon/sysfs-schemes: implement DAMOS action destinations directory") Signed-off-by: SJ Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b8ec303f53b04560379ab597622054e138a215ef Author: SJ Park Date: Sun Jun 28 14:54:44 2026 -0700 samples/damon/wsse: stop and free damon ctx when damon_call() fails commit a2c6fa6c23ad87c61e1379b05dc05cf5fed4bf8d upstream. damon_sample_wsse_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_wsse_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_wsse_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-6-sj@kernel.org Link: https://lore.kernel.org/20260610034828.4632-1-sj@kernel.org [1] Fixes: cc9c1b8c205b ("samples/damon/wsse: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e60774d6335b89fac0be8b17a041fcffc508d281 Author: SJ Park Date: Sun Jun 28 14:54:40 2026 -0700 samples/damon/wsse: handle damon_start() failure commit e4742be45ea45bf554399ce89a09f71e525d7981 upstream. Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-2-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: b757c6cfc696 ("samples/damon/wsse: start and stop DAMON as the user requests") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9fbc1811e83f9f93c34f3ab7cadb418c1530ab67 Author: SJ Park Date: Sun Jun 28 14:54:45 2026 -0700 samples/damon/prcl: stop and free damon ctx when damon_call() fails commit a73fa45d3f0f42c446ae55c5799e3d5ef044cd5d upstream. damon_sample_prcl_start() calls damon_call() right after damon_start() is succeeded. The kdamond that has started by the damon_start() could be terminated by itself before or in the middle of the damon_call() execution. There could be multiple reasons for such a stop including monitoring target process termination and kdamond_fn() internal memory allocation failures. In the case, damon_call() will fail and return an error without cleaning up the DAMON context object. The damon_sample_prcl_start() caller assumes it would clean up the object, though. When the user requests to start DAMON again, damon_sample_prcl_start() is called again, allocates a new DAMON context object and overwrites the pointer for the previous object. As a result, the previous context object is leaked. Safely stop the kdamond and deallocate the context object when the failure is returned. Note that the kdamond should be stopped first, because damon_call() failure means not complete termination of the kdamond but only the fact that the termination process has started. The user impact shouldn't be that significant because the race is not easy to happen, and only up to one DAMON context object can be leaked per race. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-7-sj@kernel.org Link: https://lore.kernel.org/20260610035214.4850-1-sj@kernel.org [1] Fixes: a6c33f1054e3 ("samples/damon/prcl: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f383b55811d8e8435366a4ab3b5ce5ea41b563ca Author: SJ Park Date: Sun Jun 28 14:54:41 2026 -0700 samples/damon/prcl: handle damon_start() failure commit 8b724349229bb6ebbf781178be011ba9bc2cca57 upstream. damon_sample_prcl_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_prcl/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_prcl/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-3-sj@kernel.org Link: https://lore.kernel.org/20260609145814.70163-1-sj@kernel.org [1] Fixes: 2aca254620a8 ("samples/damon: introduce a skeleton of a smaple DAMON module for proactive reclamation") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 215f9a7e4f1dcfc05ebcdc5c1ad0ea0dcb47bd09 Author: SJ Park Date: Sun Jun 28 14:54:43 2026 -0700 samples/damon/mtier: handle damon_stop() failure commit 9dc5b6d66fd51b103eff21ed0df3e292f489ebc0 upstream. damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-5-sj@kernel.org Link: https://lore.kernel.org/20260609014219.3013-1-sj@kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b4bba194bd06e07fc6d9a007928036d18a12aad5 Author: SJ Park Date: Sun Jun 28 14:54:42 2026 -0700 samples/damon/mtier: handle damon_start() failure commit c7230d08ee79b13127bd2b45a3648d361ac912fc upstream. damon_sample_mtier_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it could leak the memory for DAMON context. Also, if damon_start() fails for only the second context, the first context will indefinitely run, and avoid starting other DAMON contexts since it is running in the exclusive mode. Stop possibly started DAMON context and free the contexts in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo Y | sudo tee /sys/module/damon_sample_mtier/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the second command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the second and the third commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260628215447.96166-4-sj@kernel.org Link: https://lore.kernel.org/20260608112455.274231F00893@smtp.kernel.org [1] Fixes: 82a08bde3cf7 ("samples/damon: implement a DAMON module for memory tiering") Signed-off-by: SJ Park Reviewed-by: Zenghui Yu Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb97afccffd6a525c840c4e42213a713c17fa3ef Author: SJ Park Date: Fri Jul 17 17:14:37 2026 -0700 mm/damon/vaddr-kunit: check region count in three_regions test commit 5fea07e460874c8c7cf00f728efbe22abc62c8d8 upstream. damon_do_test_apply_three_regions() iterates regions after damon_set_regions() call assuming the function would succeed at setting the number of regions the same to the expected one. It might have failed. In this case, __nth_region_of() in the iteration could return NULL and NULL dereference can happen in the test. The consequent user impact (NULL dereference) is quite bad. The realistic user impact would be limited, though. It would affect only test run setups. Fix it by testing if the number of regions was also changed as expected and exit early for the failure. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-4-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3ed555fb2c6e41783174ce6de25bffbbc3e887e9 Author: SJ Park Date: Tue Jul 14 20:09:57 2026 -0700 mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() commit b640708929aa956235866bf7717d89018c661083 upstream. KUNIT_EXPECT_EQ() does not abort the execution of test code when the expectation is not met. But damon_test_merge_regions_of() code after its initial KUNIT_EXPECT_EQ() call assumes the expectation is met. It does a per-region test with a hard-coded number of regions that is correct only if the expectation was met. As a result, __nth_region_of() could return NULL, and the test code can dereference NULL pointers. Fix the issue by catching the expectation failure and skip the per-region tests. The user impact on realistic setups should be negligible, as it is a unit test. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-3-sj@kernel.org Link: https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 25253bbd8066d26fe4825a8262dd178ba27f3595 Author: SJ Park Date: Tue Jul 14 20:10:01 2026 -0700 mm/damon/sysfs: read ops_id only once in damon_sysfs_apply_inputs() commit 5adaaa28be8a79ddd7e103b171f9d6e14e7fc26e upstream. damon_sysfs_apply_inputs() reads ops_id twice. It could race with ops_id_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-7-sj@kernel.org Link: https://lore.kernel.org/20260703172417.95426-1-sj@kernel.org [1] Fixes: 8d009da32f13 ("mm/damon/sysfs: set damon_ctx->min_sz_region only for paddr use case") Signed-off-by: SJ Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 81e9ca01ebc2df9bdb05f6c723bffb93428adfec Author: SJ Park Date: Tue Jul 14 20:10:00 2026 -0700 mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs() commit ab4d9358e32316fa39b5f1f5360292135978c3d9 upstream. damon_sysfs_apply_inputs() reads addr_unit twice. It could race with addr_unit_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-6-sj@kernel.org Link: https://lore.kernel.org/20260714142950.100711-1-sj@kernel.org [1] Fixes: 540a2aebc657 ("mm/damon/sysfs: implement addr_unit file under context dir") Signed-off-by: SJ Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b9687ed098d7fd989e1ddd214f3d6ebb37e6197d Author: Song Hu Date: Tue Jul 14 07:01:13 2026 -0700 Docs/ABI/damon: fix typo in intervals_goal sysfs path commit 1b492fc82368399123413c937f13da6ed312ee4d upstream. Patch series "Docs/ABI/damon: sysfs ABI document fixes and additions", v2. This series fixes typos and fills in missing entries in the DAMON sysfs ABI document (Documentation/ABI/testing/sysfs-kernel-mm-damon). Patch 1 fixes a path typo, "intrvals_goal" -> "intervals_goal", in four What: entries; the documented path points to a non-existent directory, so it is Cc'ed to stable. Patch 2 fixes two further typos ("WDate:", "manimum"). Patches 3 and 4 add ABI entries that exist in the kernel and are already described in usage.rst but are missing from the canonical ABI document: the 'update_tuned_intervals' state command (patch 3) and the 'tried_regions//probes/

/hits' file (patch 4). This patch (of 4): The ABI document spells the DAMON sysfs directory as "intrvals_goal" (missing 'e') in four What: entries, but the kernel creates it as "intervals_goal" (mm/damon/sysfs.c). Following the documented path therefore yields a non-existent directory. Link: https://lore.kernel.org/20260714140117.94147-1-sj@kernel.org Link: https://lore.kernel.org/20260714140117.94147-2-sj@kernel.org Fixes: e2b23dc62369 ("Docs/ABI/damon: document intervals auto-tuning ABI") Signed-off-by: Song Hu Reviewed-by: SJ Park Signed-off-by: SJ Park Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Jonathan Corbet Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e20b16aa3b49f9db5510940740255a987e6f2a6f Author: Runyu Xiao Date: Mon Aug 24 19:36:18 2026 +0800 scsi: pm8001: Use rollback index when freeing MSI-X vectors commit 3f92a64545165bdbb36dee8fa35626b295463313 upstream. pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop. Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Jack Wang Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 4dd118d06dec9efe5065ac7897bdc18f404a3af4 Author: Thomas Lamprecht Date: Thu Aug 27 19:24:24 2026 +0200 scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame commit af8c27375733fb6a6df9fa484cda77cc3dd0cb80 upstream. megasas_make_prp_nvme() builds a command's PRP list in cmd->sg_frame, a DMA pool buffer of instance->max_chain_frame_sz bytes, spending one entry per NVMe page of the transfer plus one per page of the buffer for the chain pointer. The loop runs until the transfer is described and never checks the buffer bound. max_hw_sectors comes straight from the MDTS the firmware reports for the drive. On drives with a large MDTS the only thing keeping the list inside the buffer was the block layer default of 1280 KiB, which needs 320 entries, which fit into a 4 KiB frame as that holds 512. But since commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") that default is 4 MiB, and such a transfer needs 1025 entries, so the list runs a full page past the end of the frame: sd 1:0:1:0: [sdb] tag#630 page boundary ptr_sgl: 0x00000000ba62d13f BUG: unable to handle page fault for address: ff663bcb81e7c000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:megasas_build_and_issue_cmd_fusion+0xeaa/0x1870 [megaraid_sas] If the page after the frame happens to be mapped, the overrun does not fault but silently corrupts the neighbouring pool entry, which is another in-flight command's PRP list. Cap max_hw_sectors at what the chain frame can describe, less one page for transfers that do not start on a page boundary and so need one entry more. This is the megaraid_sas counterpart of commit 04631f55afc5 ("scsi: mpt3sas: Limit NVMe request size to 2 MiB"), but derives the limit from max_chain_frame_sz rather than hardcoding it. Cc: stable@vger.kernel.org Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Reported-by: Lukasz Magiera Closes: https://lore.kernel.org/all/GPhsSM0vkgyIrs0DIZ62qeUZX7X4RxwQXVKiuvMx-lHQVSPDxpztUyQOGS0xikqvJ-Z94hMV-dW_5KN_0CX2hsfV7kTf_t0MTf6vdAAaSEc=@magik.net/ Reported-by: Mira Limbeck Closes: https://lore.kernel.org/all/d171cc76-bf25-48ce-b482-d344669dfc24@proxmox.com/ Suggested-by: Martin K. Petersen Link: https://lore.kernel.org/all/yq17bmzd5jr.fsf@ca-mkp.ca.oracle.com/ Signed-off-by: Thomas Lamprecht Closes: https://lore.kernel.org/linux-scsi/20260827182106.535D61F000E9@smtp.kernel.org Link: https://patch.msgid.link/20260827175743.734593-1-t.lamprecht@proxmox.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit f033530105aa73d82c121d54b57f358e4865d2f4 Author: Rahul Chandelkar Date: Mon Aug 17 16:07:29 2026 +0800 scsi: bsg: Fix TOCTOU in io_uring passthrough command setup commit 4b3c5965fca99f62d31c963294bd5b23cc488e97 upstream. scsi_bsg_uring_cmd() reads bsg_uring_cmd from the shared mmap'd SQE. Userspace can change a field after we check it and before we use it. request_len is the sharp case: it can grow past sizeof(scmd->cmnd) after the bound check and overflow scmd->cmnd in copy_from_user(). READ_ONCE() the SQE fields we check or use into locals before use. Fixes: 7b6d3255e7f8 ("scsi: bsg: add io_uring passthrough handler") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260527105931.3950913-1-rc@rexion.ai Signed-off-by: Rahul Chandelkar Co-developed-by: Yang Xiuwei Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260817080730.967879-3-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5d326efc334ea21afd8161f6ca53e17de71948a9 Author: Yang Xiuwei Date: Mon Aug 17 16:07:28 2026 +0800 scsi: bsg: Cap io_uring sense copy to max_response_len commit ece06de726737e887dc0225c8283477624f8ae21 upstream. Completion copied scmd->sense_len to the user response buffer without honoring max_response_len. After a valid sense, the midlayer sets sense_len to the real length (up to SCSI_SENSE_BUFFERSIZE), so a smaller user buffer was overrun. Fixes: 7b6d3255e7f8 ("scsi: bsg: add io_uring passthrough handler") Cc: stable@vger.kernel.org Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260817080730.967879-2-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 3ddf3ea291a0ef2ea93b82e158960ac2cc42302b Author: Sujal Tuladhar Date: Sat Aug 1 21:30:00 2026 +0545 scsi: target: iscsi: Reserve a terminator byte for the login payload commit f4825922d2fb371e2b969697d792077f1b62b62c upstream. iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Assisted-by: Claude Opus5 (custom harness) Cc: stable@vger.kernel.org Signed-off-by: Sujal Tuladhar Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 5def8b6aaad44603740786262b95b6f77df52a1c Author: Honghui Jiang Date: Fri Aug 14 11:14:15 2026 +0800 spi: Fix DMA mapping ownership on partial map failure commit 367cea239fc93094e5c16a72724800e0358f5c46 upstream. If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners. Fixes: e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer") Cc: stable@vger.kernel.org Signed-off-by: Honghui Jiang Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260814031419.43378-2-jiang_hh2019@163.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 103e7b19d1085af94836b659c8f4c00752548f85 Author: Can Peng Date: Tue Aug 4 15:19:04 2026 +0800 spi: bcmbca-hsspi: disable clocks on resume failure commit d2f5a606710ad70c341dc609430a20a5645618d5 upstream. bcmbca_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804071904.860842-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6b1ccecf311c0610c92a6447719f8bd31c221447 Author: Can Peng Date: Tue Aug 4 15:18:31 2026 +0800 spi: bcm63xx: disable clock on resume failure commit 2b62c2c134fa32d9d3a9e7323c8ac74518eeb4ac upstream. bcm63xx_spi_resume() enables the controller clock before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves the clock enabled. Propagate the error and disable the clock before returning. Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Link: https://patch.msgid.link/20260804071831.860784-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d07d4fbae4793c472cf276ffc4569ad9d8d2ce2a Author: Can Peng Date: Tue Aug 4 15:20:17 2026 +0800 spi: bcm63xx-hsspi: disable clocks on resume failure commit 3b0cee02664041aea7e4f787c66cb86c82eb4e97 upstream. bcm63xx_hsspi_resume() enables the HSSPI clock, and optionally the PLL clock, before restarting the SPI controller queue. If spi_controller_resume() fails, the function currently reports success and leaves those clocks enabled. Propagate the error and disable the clocks before returning. Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Reviewed-by: Kursad Oney Link: https://patch.msgid.link/20260804072017.860974-1-pengcan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 220cea6c1662b9049d1af752fdac21939d2a6a94 Author: Viken Dadhaniya Date: Thu Jul 2 11:12:23 2026 +0530 soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size commit 522bfb4f33c0930b3d14d5c5ee80bc93a883b544 upstream. The hardcoded MAX_GENI_CFG_RAMn_CNT limit is not accurate for all SoCs: some targets have less CFG RAM than the constant implies, while others like QCS615 need more entries than the old limit of 455 allowed, causing valid firmware to be rejected at load time. Rather than hardcoding a constant, read PROG_RAM_DEPTH from SE_HW_PARAM_2 at runtime to get the actual CFG RAM depth of the hardware instance and use that as the upper bound for firmware size validation. Fixes: d4bf06592ad6 ("soc: qcom: geni-se: Add support to load QUP SE Firmware via Linux subsystem") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20260702-qup-se-increase-ram-cnt-v3-1-80b363373a5b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit b437284a4c29d8ee37e82ca831638353d5e583f0 Author: Paul Louvel Date: Wed Jul 8 12:15:14 2026 +0200 soc: fsl: qe: Add chained_irq_{enter,exit}() calls in cascade handler commit 7e47fe56415847732419ca8cef9307bf111dd368 upstream. Wrap the cascade handler body with chained_irq_{enter,exit}() to properly inform the parent IRQ chip that a chained interrupt is being serviced. Fixes: f0bcd784e1b76 ("soc: fsl: qe: Add an interrupt controller for QUICC Engine Ports") Signed-off-by: Paul Louvel Cc: stable@kernel.org Reviewed-by: Christophe Leroy (CS GROUP) Link: https://lore.kernel.org/r/20260708-qe-pic-gpios-v2-1-1972044cfbd1@bootlin.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Greg Kroah-Hartman commit fa5e1bc673ca59722608af67b27e65dba0c97926 Author: Kanishka De Silva Date: Sun Aug 30 12:31:33 2026 +0530 ublk: clear VM_MAYWRITE on read-only ublk char device mmap commit 6e2b571b0a54755b06e092501913e1dfefe75d6c upstream. ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES. Fixes: 3fee8d7599e1 ("ublk_drv: add io_uring based userspace block driver") Cc: stable@vger.kernel.org Signed-off-by: Kanishka De Silva Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260830070133.559-1-kpskanna1915@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dfc17986c608d7dea1bcd12a3feea0c537f1f992 Author: Bryan Lim Date: Wed Aug 19 10:08:24 2026 +0700 userfaultfd: reset err to be 0 when move_pages_ptes succeeded commit f025ca73decda1f895a4b80b961d3bc88825298a upstream. During move_pages() operation, when move_pages_ptes() returns EAGAIN, the error code is not cleared even after we processed it. This leads to a successful retry but then the same pages are retried again due to the stale error code. This time move fails because pages are already moved, loop is terminated and move_pages() reports a failure. Clear the error code once we processes EAGAIN. Link: https://lore.kernel.org/e1e0b5f8-c3c6-0537-670b-4397f822f980@gmail.com Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE") Assisted-by: ChatGPT:GPT-5.6-Luna Signed-off-by: Bryan Lim Reviewed-by: Suren Baghdasaryan Acked-by: Mike Rapoport (Microsoft) Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 64a41f4a9a968f54f3792399aa4d2a9fdb23b0a5 Author: Steven Rostedt Date: Wed Sep 2 12:19:18 2026 -0400 tracing: Take trace_array reference when opening options file commit f2951ebd15c36a1ea4820a7f0cbb0b5f1c028b73 upstream. The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902121918.5a9e9d1b@gandalf.local.home Fixes: 577b785f55168 ("tracing: add tracer dependent options to options directory") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-trace-kernel/20260828135858.2AC501F000E9@smtp.kernel.org/ Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2ee3f7d43f79efaca0cd84a6798653d9d75ce60b Author: Steven Rostedt Date: Fri Aug 28 09:41:53 2026 -0400 tracing: Have show_event_filters/triggers files take trace array ref commit f4a771cc684c7354b6200147f7252c58d17408ff upstream. The newly added files show_event_filters and show_event_triggers that show all filters or triggers that are set within the trace array do not take a reference for the trace array it is showing. Without taking a reference, the trace_array may be freed via "rmdir" while a task is reading one of theses files. Those files iterate all the events within an instance (trace_array) and nothing prevents that instance from being freed while its data is being read. This causes a use-after-free crash. Have the open of both those files take the trace_array reference via the trace_array_get() that prevents the trace_array from being freed while the files are opened. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260828094153.17b95037@gandalf.local.home Fixes: 729757b96a662 ("tracing: Add show_event_filters to expose active event filters") Fixes: 6a80838814eea ("tracing: Add show_event_triggers to expose active event triggers") Reported-by: Farhad Alemi Closes: https://lore.kernel.org/all/CA+0ovCjerKZJLwXScM9bF2ga2rLi4_XOpUfK41NDbENpeu98jA@mail.gmail.com/ Reviewed-by: Aaron Tomlin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e6ccc279cb8ed47e072e244a4228b104489f2b81 Author: Masami Hiramatsu (Google) Date: Tue Sep 1 23:21:37 2026 +0900 tracing/probes: Fix anon_stack check for unnamed bitfields in btf_find_struct_member commit f36d94a20ca185bcadef3a10b980cd2cfd72d53a upstream. btf_find_struct_member() traverses into nested anonymous structures and unions by pushing members with !member->name_off onto anon_stack. However, it does not consider the unnamed bitfields (e.g. `int : 5` or `unsigned int : 0`) which also have member->name_off == 0. If such an unnamed bitfield is pushed to anon_stack, the btf_find_struct_member() return an error even if there are other valid entries in anon_stack. To fix this, only push unnamed struct/union members to anon_stack. Also move the btf_type_is_struct() check to the entry of this function because now it is sure only struct/union are pushed to anon_stack. Link: https://lore.kernel.org/all/178827249775.123716.7813217688423513612.stgit@devnote2/ Fixes: 302db0f5b3d8 ("tracing/probes: Add a function to search a member of a struct/union") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260830143859.D56991F00A3D@smtp.kernel.org/ Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 50af36b7f9011fa4f2ab481dbe5a1480dd499d3c Author: Can Peng Date: Wed Jul 22 15:56:25 2026 +0800 thermal/drivers/qoriq: Disable clock on resume failure commit fcbf9964b67a6d6704c50ed28daa24c3b164f01c upstream. qoriq_tmu_resume() enables the TMU clock before clearing the power-down bit and enabling monitoring. If either register update fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed resume. Disable the clock on those failure paths before returning the error. Fixes: 51904045d4aa ("thermal: qoriq: Add clock operations") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260722075625.452684-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 909cdbd028f84931f6231fc6ce21582ffbcf4a0c Author: Can Peng Date: Wed Jul 22 16:49:09 2026 +0800 thermal/drivers/imx: Disable clock on runtime resume failure commit bcc6d886e5006a4656901d2d7fb6a215c96068a0 upstream. imx_thermal_runtime_resume() enables the thermal clock before powering up the sensor and enabling measurements. If either regmap_write() fails, the function returns with the clock still enabled. This leaves the clock enable count unbalanced after a failed runtime resume. Disable the clock on those failure paths before returning the error. Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Can Peng Signed-off-by: Daniel Lezcano Reviewed-by: Frank Li Link: https://patch.msgid.link/20260722084909.463437-1-pengcan@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 7236bbd2cb7d9fc0eda896bbd34790341e2a4377 Author: Arthur Gautier Date: Mon Aug 31 12:04:48 2026 +0300 xhci: fix lost bounce buffers on TDs spanning several ring segments commit ff44dfb03a293bf30e31f98772a1dd316a6071d1 upstream. When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.] Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Suggested-by: Michal Pecio Signed-off-by: Arthur Gautier Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fd19b8895f8a91087e8a62f1e27b128025dabb95 Author: Muhammad Bilal Date: Tue Jul 28 17:54:56 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() commit 28a289beaf226b30b1e6e7d7b1a2946fe2d6e852 upstream. rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: while (i < in_len) { ... if (i + 5 < in_len && in_ie[i] == 0xDD && ...) { ... break; } i += (in_ie[i + 1] + 2); /* to the next IE element */ } When the "i + 5 < in_len" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to "i += (in_ie[i + 1] + 2)", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie") added the "i + 5 < in_len" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-4-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a54fd1a44862d263df9f8bc17fca3620be31addb Author: Muhammad Bilal Date: Tue Jul 28 17:54:55 2026 +0500 staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() commit ff917923f4fb9c83717ba135ee47d7e4c1567bb7 upstream. rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman commit 34f51d196c43a42046d229de5e79025d5ca553ca Author: Muhammad Bilal Date: Tue Jul 28 17:54:54 2026 +0500 staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() commit 99aa998dec83ba180822f70e6d48a514fc81c20d upstream. rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260728125456.32359-2-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5117f236e9e30744338b425395d55913c4500897 Author: Jeffin Philip Date: Sun Aug 16 11:47:12 2026 +0530 usb: gadget: fix null pointer dereference in usb_put_function_instance() commit 6e74ac5c596fd246e37eadfc354567179ccbe9aa upstream. usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null. Reported-by: syzbot+fd6ef980cf1c722be639@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fd6ef980cf1c722be639 Fixes: 0062f6e56f70 ("usb: gadget: add a forward pointer from usb_function to its "instance"") Cc: stable Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260816061712.15547-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 64ec019bf9a8b12f53b9f2777d65aadb730b5a84 Author: Lovekesh Solanki Date: Tue Aug 25 22:43:43 2026 +0530 USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() commit dd0eed9e165b1a6292f49e622e3dd0b7d99b106d upstream. gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently. Cc: stable Reported-by: Eulgyu Kim Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/all/20260824113510.1141236-1-jjy600901@snu.ac.kr/ Signed-off-by: Lovekesh Solanki Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260825171343.459630-1-lovekeshsolanki00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 858576de6b2f5166b08dae803f0fd0766dcb3002 Author: Jeffin Philip Date: Sat Aug 15 11:10:06 2026 +0530 usb: gadget: f_midi: initialize work in f_midi_alloc() commit 7e07d3e4c389217d7d7171d80edf2e23ac70f1ea upstream. f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc(). Reported-by: syzbot+d5fa3d224505c8610702@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d5fa3d224505c8610702 Fixes: 8653d71ce376 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable Signed-off-by: Jeffin Philip Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260815054006.102325-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 49fab5e1bdb205c36c965d0e9677bc40d282d3a2 Author: Ivy Lopez Date: Sat Aug 15 18:54:33 2026 -0600 usb: gadget: f_midi2: fix use-after-free in string attribute show path commit fed0aa7c6eaedc6c0d4e362fc91724aa47be4a7b upstream. f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly. Reported-by: syzbot+2280f1cca5e6b0c353e4@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=2280f1cca5e6b0c353e4 Signed-off-by: Ivy Lopez Reviewed-by: Takashi Iwai Link: https://patch.msgid.link/20260816005434.34018-1-skunkolee@gmail.com Signed-off-by: Greg Kroah-Hartman commit b9b5b5df5b8dd3c1572ed267200276a44cc67d8e Author: Jeffin Philip Date: Tue Aug 18 09:29:04 2026 +0530 usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() commit 2c0f5ca48674a5b5f9fa4a9c3325aa48053af0bc upstream. Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic. Reported-by: syzbot+791be35f1fbcc85d06d7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=791be35f1fbcc85d06d7 Fixes: fe5a6c48fd95 ("usb: gadget: storage: get rid of fsg_num_buffers_validate()") Cc: stable Signed-off-by: Jeffin Philip Acked-by: Alan Stern Link: https://patch.msgid.link/20260818035904.10324-1-jeffinphilip14@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4079f19a0e1ce76f1e21a398f02aca150ceaaf61 Author: Aleksandr Nogikh Date: Wed Jul 29 09:04:54 2026 +0000 usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs commit f0efaf1872949e96d213c8e910fd9517f7d7c406 upstream. A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877 Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+bbb6dad313f4aaa8da6b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bbb6dad313f4aaa8da6b Link: https://syzkaller.appspot.com/ai_job?id=8ce30b1a-8cf7-4e38-bcf7-1f69e6f6313f Signed-off-by: Aleksandr Nogikh Reviewed-by: Takashi Iwai Closes: https://syzkaller.appspot.com/bug?extid=01a17afb30637396955e Link: https://patch.msgid.link/cafe65f4-e1bb-46a3-901d-732814b861b2@mail.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit bdaaf3074aedce8f1b173cc363d61cff5f6a585f Author: Jameson Thies Date: Tue Aug 25 23:45:45 2026 +0000 usb: typec: ucsi: displayport: Fix OOB altmode array index commit 04cec690b1fd9d1c4c314b91a10d8c68a3acfe18 upstream. The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman commit 87f7222587b48da89e7ed943bae37cd66f22298c Author: Sven Peter Date: Thu Aug 13 20:16:15 2026 +0200 usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x commit e24e3370356bddb65d667985a332b5f8aeeb5f97 upstream. The Intel VID status register is actually 9 bytes long and doesn't contain the raw VDOs but only the upper 16bits for device mode and enter mode. Shift those two fields into place and reconstruct the cable discover mode VDO from the data status register instead since it's not directly accessible. With this fixed now the correct VDOs are forwarded to the PHY and the to-be-submitted Thunderbolt/USB4 native host interface so that the right mode can be negotiated and the link actually comes up. Link: https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf Fixes: 0b31c978935f ("usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321x") Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x") Cc: stable Signed-off-by: Sven Peter Tested-by: Rafay Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260813-b4-tipd-vdo-fix-v1-1-70317f2cd554@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e5f9f36c5d610730fef74d2906cf5e16054de92c Author: Amit Sunil Dhamne Date: Thu Aug 27 21:16:17 2026 +0000 usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling commit cd3b9cea675bbfebc223f007dc2f4e79524fa54c upstream. When a sink detach occurs while waiting for TX send status, the old TCPM_SOURCING_VBUS event along with TCPM_VBUS_EVENT and TCPM_CC_EVENT can be queued in port->pd_events. Because TCPM_SOURCING_VBUS is evaluated after TCPM_VBUS_EVENT and TCPM_CC_EVENT in tcpm_pd_event_handler(), a stale TCPM_SOURCING_VBUS event can override the detach handling and incorrectly set port->vbus_source and port->vbus_present to true. Add a state guard to check that the port is either operating as a Source (tcpm_port_is_source(port)) or in a Fast Role Swap (FRS) state up to FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED before processing TCPM_SOURCING_VBUS. Otherwise, discard and log the event. Log snippet for error condition before fix: [72792.204955] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [72792.204960] sourcing vbus [72792.204962] VBUS on [72792.204970] AMS POWER_NEGOTIATION start [72792.204974] cc:=4 [72792.205319] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [72792.205325] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [72792.205332] PD TX, header: 0x11a1 [72792.216911] PD TX complete, status: 2 [72792.216957] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [72792.218005] VBUS off [72792.218013] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [72792.218020] VBUS VSAFE0V [72792.218024] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [rev3 POWER_NEGOTIATION] [72792.218458] CC1: 2 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected] [72792.218467] VBUS on --> VBUS left on [72792.218980] disable vbus discharge ret:0 [72792.235193] Start toggling After fix: [ 1195.291691] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS] [ 1195.291698] sourcing vbus [ 1195.291700] VBUS on [ 1195.291707] AMS POWER_NEGOTIATION start [ 1195.291710] cc:=4 [ 1195.291758] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION] [ 1195.291794] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION] [ 1195.291798] PD TX, header: 0x11a1 [ 1195.297056] PD TX complete, status: 2 [ 1195.297092] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION] [ 1195.297177] VBUS off [ 1195.297184] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.297227] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES, polarity 0, disconnected] [ 1195.307469] cc:=2 [ 1195.307544] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION] [ 1195.307555] Discarding sourcing vbus! Invalid state SRC_SEND_CAPABILITIES [ 1195.957636] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [delayed 650 ms] [ 1195.957732] disable vbus discharge ret:0 [ 1195.970196] Start toggling [ 1195.970468] VBUS off [ 1196.051637] VBUS off [ 1196.051642] VBUS VSAFE0V Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)") Cc: stable Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Amit Sunil Dhamne Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260827-sourcing-vbus-v1-1-9be1aca991a0@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 52d556f08547733948cc40b8b11e6b68dccee7b2 Author: Fan Wu Date: Wed Aug 19 16:14:48 2026 +0000 usb: typec: qcom-pmic: cancel reset_work on stop commit 7b0df6efd143f8085bdb68778a013a46f1349913 upstream. pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Konrad Dybcio Reviewed-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260819161448.76597-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit b5efa3b89395d2a753c3c9123ca617095ba70a4f Author: Fan Wu Date: Thu Aug 20 13:53:07 2026 +0000 usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails commit c9273c83885835dbd1e8835d5665dfb8503d65e0 upstream. cc_debounce_dwork can be queued before port_start() fails: tcpm_register_port() runs first, and its state machine may invoke set_cc() or start_toggling() from the TCPM worker. The error path then calls tcpm_unregister_port(), whose worker flush may queue the delayed work before devres frees pmic_typec_port. Disable and drain the delayed work directly at port_start()'s error exit. Do not use port_stop() for this path: its IRQs use IRQF_NO_AUTOEN and are enabled only after a successful port_start(). This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Suggested-by: Bryan O'Donoghue Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-3-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 1ab669c2b44e1040ddfab7cd7f717aad580d17aa Author: Fan Wu Date: Thu Aug 20 13:53:06 2026 +0000 usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop commit 263f7d61a4201cde16849b2d016251806e7418be upstream. cc_debounce_dwork is queued from the set_cc() and start_toggling() callbacks, which run from TCPM's kthread worker. port_stop() returns before tcpm_unregister_port() destroys that worker. Flushing the worker during unregister may therefore run a callback which queues the delayed work after port_stop() has returned. The delayed work can then run after devres has freed pmic_typec_port. Use disable_delayed_work_sync() in port_stop() to cancel a pending instance and prevent the TCPM callbacks from queueing another one. This issue was found by an in-house static analysis tool. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260820135307.153773-2-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit e2e424655e3125e32716ee72ca959b61a5d26958 Author: Marek Vasut Date: Mon Aug 17 20:22:39 2026 +0200 usb: typec: mux: Fix typec_switch_match() commit dea99705bc8fcda12590cfeeae6d2ba47a7ef572 upstream. The fwnode_typec_switch_get() sporadically returns NULL instead of an -EPROBE_DEFER for orientation-switch described in DT. This makes it impossible to discern whether the DT does describe an orientation-switch which did not probe yet, or whether the DT does not describe the switch. This happens with gpio-sbu-mux connected to an I2C GPIO expander. The class_find_device() on typec_switch_match() may return NULL in case the mux did not probe just yet early on boot. The sw_devs[] array can be empty on boot as well. If these two conditions occur, then the conditional if (to_typec_switch_dev(dev) == sw_devs[i]) evaluates to true and the match function returns NULL, which propagates to fwnode_typec_switch_get() which makes it look as if the orientation-switch was not described in DT. This is incorrect, because the mux driver will probe a bit later on, but at that point, the caller of fwnode_typec_switch_get() already got the NULL return value. The NULL return value also does not trigger IS_ERR(), therefore the caller driver interprets this as if the orientation-switch is not described in DT, and does not return -EPROBE_DEFER to try again, even if it should. Fix this by checking the class_find_device() return value, and return -EPROBE_DEFER if it is NULL right away. If the return value is not NULL, perform the deduplication test, and if that test passes, consider the return value to be already non-NULL. Fixes: a53b4f9c51a9 ("usb: typec: mux: avoid duplicated orientation switches") Cc: stable Signed-off-by: Marek Vasut Reviewed-by: Sebastian Reichel Tested-by: Jens Glathe Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260817182302.146546-1-marex@nabladev.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 312a11d6f7392633d0d8a9841ec4b32808f3799d Author: Marek Vasut Date: Sat Aug 22 09:24:58 2026 +0200 usb: typec: mux: avoid duplicated mux switches commit d50b6442bef66abbe4694f918f8ad013f81d75cf upstream. Some devices use combo PHYs (i.e. USB3 + DisplayPort), which also handle the lane muxing. These PHYs are referenced twice from the USB-C connector (USB super-speed lines and SBU/AUX lines) resulting in the mux being configured twice. Avoid this by dropping duplicates. This is a re-application of b145c3f29d62 ("usb: typec: mux: avoid duplicated mux switches"), with fix derived from usb: typec: mux: Fix typec_switch_match() . Fixes: f576c75f95a5 ("Revert "usb: typec: mux: avoid duplicated mux switches"") Cc: stable Signed-off-by: Sebastian Reichel Co-developed-by: Sebastian Reichel Signed-off-by: Marek Vasut Tested-by: Jens Glathe Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260822072556.490594-1-marex@nabladev.com Signed-off-by: Greg Kroah-Hartman commit df7cd3908e07503fa7e9737dacf44208530e58d9 Author: Chang Wu Date: Wed Aug 19 23:20:27 2026 +0800 usb: typec: hd3ss3220: track VBUS enable state per consumer commit c9a48db776d7184981630ecc01a3ad30a8f7dc24 upstream. regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references. Fixes: b3f9d6e491fd ("usb: typec: hd3ss3220: Check if regulator needs to be switched") Cc: stable Link: https://github.com/qualcomm-linux/kernel/issues/472 Signed-off-by: Chang Wu Reviewed-by: Heikki Krogerus Tested-by: Jan Remmet Reviewed-by: Krishna Kurapati Link: https://patch.msgid.link/20260819152027.90994-1-kunjinkao.jp@gmail.com Signed-off-by: Greg Kroah-Hartman commit cae9dbba6adae21a04a3bd045e07b489847ff2c6 Author: Myeonghun Pak Date: Mon Jul 27 21:34:14 2026 +0900 usb: storage: realtek_cr: fix use-after-free on disconnect commit 4ffee1aebb0c0ffcda9faffd17834ea9b00d42cc upstream. realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis. Fixes: e931830bb877 ("Realtek cr: Add autosuspend function.") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260727123414.44700-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit e01408ee52fe5cb2d0b43f47f359336af2b6c316 Author: Elson Serrao Date: Thu Aug 13 08:14:56 2026 -0700 usb: dwc3: clear forceRM when issuing EndTransfer commit b58e6200450d350314db0ecda7d6d1bde3281e80 upstream. The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations. Fixes: 1e43c86d84fb ("usb: dwc3: core: Add DWC31 version 2.00a controller") Cc: stable Signed-off-by: Elson Serrao Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260813151456.867008-1-elson.serrao@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit d8cfb7f630eb752acd8da4353dfe22243d8dd3ca Author: Radhey Shyam Pandey Date: Wed Aug 19 23:51:58 2026 +0530 usb: dwc3: google: Initialise probe properties with DWC3_DEFAULT_PROPERTIES commit 6b2a674fcc953378e5e750d47a888bbe51229de5 upstream. dwc3_google_probe() zero initialises struct dwc3_probe_data and never assigns its properties member. The unspecified state of gsbuscfg0_reqinfo is encoded as DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED (0xffffffff), not as zero, so dwc3_get_software_properties() reads the zeroed field as a value the glue explicitly requested: if (properties->gsbuscfg0_reqinfo != DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) { dwc->gsbuscfg0_reqinfo = properties->gsbuscfg0_reqinfo; return; } Two things follow. dwc3_config_soc_bus() programs GSBUSCFG0.REQINFO with zero on hardware that never asked for it, and the early return skips the walk over the parent devices, so a swnode or device tree supplied snps,gsbuscfg0-reqinfo would be ignored. Assign DWC3_DEFAULT_PROPERTIES so the unset fields carry their unspecified sentinels and the controller is left alone. Fixes: 8995a37371bf ("usb: dwc3: Add Google Tensor SoC DWC3 glue driver") Cc: stable Signed-off-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260819182158.1351869-1-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 619aae11b85f9dcbd14da82acfd0b3356cf18700 Author: Andy Shevchenko Date: Mon Aug 17 18:11:30 2026 +0200 usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() commit 9f6f095beec82a80daa666a3b2186a5b95841e9a upstream. GCC (Debian 14.2.0-19) is not happy about the buffer size: drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=] Bump the size to get it enough for all possible values. Note, although cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize this and complains about the buffer size. Also note, the existing comment is wrong as size 8 for the whole buffer doesn't cover 100 mil numbers, hence drop it altogether. Fixes: b27c08c953e9 ("usb: gadget: f_mass_storage: create lun creation helpers for use in fsg_common_init") Cc: stable Acked-by: Alan Stern Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260817161239.1448582-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2571029a92ee7746d1e5b852a6b8daeb8e63cd63 Author: Pawel Laszczak Date: Thu Aug 20 12:45:31 2026 +0200 usb: cdnsp: fix wakeup from S3 after controller context loss commit eae6460f617382044c5afe5ef202f4d8b2c099b5 upstream. CDNSP controller may lose its runtime register programming across S3 suspend/resume, depending on SoC power domain configuration. After resume the operational and interrupter registers may contain reset values, which prevents the gadget side from recovering correctly and breaks wakeup from S3. Fix this by detecting whether the controller lost its register context after resume and handling both cases: - If context was lost (CFG_3XPORT_U1_PIPE_CLK_GATE_EN set or power lost): reset the controller and reprogram the state required for normal operation, including the command ring, DCBAA pointer, doorbell base, event ring, ERST base/size and event ring dequeue pointer. - If context was retained: restart the controller directly without reprogramming registers. Issue a wakeup if the link was in U3 before suspend. Move the basic controller register programming out of the one-time memory initialization path and make it reusable from the resume path. Also separate ring allocation from ring initialization so that rings can be reinitialized without reallocating DMA memory. Always perform the full suspend sequence regardless of the current link state. Previously, if the device was already in U3, the suspend callback returned early without stopping the controller, which could lead to commands being issued on a disabled slot during resume. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://patch.msgid.link/20260820-suspend_resume_fix-v3-1-5a713098b977@cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 996c319b8bd5ada1f62daae0d331d0b23e0f2117 Author: Liu Qi Date: Fri Aug 21 17:04:16 2026 +0800 usb-storage: ene_ub6250: fix race between scan work and probe commit 445fc368c6bc73eff0aeb3818cf5f355facfbb16 upstream. ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path. Reported-by: syzbot+22ea20ef3afb6785b122@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=22ea20ef3afb6785b122 Assisted-by: Qwen:Qwen3.6 Signed-off-by: Liu Qi Acked-by: Alan Stern Link: https://patch.msgid.link/20260821090416.1247127-1-liuqi@longcheer.com Signed-off-by: Greg Kroah-Hartman commit 1618257cb0aba4ce342ae8c0228368c24161f5fb Author: Shuangpeng Bai Date: Mon Jul 6 16:24:06 2026 -0400 media: usbtv: keep device alive while ALSA card exists commit fc530fe168bb2b745a93f553ad21fc25fd9cba3d upstream. The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card. Closes: https://lore.kernel.org/r/178144969601.60470.4852887710381872458@gmail.com Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d2c87eadcec4e2aa8b615d1fc7fc3bcb9b53ec7d Author: Stephan Gerhold Date: Mon Jul 6 17:02:12 2026 +0200 clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset commit c99bc8e83848358bd4a0436e4bdae5b7919babb2 upstream. To conform to the specifications of the USB PHY, the reset signal should be asserted for at least 10us. Guarantee that by increasing the delay for the USB2_HS_PHY_ONLY_BCR reset control similar to commit dcc6c9fb7128 ("clk: qcom: gcc-msm8909: Increase delay for USB PHY reset"). Cc: stable@vger.kernel.org Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver") Reviewed-by: Konrad Dybcio Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20260706-qcom-clk-mdm9607-fixes-v2-5-745565101869@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 9d81885d97cba7796d1f8edc88f2499c8296f5b9 Author: HyeongJun An Date: Tue Sep 1 18:04:09 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() commit e4637ce34607f1733a34a57294966d26b263e626 upstream. The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e22428f0c038c23109c0383a235aa607b0cd4c95 Author: Griffin Kroah-Hartman Date: Wed Aug 19 12:04:25 2026 +0200 usb: image: mdc800: change kmalloc() to kzalloc() commit 2430eb81e44111b30eeb5273bbcf8b24ca517ef9 upstream. Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify() Assisted-by: gkh_clanker_t1000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260819-usb_misc_random-v1-1-43a0dcee3a32@kroah.com Signed-off-by: Greg Kroah-Hartman commit b08c3d5ee7feadd821208f7c2c1ec02a16ce5878 Author: Hari Mishal Date: Sat Aug 22 16:57:51 2026 +0200 drm/amd/display: fix division by zero in get_estimated_bw() commit f63de9054da858d57054474c32464106f8375e0d upstream. get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. Fixes: 8e5cfe547bf3 ("drm/amd/display: upstream link_dp_dpia_bw.c") Reviewed-by: Alex Hung Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Signed-off-by: Alex Deucher (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6fedb2eaff77554ca7a0deffd2e8bc0d6e8b38b0 Author: Chuck Lever Date: Mon Sep 7 16:18:48 2026 -0400 NFSD: Prevent client use-after-free during blocked-lock reaping [ Upstream commit 9026932ac8be4d0ae01db47f23619a98cc57b671 ] A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle. Fixes: 7919d0a27f1e ("nfsd: add a LRU list for blocked locks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-7-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e57a9ed34ea8c17e831de59b8f1a6b2d80d347a1 Author: Chuck Lever Date: Mon Sep 7 16:18:44 2026 -0400 NFSD: Prevent client use-after-free during close_lru reaping [ Upstream commit 2330b788d732f43668b965b3105b37ceb276dfea ] An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat. Fixes: 217526e7ecc9 ("nfsd: protect the close_lru list and oo_last_closed_stid with client_lock") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-8-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b75ecd5122088750e53891c0a6d3a1f4028f6431 Author: Chuck Lever Date: Mon Sep 7 16:18:43 2026 -0400 NFSD: Consolidate the revocation-path client unpin [ Upstream commit 3308cf3f11ed23c79f9f3f90b34bbbad3e3a6ea9 ] The client use-after-free fixes in the state-revocation paths left four open-coded copies of one idiom: drop a cl_rpc_users pin without renewing the client's lease, waking force_expire_client() when the last pin drops on a client it is tearing down. The accompanying "do not renew" rationale was documented at only one of the four sites. put_client_renew_locked() and put_client_renew() already carry the same pin-drop logic, but they renew a non-expired client's lease and so would resurrect the client whose state is being revoked. Factor the common pin-drop into __put_client_locked(), parameterized by whether to renew. The renew helpers pass true; the new put_client_no_renew_locked() and put_client_no_renew() pass false and carry the revocation paths, which must not revive the client they are tearing down. No change in behavior. Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-6-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2330b788d732 ("NFSD: Prevent client use-after-free during close_lru reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c05ae58fe06ce2ac34312f649e71c3596bdde358 Author: Chuck Lever Date: Mon Sep 7 16:18:41 2026 -0400 NFSD: Prevent client use-after-free during export state revocation [ Upstream commit 2108de53568a64936a0da3e04d85c35df98d3fb6 ] nfsd4_revoke_export_states() has the same use-after-free as nfsd4_revoke_states(): it drops nn->client_lock across revoke_one_stid() and the following read of clp->cl_minorversion, but the stateid reference it holds does not pin the client. A teardown racing the dropped lock can free the client while revoke_one_stid() still dereferences it. exportfs -u drives this path through NFSD_CMD_UNLOCK_EXPORT, so an administrator removing an export can race a client expiry. Skip a client that is already expiring and otherwise pin it with cl_rpc_users under client_lock before dropping the lock, matching nfsd4_revoke_states(). Fixes: 2eac189bb059 ("NFSD: Add NFSD_CMD_UNLOCK_EXPORT netlink command") Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-4-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2330b788d732 ("NFSD: Prevent client use-after-free during close_lru reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0146467a2fce845cb6629979c3e9c58dd3d3a6a3 Author: Chuck Lever Date: Sun Sep 6 09:28:46 2026 -0400 NFSD: Guard admin state-revocation walks with NFSD_NET_UP [ Upstream commit 2f3e6638aebc0ab8afb8b4e9816ea9a1cad85378 ] Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix. Reported-by: XIAO WU Fixes: 1ac3629bf012 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260621162551.2469460-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f7e7fcd82f574f49f708ff5d102e881cc9f05521 Author: Chuck Lever Date: Sun Sep 6 09:28:45 2026 -0400 NFSD: Annotate caller preconditions for the state-table walkers [ Upstream commit 5f367f05481d56be90f8c13eee4cb421cd7af2d8 ] The state-table walkers now assert nfsd_mutex with lockdep_assert_held() and document the nfsd_mutex / nn->nfsd_serv precondition in a Context: kdoc section, so the next caller added to this path cannot silently reintroduce the same use-after-free. Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260613-unlock-filesystem-uaf-v1-3-462b9bec8c84@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2f3e6638aebc ("NFSD: Guard admin state-revocation walks with NFSD_NET_UP") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2640cc26ed0dd1bf6ec2f6852a60e494093db3e5 Author: Sean Christopherson Date: Mon Aug 31 18:20:10 2026 -0400 KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped [ Upstream commit d1a3c216233413f57f5341a9b878b7e2dde7e785 ] Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99a64d198000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 13eb001067 P4D 13eb001067 PUD 78d1d1063 PMD 1184e0063 PTE 800000078d198163 SEV-SNP: PFN 0x78d198, RMP entry: [0x6030000000144001 - 0x000000000000000f] Oops: Oops: 0003 [#1] SMP CPU: 3 UID: 0 PID: 31407 Comm: highlanderd_hea Tainted: G U W O Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:prep_new_page+0x67/0x220 Call Trace: get_page_from_freelist+0x1c40/0x1c70 __alloc_frozen_pages_noprof+0xca/0x1f0 alloc_pages_mpol+0x10b/0x1b0 alloc_pages_noprof+0x81/0x90 pte_alloc_one+0x1b/0xd0 do_pte_missing+0xdf/0x1020 handle_mm_fault+0x7c7/0xb20 do_user_addr_fault+0x268/0x6b0 exc_page_fault+0x67/0xa0 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x4a6b1e gsmi: Log Shutdown Reason 0x03 CR2: ffff99a64d198000 ---[ end trace 0000000000000000 ]--- RIP: 0010:prep_new_page+0x67/0x220 Drop the pseudo-TODO comment about needing to pin the page if guest_memfd every supports migration, as integrating with invalidations events means KVM will Just Work if/when page migration is ever supported (assuming SNP hardware supports migrating VMSA pages). Note #3, invalidate() and invalidate_range() have _completely_ different semantics; the new invalidate_range() is a true invalidation, whereas the existing invalidate() is really a "make shared" operation. Ignore the confusing naming and poor Kconfig bundling for the moment to minimize the delta for LTS kernels, the mess will be cleaned up shortly. Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Cc: Tom Lendacky Cc: Michael Roth Cc: Jörg Rödel Cc: Fuad Tabba Cc: Ackerley Tng Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-11-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 98bcc7034db1eaf09435e37fe713429325ee5b71 Author: Sean Christopherson Date: Mon Aug 31 18:20:09 2026 -0400 KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot [ Upstream commit db095727ff5739f4f46ee641ee6ef450032886db ] Manually invoke the front half and back half of the "zap all fast" flow when invalidating a memslot so that mmu_lock is acquired at function scope in kvm_arch_flush_shadow_memslot(). This will allow putting more code inside the critical section without having to take mmu_lock twice in quick succession. Opportunistically open code checking whether or not to do the fast zap, to discourage removing the local "zap_all" in a future cleanup, i.e. to ensure the SLOT_ZAP_ALL quirk is queried exactly once. Processing the front half but not the back half of the fast zap (if SLOT_ZAP_ALL were disabled concurrently) would result in KVM unnecessarily keeping invalid TDP MMU roots until the VM is destroyed. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-10-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: d1a3c2162334 ("KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 689c1b2da4779f4d3ad1696f28d45dd690b72ead Author: Sean Christopherson Date: Mon Aug 31 18:20:08 2026 -0400 KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves [ Upstream commit b27622c4eeb125814081baaefe9175191be5b94d ] Split kvm_mmu_zap_all_fast() into a "front half" and a "back half", where the front half is everything that runs with mmu_lock held for write, and the back half is the code that runs outside of mmu_lock. This will allow putting more code inside kvm_arch_flush_shadow_memslot()'s critical section without having to take mmu_lock twice in quick succession. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-9-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: d1a3c2162334 ("KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00388b7b718a11efab37edf5a0fbb0ff3d5a388e Author: Sean Christopherson Date: Mon Aug 31 18:20:07 2026 -0400 KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() [ Upstream commit 06d38eaa78fdac1cc889f261fa420eba8e9caa1a ] Fold kvm_mmu_zap_memslot() into its sole caller so that its GFN range structure can be used to trigger guest_memfd invalidations regardless of whether KVM will do a partial or full zap of the MMU. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-8-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: d1a3c2162334 ("KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7a90d99686e5afee2134ac11b300a712629e6bbb Author: Rong Zhang Date: Mon Sep 7 21:38:23 2026 -0400 ACPI: battery: Protect all properties with a separated mutex [ Upstream commit 9e409f1dff7841634e4b101111d6427f979c0aac ] The acpi_battery_get_property() callback calls acpi_battery_get_state() without any lock held. On some devices, it happens that the property cache has expired before a uevent reaches userspace, triggering simultaneous attempts to evaluate _BST. See [1] for an analysis to sysrq stacktraces on one of the these devices. In a few cases, including when the AML is sleeping or acquiring a mutex, ACPICA drops the namespace and interpreter locks and allows the evaluation of _BST to start while another task is still evaluating it. This could somehow confuse the interpreter and lead to chaos in AML mutexes on some devices, see [2] for an example. Not holding the lock is also prone to race conditions, for example: CPU0 | CPU1 acpi_battery_get_property() | acpi_battery_get_state() | [update_time expired] | extract_package() | acpi_battery_get_property() battery->update_time = jiffies | acpi_battery_get_state() kfree() | [up to date] | [read capacity_now] [fix capacity_now due to quirk] | where CPU1 gets raw capacity_now before CPU0 fixes it to a meaningful value. The existing mutex update_lock is not applicapable for acpi_battery_get_property(), as some code path could call or wait for acpi_battery_get_property() while holding update_lock. Therefore, introduce a mutex called property_lock to protect all accesses to battery properties, so that acpi_battery_get_property() can take the advantage of the mutex and synchronize itself. With the mutex, acpi_battery_get_state() are synchronized in all code paths calling it, and its cache mechanism can always clamp the frequency of _BST evaluations according to cache_time. The helper function acpi_battery_handle_discharging() for quirky devices has to be inlined due to the change, as the mutex must be unlocked before calling the expensive power_supply_is_system_supplied() helper function. Fixes: 86bfd21a0baf ("ACPI: battery: Drop redundant locking") Reported-by: Rick Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221065#c85 [1] Reported-by: Avraham Hollander Tested-by: Avraham Hollander Closes: https://lore.kernel.org/linux-acpi/CAP1mzZReJCn6df5DwEPu-JCQUyr=Pu1cg5xKCMttWZkHCQtVmQ@mail.gmail.com [2] Signed-off-by: Rong Zhang Cc: All applicable Link: https://patch.msgid.link/20260809-b4-acpi-battery-notification-v5-1-788d54fa2e35@rong.moe Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7a6af8e5176d77ee9b454e33a33b83e73d3d596 Author: Rong Zhang Date: Mon Sep 7 21:38:22 2026 -0400 ACPI: battery: Use kstrtoul() over sscanf("%lu\n") [ Upstream commit 57346c4d78d38b357dbe9ef16d3f63bf4610c039 ] It is more preferred to use kstrto*() to parse a single number. The function family properly returns an errno on error and is the correct mechanism to parse data from sysfs. The number base is set to 10 in order not to break the ABI. Tested-by: Avraham Hollander Signed-off-by: Rong Zhang Link: https://patch.msgid.link/20260718-b4-acpi-battery-notification-v4-2-599c8ed1072f@rong.moe Signed-off-by: Rafael J. Wysocki Stable-dep-of: 9e409f1dff78 ("ACPI: battery: Protect all properties with a separated mutex") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d044d796e2a369c6051c7e83dce88c7baa2494d4 Author: Doruk Tan Ozturk Date: Mon Sep 7 12:04:36 2026 -0400 HID: sony: clean up device list on probe failure [ Upstream commit 7c65699a3a311198a07659a614fe64d45924839e ] sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths. Fixes: 4f967f6d7374 ("HID: sony: Fix memory issue when connecting device using both Bluetooth and USB") Cc: stable@vger.kernel.org Reported-by: Doruk Tan Ozturk Link: https://lore.kernel.org/linux-input/20260724143925.007D61F00A3A@smtp.kernel.org/ Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5a4ed79030efb32717fa0a0aa601d76a9afa690f Author: Rosalie Wanders Date: Mon Sep 7 12:04:35 2026 -0400 HID: sony: use guard() and scoped_guard() [ Upstream commit da4f817ad273bca9aefd8636d347a8c101069111 ] This replaces the spin_lock_irqsave() and spin_unlock_irqrestore() calls with the RAII guard() and scoped_guard(). Signed-off-by: Rosalie Wanders Signed-off-by: Jiri Kosina Stable-dep-of: 7c65699a3a31 ("HID: sony: clean up device list on probe failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b467c68803d7c7e82678289e598afd44faa6101 Author: Sam Edwards Date: Sun Sep 6 13:06:18 2026 -0400 ceph: properly decrypt filenames in vmalloc() buffers [ Upstream commit e939fc6a7bd969a58a150b7f188c1047138403e3 ] The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new "tname must never come from vmalloc()" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead. Cc: stable@vger.kernel.org # 888d33b208bd: ceph: pass fscrypt `tname` buffers directly Cc: stable@vger.kernel.org Fixes: 457117f077c6 ("ceph: add helpers for converting names for userland presentation") Closes: https://lore.kernel.org/ceph-devel/20260415034020.11530-1-CFSworks@gmail.com/ Signed-off-by: Sam Edwards Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov [ adapted raw tname buffer access to the existing struct fscrypt_str interface ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 052b6b2d5fe97547bd2cdb73fa894f6cfea68b11 Author: David Carlier Date: Fri Sep 4 14:49:50 2026 -0400 zram: fix slot lock bit position on big-endian 64-bit [ Upstream commit a8b5875741d416703e19ad8eeac6fce8a12bd6e4 ] The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever. Shift the lock bit into the flags half of the word on big-endian 64-bit. Link: https://lore.kernel.org/20260810202241.2436603-1-devnexen@gmail.com Fixes: 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking") Signed-off-by: David Carlier Reviewed-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 342d140c82251b3a6266f1677d19ff8bfc0c267f Author: Sebastian Andrzej Siewior Date: Fri Sep 4 14:49:49 2026 -0400 zram: move lockmap to be per-zram instead per table [ Upstream commit dbb7ba9c7fa81a48ed2a108ad684cf3655f3ae4b ] Patch series "zram: lockmap tweaks". This patch (of 2): The zram object contains an array zram_table_entry. Each one has a `lock' variable and each has a matching struct lockdep_map. This mimics a struct mutex. It uses always the same key for all lockdep_map instances. This makes it look like the same lock to lockdep. Therefore it could be reduced to have one lockdep_map per struct zram. Use only one struct lockdep_map per struct zram. Link: https://lore.kernel.org/20260714141300.3945672-1-bigeasy@linutronix.de Link: https://lore.kernel.org/20260714141300.3945672-2-bigeasy@linutronix.de Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Cc: Jens Axboe Cc: Minchan Kim Signed-off-by: Andrew Morton Stable-dep-of: a8b5875741d4 ("zram: fix slot lock bit position on big-endian 64-bit") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a2fb2d12b87b43724230abb52a1440617c7b6cc Author: Neill Kapron Date: Fri Sep 4 10:25:06 2026 -0400 usb: gadget: f_fs: Fix Use-After-Free in AIO error path [ Upstream commit e78dcb1f7ec271449c54984dc90c62a5ba272de7 ] In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers. Fixes: de2080d41b5d ("gadget/function/f_fs.c: close leaks") Cc: stable@vger.kernel.org Reported-by: Xingyu Jin Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260724235100.106011-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7411de0ce3b45286de1de82526795658ea6eacb0 Author: Gabriel Prostitis Date: Fri Sep 4 10:25:05 2026 -0400 USB: gadget: ffs: fix mm lifetime handling [ Upstream commit 5eb5c72c72fef76cb765ef1669b62b6a3ba1bfc8 ] io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion. Reported-by: Gabriel Prostitis Signed-off-by: Gabriel Prostitis Link: https://patch.msgid.link/20260601-mm-uaf-fix-v2-1-3c942a707bce@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e78dcb1f7ec2 ("usb: gadget: f_fs: Fix Use-After-Free in AIO error path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 68a069b407303e71db371df85036101e8ff59280 Author: Brendan Jackman Date: Fri Sep 4 09:43:54 2026 -0400 mm/page_alloc: don't spin_trylock() in NMI on UP [ Upstream commit 3105ae628fb785d48b49256468be4f21a7b3cfc0 ] Patch series "mm/page_alloc: fixes for free_pages_nolock() on RT/UP". Pre-existing bugs found by Sashiko during review of this other series: https://lore.kernel.org/all/20260703-alloc-trylock-v5-0-c87b714e19d3@google.com/ I have not reproduced these bugs, and I suspect there is no real-world user that is affected by them. This patch (of 2): As noted in can_spin_trylock(), using this is unsafe in this context. commit 620b46ed6ae17 ("mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP") fixed this on the alloc side but missed the free side. Impact: If BPF programs using these features in NMI (probably tracing) are present on non-SMP builds this might crash the kernel and is probably exploitable by local attackers for privilege escalation. Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-0-fadc49952dda@google.com Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-1-fadc49952dda@google.com Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Signed-off-by: Brendan Jackman Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260703-alloc-trylock-v5-0-c87b714e19d3%40google.com?part=18 Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Oracle) Cc: Brendan Jackman Cc: Alexei Starovoitov Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 348c3db4f1520d36764ac8cae2492f50599714f6 Author: Linus Torvalds Date: Thu Aug 20 20:12:39 2026 -0700 drm/xe: Don't hand out the flat CCS storage as usable VRAM commit 818bebeb63dd6bf5f4e07e145f6cdbace520a34c upstream. get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K. Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means "usable memory ends here" upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware. The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's pool. Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM's level-3 page table landed on that page on every cold boot. It lost the entry covering the compositor's batch-buffer heap, so the compositor's first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine. Restarting gdm cleared it because the next VM's page tables were allocated somewhere else. Round down instead, to the page size the allocator works in. On this machine that excludes exactly one page. Reading the reserved page afterwards shows what had been writing it: [369] 0xcccc000000000000 [371] 0xcc77000000000000 [373] 0xcccc000000000000 [375] 0xcc77000000000000 compression metadata, two bytes per sixteen, sitting where the driver used to hand out memory. The assertion that should have caught this compares the offset against GSMBASE - ccs_size for equality. That value is 128K aligned, so it agrees with the rounded-up offset precisely when the base is not aligned - the check cannot fail in the case it exists to catch, and is compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one that can fail: CCS storage must not run into GSM. [ And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work. I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it. I suspect those things have been trained by people who may not be quite as stubborn as I am. But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above. This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. - Linus ] Fixes: 37173392741c ("drm/xe/vram: fix ccs offset calculation") Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a84f3db72561c4d9281c5ff721ce46b9ffa7f30e Author: HE WEI（ギカク） Date: Wed Jun 10 09:29:29 2026 +0900 fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() commit 7c4841e2a62794a3bab7c1ff0540580f387e377f upstream. ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: HE WEI（ギカク） Signed-off-by: HE WEI（ギカク） Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit bab5a851e44a3601d31f2aa8043f385bb50ac5d9 Author: Norbert Szetei Date: Fri Sep 4 10:57:44 2026 +0200 net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() [ Upstream commit 8ece906150128d5ec2462aabcc978c568433eca4 ] skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers. Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors") Cc: stable@vger.kernel.org Suggested-by: Ilya Maximets Signed-off-by: Norbert Szetei Reviewed-by: Ilya Maximets Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/6E3A780D-FB87-421F-9964-B1D457D7D106@doyensec.com Signed-off-by: Paolo Abeni [ 7.2 and earlier do not have the put_page() call on the error path ] Signed-off-by: Ilya Maximets Signed-off-by: Sasha Levin