summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-28tracing: Use seq_buf for string concatenationWoradorn Laodhanadhaworn
In preparation for removing the strlcat API[1], replace the string concatenation logic with a struct seq_buf, which tracks the current position and the remaining space internally. Use seq_buf_str() to NUL-terminate before passing to early_enable_events(). Link: https://github.com/KSPP/linux/issues/370 [1] Link: https://patch.msgid.link/20260713045249.69942-1-woradorn.laon@gmail.com Signed-off-by: Woradorn Laodhanadhaworn <woradorn.laon@gmail.com> [ Moved placement of #include <linux/seq_buf.h> ] Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Use strscpy() instead of strcpy() in trace_sched_switchPo-Sheng Lin
Replace strcpy() with strscpy() in __trace_find_cmdline() for consistency with the existing strscpy() call in the same function, and to avoid potential buffer overflow as flagged by the Kernel Self Protection Project. Link: https://patch.msgid.link/20260705173648.5418-1-posheng.lin.tw@gmail.com Signed-off-by: Po-Sheng Lin <posheng.lin.tw@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Warn when an event dereferences a pointer in TP_printk()Steven Rostedt
Currently on boot up and when modules are loaded, the trace event infrastructure will examine the TP_printk's of every event looking to see if it dereferences pointers on the ring buffer via printk formats like "%pB" and such. What it doesn't do is check if the arguments themselves do a dereference from a pointer. This was brought with a fix[1] to the fsl_edma event that had in the arguments of the TP_printk(): "__entry->edma->membase" The __entry->edma is a pointer saved in the ring buffer. The dereference from TP_printk() happens when the user reads the "trace" file which can be seconds, minutes, hours, days, weeks, or even months later! There is no guarantee that the __entry->edma pointer will still be pointing to what it was when it was recorded, and could crash the kernel when a user reads the event. Add logic to the test_event_printk() that also checks for this case and warn if the event dereferences a pointer from the ring buffer. [1] https://lore.kernel.org/all/20260630200022.1826420-1-martin@kaiser.cx/ Link: https://patch.msgid.link/20260630184836.74d477b6@gandalf.local.home Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28samples/ftrace: Prevent division by zero when nr_function_calls is zeroSamuel Moelius
The ftrace-ops sample exposes nr_function_calls as a module parameter and uses it as the divisor when printing the measured time per call. Loading the module with nr_function_calls=0 skips the benchmark loop and then divides the elapsed time by zero, crashing the kernel during sample module initialization. Keep accepting the parameter value, but report -1LL as the per-call duration when the call count is zero instead of dividing by it. Link: https://patch.msgid.link/20260629152616.107080.e19bfbed249c.ftrace-ops-zero-function-calls-div0@trailofbits.com Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Reject invalid preemptirq_delay_test CPU affinitySamuel Moelius
preemptirq_delay_test accepts cpu_affinity as a module parameter and, when it is non-negative, writes that CPU directly into a temporary cpumask from the worker thread. Values outside nr_cpu_ids can set a bit outside the allocated cpumask before the test reports a normal affinity error. Validate the requested CPU in preemptirq_delay_run() before setting it in the temporary cpumask. Invalid affinity requests are reported by the test thread and skipped before cpumask_set_cpu() can touch an out-of-range bit. Link: https://patch.msgid.link/20260628131021.2208632.6a5c6c959813.preemptirq-delay-test-invalid-cpu-affinity@trailofbits.com Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28fgraph: Use trace_seq_putc() in print_graph_return()Markus Elfring
A single closing curly bracket should be put into a trace sequence buffer. Thus use the corresponding function “trace_seq_putc”. The source code was transformed by using the Coccinelle software. Link: https://patch.msgid.link/d215fa89-9a62-4067-86ec-833290f35c80@web.de Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing/user_events: Replace a seq_printf() call by seq_puts() in ↵Markus Elfring
user_seq_show() A single string should be put into a sequence within a loop. Thus use the corresponding function “seq_puts” for one selected call. The source code was transformed by using the Coccinelle software. Link: https://patch.msgid.link/1cf327f0-49a6-477f-a06f-2b22a167db24@web.de Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing/user_events: Use seq_putc() in two functionsMarkus Elfring
Single characters should be put into a sequence. Thus use the corresponding function “seq_putc” for selected calls. The source code was transformed by using the Coccinelle software. Link: https://patch.msgid.link/6bcaa4da-05c6-4097-90f5-3969f8a1dfbc@web.de Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Bound histogram expression strings with seq_bufPengpeng Hou
expr_str() allocates a fixed MAX_FILTER_STR_VAL buffer and then builds expression names with a series of raw strcat() appends. Nested operands, constants, field flags, and generated field names can push the rendered string past that fixed limit before the name is attached to the hist field. Build expression strings with seq_buf and return -E2BIG when the rendered name would exceed MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while replacing the raw append logic with bounded construction. Link: https://patch.msgid.link/20260611055945.22348-4-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Return ERR_PTR() from expr_str()Pengpeng Hou
expr_str() currently reports all failure cases as NULL, so callers cannot distinguish invalid recursion depth from allocation failure or later string construction errors. Return ERR_PTR()-encoded errors from expr_str() and make parse_unary() and parse_expr() propagate them. Clear expr->name before destroying the hist field so the error pointer is not freed as a string. Link: https://patch.msgid.link/20260611055945.22348-3-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Use __free() for expr_str() bufferPengpeng Hou
expr_str() allocates a temporary expression buffer and manually frees it on some error paths. Convert the buffer to __free(kfree) and return it with return_ptr() on success. This keeps ownership handling separate from the later ERR_PTR() conversion and string-bound change. Link: https://patch.msgid.link/20260611055945.22348-2-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28kernel/trace/trace_printk: Use kstrdup() instead of kmalloc() and strcpy()David Laight
Link: https://patch.msgid.link/20260606202633.5018-34-david.laight.linux@gmail.com Signed-off-by: David Laight <david.laight.linux@gmail.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Point constant hist field type to string literalYu Peng
The HIST_FIELD_FL_CONST path uses the fixed "u64" type string. Point hist_field->type directly to the string literal, matching the HIST_FIELD_FL_HITCOUNT path. The release path already uses kfree_const(), so no duplication is needed. Link: https://patch.msgid.link/20260527023450.2137639-1-pengyu@kylinos.cn Signed-off-by: Yu Peng <pengyu@kylinos.cn> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28selftests/bpf: Add test for tracepoint btf_ids tracefs fileMykyta Yatsenko
Read events/bpf_testmod/bpf_testmod_test_read/btf_ids and verify the exported FUNC_PROTO matches the testmod tracepoint signature (__data, struct task_struct *task, struct bpf_testmod_test_read_ctx *ctx) and the record struct trace_event_raw_bpf_testmod_test_read carries the fields declared by TP_STRUCT__entry. Use the testmod tracepoint so the test exercises the module/split-BTF path (btf_relocate_id) rather than vmlinux only, and falls back from /sys/kernel/tracing to /sys/kernel/debug/tracing when tracefs is not mounted at the new location. Link: https://patch.msgid.link/20260518-generic_tracepoint-v2-3-b755a5cf67bb@meta.com Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28tracing: Expose tracepoint BTF ids via tracefsMykyta Yatsenko
Add events/<sys>/<event>/btf_ids, a per-template file that exposes the BTF ids resolve_btfids fills in for each tracepoint: btf_obj_id BTF object owning the ids below raw_btf_id FUNC_PROTO of __bpf_trace_<call> (named args), consumed by raw_tp / tp_btf BPF programs tp_btf_id trace_event_raw_<call> ring-buffer record, consumed by classic BPF_PROG_TYPE_TRACEPOINT programs DECLARE_EVENT_CLASS now emits a 2-entry BTF_ID_LIST (FUNC __bpf_trace_* and STRUCT trace_event_raw_*) and stores the pointer in trace_event_class. Per-syscall events under syscalls/ share the handcrafted classes event_class_syscall_{enter,exit} instead of going through DECLARE_EVENT_CLASS. Wire those classes to the BTF id lists generated for sys_enter / sys_exit so all ~700 per-syscall events expose the shared dispatcher prototype and record. The per-syscall events do not own their own tracepoint (they share sys_enter/sys_exit), so raw_btf_id is reported as 0 on those events; the meaningful raw_btf_id is exposed on raw_syscalls/sys_{enter,exit}/btf_ids where raw_tp / tp_btf programs can actually attach. Link: https://patch.msgid.link/20260518-generic_tracepoint-v2-2-b755a5cf67bb@meta.com Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28bpf: Make btf_get_module_btf() and btf_relocate_id() non-staticMykyta Yatsenko
Drop the static qualifier and add prototypes to <linux/btf.h> so the tracing core can look up module BTF and translate ids stored by resolve_btfids (which are local to a module's split BTF) into the runtime ids used by the kernel. Used by the upcoming events/<sys>/<event>/btf_ids tracefs interface. Link: https://patch.msgid.link/20260518-generic_tracepoint-v2-1-b755a5cf67bb@meta.com Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-28arm64: dts: allwinner: a523: enable IR on the Avaota A1Andre Przywara
The Avaota A1 board has an IR receiver chip on the PCB (next to the Ethernet jacks), wired to the PI8 pin on the SoC. Enable the CIR receiver in the main power domain. Tested on the board with evtest and some random TV remote control. Signed-off-by: Andre Przywara <andre.przywara@arm.com> [justin: move the PI8 pinmux node into the dtsi patch] Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260728024916.993224-5-utilityemal77@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-07-28arm64: dts: allwinner: a523: enable IR receiver on the X96Q Pro+Justin Suess
The X96Q Pro+ TV box has an IR receiver window on the front panel, wired to the SoC CIR input on PL11. Enable the CIR receiver in the RTC power domain and mux its RX signal to PL11. Tested on an X96Q Pro+ with ir-keytable and nec keybindings with the remote that it came with in the box. Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260728024916.993224-4-utilityemal77@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-07-28arm64: dts: allwinner: a523: add IR receiver nodesJustin Suess
The A523 has two CIR receivers, both compatible with the A31 CIR: one in the CPUX domain, clocked from the main CCU, and one in the RTC power domain, clocked from the R-CCU. The RTC domain instance's RX signal is typically muxed to PL11, as on the X96Q Pro+. The CPUX instance's can be muxed to PI8, which is what the Avaota A1 uses. Add nodes for both instances, disabled by default. Since the RX signal of each instance can be routed to more than one pin, boards with an IR receiver are expected to add the pinctrl properties next to where they enable the node. Add pinmux nodes for both pins: PL11 for the RTC domain instance, and PI8 for the CPUX one. Co-developed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260728024916.993224-3-utilityemal77@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-07-28media: dt-bindings: allwinner,sun4i-a10-ir: add A523 compatibleJustin Suess
The A523 (sun55i) contains a newer revision of the sunxi CIR receiver. The reset defaults match the fixed behaviour of the older IP, so the device works fine when driven as an A31 CIR receiver. Add the A523 compatible, with allwinner,sun6i-a31-ir as the fallback. While at it, merge the standalone compatible entries into a single enum. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Justin Suess <utilityemal77@gmail.com> Link: https://patch.msgid.link/20260728024916.993224-2-utilityemal77@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-07-28riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGICK Prateek Nayak
Define the placeholder used for lui + addi[w] patching sequence as RUNTIME_MAGIC and use that instead of open coding the constants in the inline assembly. No functional changes intended. Suggested-by: Guo Ren <guoren@kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Guo Ren <guoren@kernel.org> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260728052540.4728-5-kprateek.nayak@amd.com
2026-07-28arm64/runtime-const: Introduce runtime_const_mask_32()K Prateek Nayak
Futex hash computation requires a mask operation with read-only after init data that will be converted to a runtime constant in the subsequent commit. Introduce runtime_const_mask_32 to further optimize the mask operation in the futex hash computation hot path. Since all the current use-cases are of the form GENMASK(n, 0), with n > 0, a single: ubfx w0, w0, #0, #widthm1 // w0 = w0 [widthm1:0] instruction is used for amd64 to improve instruction dinsity and performance. "Arm A-profile A64 Instruction Set Architecture" manual, Sec. "A64 -- Base Instructions" [1] for UBFX instruction highlights the immediate "width" is encoded as width minus 1 in imms (Bits [15:10]) which is patched by __runtime_fixup_mask() once the mask is known. If a future use case arises that needs to tackle arbitrary mask, consider using: movz w1, #lo16, lsl #0 movk w1, #hi16, lsl #16 to patch the 32-bit mask in the asm block and return "__ret & (val)" from runtime_const_mask_32() which allows compiler to further optimize the logical and operation. __runtime_fixup_ptr() already patches a "movz, + movk lsl #16" sequence which can be reused when the need arises. A possible implementation for this alternate scheme can be found at [2]. Suggested-by: Samuel Holland <samuel.holland@sifive.com> Suggested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://developer.arm.com/documentation/ddi0602/2026-03/Base-Instructions/ [1] Link: https://lore.kernel.org/lkml/20260430094730.31624-4-kprateek.nayak@amd.com/ [2] Link: https://patch.msgid.link/20260728052540.4728-4-kprateek.nayak@amd.com
2026-07-28arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patchingK Prateek Nayak
The current scheme to directly patch the kernel text for runtime constants runs into the following issue with futex adapted to using runtime constants on arm64: Unable to handle kernel write to read-only memory at virtual address ... The pc points to the *p assignment in the following call chain: futex_init() runtime_const_init(shift, __futex_shift) __runtime_fixup_shift() *p = cpu_to_le32(insn); which suggests that core_initcall() is too late to patch the kernel text directly unlike the "d_hash_shift" which is initialized during vfs_caches_init_early() before the protections are in place. Use aarch64_insn_patch_text_nosync() to patch the runtime constants instead of doing it directly to allow runtime_const_init() slightly later into the boot. Since aarch64_insn_patch_text_nosync() calls caches_clean_inval_pou() internally, __runtime_fixup_caches() ends up being redundant. runtime_const_init() are rare and the overheads of multiple calls to caches_clean_inval_pou() instead of batching them together should be negligible in practice. The cpu_to_le32() conversion of instruction isn't necessary since it is handled later in the aarch64_insn_patch_text_nosync() call-chain: aarch64_insn_patch_text_nosync(addr, insn) aarch64_insn_write(addr, insn) __aarch64_insn_write(addr, cpu_to_le32(insn)) Sashiko noted that aarch64_insn_patch_text_nosync() does not expect a lm_alias() address and Catalin suggested it is safe to drop the lm_alias() for runtime patching since the kernel text is readable. The address passed to fixup function is interpreted as a __le32 and dereferenced as is to read the opcode at the patch site. No functional changes are intended. Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260728052540.4728-3-kprateek.nayak@amd.com
2026-07-28x86/runtime-const: Introduce runtime_const_mask_32()Peter Zijlstra
Futex hash computation requires a mask operation with read-only after init data that will be converted to a runtime constant in the subsequent commit. Introduce runtime_const_mask_32 to further optimize the mask operation in the futex hash computation hot path. [ prateek: Broke off the x86 chunk, commit message. ] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260227161841.GH606826@noisy.programming.kicks-ass.net Link: https://patch.msgid.link/20260728052540.4728-2-kprateek.nayak@amd.com
2026-07-28arm64: proton-pack: Restore the nospectre_bhb command-line optionKarl Mehltretter
Commit 7f1635737823 ("arm64: proton-pack: Fix hard lockup due to print in scheduler context") moved the "mitigation disabled" printks into spectre_print_disabled_mitigations(). For spectre-v2 and spectre-v4 only the pr_info_once() calls were removed, but for spectre-bhb the whole branch went with the print: - } else if (cpu_mitigations_off() || __nospectre_bhb) { - pr_info_once("spectre-bhb mitigation disabled ...\n"); spectre_bhb_enable_mitigation() therefore no longer tests __nospectre_bhb or cpu_mitigations_off() and the mitigation is enabled regardless of the command line. The parameter is still parsed and its flag is still checked by spectre_print_disabled_mitigations(), so the kernel prints "spectre-bhb mitigation disabled by command-line option" while /sys/devices/system/cpu/vulnerabilities/spectre_v2 reports "Mitigation: CSV2, BHB" and the vectors are switched to EL1_VECTOR_BHB_LOOP. The only remaining escape is the SPECTRE_VULNERABLE arm at the top of the chain, which a CSV2 core never reaches, so from Cortex-A76 and Neoverse N1 onwards both nospectre_bhb and mitigations=off are ignored. Both are documented in Documentation/admin-guide/kernel-parameters.txt. The identical mistake was made on the neighbouring compile-time-option branch immediately before this regression and fixed shortly afterwards; this command-line branch was missed. build_bhb_mitigation() in arch/arm64/net/bpf_jit_comp.c still tests both flags, so nospectre_bhb currently keeps the exception-vector loop while dropping the cBPF epilogue mitigation. Restore the check, folded into a spectre_bhb_mitigations_off() helper alongside its spectre_v2/v4 counterparts, and use it for the boot-time print in spectre_print_disabled_mitigations() as well. The print itself already lives there and does not need restoring. Tested under QEMU with -cpu neoverse-n1 (CSV2, no ECBHB, no CLRBHB). Before, spectre_v2 read "Mitigation: CSV2, BHB" with and without the option; after, nospectre_bhb and mitigations=off both give "Mitigation: CSV2, but not BHB" and a boot without either is unchanged. Fixes: 7f1635737823 ("arm64: proton-pack: Fix hard lockup due to print in scheduler context") Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28arm64: fix cpu-feature-registers Malformed tableRandy Dunlap
The "visible" column was dropped so that last line's extra pieces should also be dropped to prevent a docs build error: Documentation/arch/arm64/cpu-feature-registers.rst:170: ERROR: Malformed table. Right border not aligned or missing. +------------------------------+---------+ | Name | bits | +------------------------------+---------+ | RNDR | [63-60] | +------------------------------+---------+ | TS | [55-52] | +------------------------------+---------+ ... +------------------------------+---------+ | AES | [7-4] | +------------------------------+---------+---------+ [docutils] Fixes: bc7f7ddc64df ("arm64: Remove hidden bitfields from cpu-feature-registers.rst") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Rate-limit the error ISR's log messageNicolin Chen
tegra241_cmdqv_isr() logs the error-map registers on every error interrupt. A malfunctioning device, or a guest deliberately faulting its own VCMDQs, can raise these interrupts rapidly, and the unconditional dev_warn() then floods the kernel log. Rate-limit the message with dev_warn_ratelimited(), and pass the error-map registers straight to it so their four MMIO reads run only when the limiter prints, instead of building the string on every interrupt. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure pathNicolin Chen
tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSIDNicolin Chen
tegra241_vintf_init_vsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Reject the mapping with -EOPNOTSUPP if master->num_streams is not one. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Reject a vSID wider than the SID_MATCH fieldNicolin Chen
tegra241_vintf_init_vsid() programs the guest-provided vSID into SID_MATCH, whose VIRT_SID field spans bits [20:1] with bit 0 as the match-enable flag. The HW therefore matches only a 20-bit Stream ID. The bound check rejects only virt_sid > UINT_MAX, which admits a value far wider than the field. The write "virt_sid << 1 | 0x1" then drops every bit above 20: a virt_sid of 0x80000000 lands as SID_MATCH = 0x1, a valid match on vSID 0, so the entry aliases the wrong Stream ID. Because vdev->virt_id is guest-controlled, a VMM can trigger it. Validate virt_sid against the field width with FIELD_MAX(), and program the register with FIELD_PREP() so the value and the field stay consistent. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFsNicolin Chen
tegra241_cmdqv_remove() tears each VINTF down first, then calls free_irq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241_cmdqv_isr() read the stale slot and hand it to tegra241_vintf0_handle_error(), which dereferences a NULL or freed pointer. Free the IRQ before tearing the VINTFs down. free_irq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down. Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc()Nicolin Chen
__tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path. Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfsNicolin Chen
__tegra241_cmdqv_probe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->num_vintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241_cmdqv_isr() then walks the uninitialized cmdqv->vintfs array. Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Harden error-map index handling in the error ISRNicolin Chen
tegra241_vintf0_handle_error() reads both 64-bit LVCMDQ error-map registers but used the register-local __ffs64() bit directly as the vintf->lvcmdqs[] index. For the second register that selects the wrong queue instead of 64 * i + bit, clearing the wrong queue's error status. The index is unbounded too: a bit at or beyond num_lvcmdqs_per_vintf would walk the read off vintf->lvcmdqs[]. tegra241_cmdqv_isr() has the same flaw one level up: a VINTF_ERR_MAP bit at or beyond num_vintfs would walk the read off cmdqv->vintfs[]. Use 64 * i + bit for the index and clear the snapshot with the local bit. In both handlers, WARN_ON_ONCE() and skip an out-of-bounds index. Only a malfunctioning device sets such a bit, so the _ONCE form keeps a wedged map from flooding the log. Note that 64 * i + bit is not reachable with the current configuration as a VINTF is pre-assigned with 2 lvcmdqs, this is not treated as bug fix but an defensive hardening. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)initNicolin Chen
A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initializedNicolin Chen
tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28fs/ntfs3: reject restart table growth beyond U16_MAX entriesWeiming Shi
During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): rt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-28iommu/arm-smmu-v3: Enable CFGI/TLBI-repeat workaround on Tegra264Ashish Mhetre
Nvidia Tegra264 SMMU is affected by an erratum where a TLB entry can survive an invalidation that races with concurrent traffic targeting the same entry. The hardware-recommended software workaround is to issue every CFGI/TLBI command (each followed by CMD_SYNC) twice, and that infrastructure is already in place behind arm_smmu_erratum_repeat_tlbi_cfgi_key. Neither IDR nor IIDR flags this Tegra264-specific bug, so hardware detection is not possible. Tegra264 is device-tree-only (no ACPI/IORT support) and already has a dedicated "nvidia,tegra264-smmu" compatible, so DT-probe is the only viable detection path. Enable the workaround on instances matching the existing "nvidia,tegra264-smmu" compatible by calling static_branch_enable() on arm_smmu_erratum_repeat_tlbi_cfgi_key. Document the erratum in Documentation/arch/arm64/silicon-errata.rst. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/arm-smmu-v3-iommufd: Report CFGI/TLBI-repeat erratumAshish Mhetre
A guest with access to VCMDQ generates its own invalidation commands and must apply any invalidation errata before submitting them. If the host also repeats those commands, each affected invalidation is issued four times instead of twice. Add IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI to report the CFGI/TLBI-repeat erratum to user space. This allows the VMM to expose the erratum to the guest or apply the workaround itself. Use the raw __arm_smmu_cmdq_issue_cmdlist() helper for user-provided invalidations so the host does not apply the workaround a second time. Add arm_smmu_erratum_repeat_tlbi_cfgi() to query the static key when populating the SMMUv3 hardware information. Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/arm-smmu-v3: Add CFGI/TLBI-repeat workaroundAshish Mhetre
Tegra264 SMMU instances need every CFGI/TLBI command sequence issued twice, with the second issue executing only after the first issue's CMD_SYNC has completed: TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC ATC_INV is not affected and must never be doubled. Add arm_smmu_erratum_repeat_tlbi_cfgi_key and a file-local arm_smmu_erratum_cmd_needs_repeating() helper that gates on the static key first and then range-checks the opcode (CFGI_STE .. ATC_INV). Rename the existing arm_smmu_cmdq_issue_cmdlist() to __arm_smmu_cmdq_issue_cmdlist() and add a thin wrapper of the original name that re-issues the same cmdlist a second time when the predicate fires. Register the new condition with arm_smmu_cmdq_batch_force_sync() too. No callers enable the static key yet, so there is no functional change. A subsequent change will enable the key on affected instances. Suggested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditionsNicolin Chen
arm_smmu_cmdq_batch_add_cmd_p() carries two distinct reasons for flushing the current batch with a CMD_SYNC before appending the new command: - The batch's pre-assigned cmdq does not support the new command. - The Arm erratum 2812531 workaround (ARM_SMMU_OPT_CMDQ_FORCE_SYNC) forces a SYNC at one entry before the batch is full. Lift those checks into a new arm_smmu_cmdq_batch_force_sync() helper so that adding another force-sync condition becomes a one-line addition. No functional change. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-28fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()Samuel Page
ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam@bynar.io> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-28Merge remote-tracking branch 'drm/drm-next' into drm-rust-nextDanilo Krummrich
Backmerge to pull in commit 21fcb222f0d1 ("drm: Remove DRIVER_GEM_GPUVA feature flag"), which a Tyr patch series depends on. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-28media: mali-c55: Add support for RGB GammaJacopo Mondi
Add support for Gamma curve correction for the Mali C55 ISP. Define a new block in the uAPI using the extensible v4l2-isp format and implement support for configuring the RGB Gamma parameters in the mali-c55 parameters handler. While at it, rename the MALI_C55_REG_GAMMA_GAINS_[1|2] register name to MALI_C55_REG_GAMMA_GAINS_[RG|B] and the MALI_C55_REG_GAMMA_OFFSETS_[1|2] register name to MALI_C55_REG_GAMMA_OFFSETS_[RG|B] to better clarify their intent. Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: Add support for CCMJacopo Mondi
Add support for the CCM (Color Correction Matrix) for the Mali C55 ISP. Define a new block in the uAPI using the extensible v4l2-isp format and implement support for configuring the CCM parameters in the mali-c55 ISP driver. Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: Fix clock leak on reset deassert failureDavid Carlier
__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 <devnexen@gmail.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: Drop redundant mutex_destroy in capture register error pathDavid Carlier
In mali_c55_register_cap_dev(), a failure of media_entity_pads_init() destroys cap_dev->lock inline and then jumps to err_destroy_mutex, which destroys the same mutex a second time. Calling mutex_destroy() twice is harmless, so this is not a bugfix, but the inline call is redundant: the err_destroy_mutex label already covers this path, just like the switch default case immediately above. Drop the inline mutex_destroy() and rely solely on the err_destroy_mutex label, so the mutex is destroyed exactly once on every error path. Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: Fix scaler factor overflow for large crop sizesDavid Carlier
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 <devnexen@gmail.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: Fix AEXP IHIST disable bit shiftDavid Carlier
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 <devnexen@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-28media: mali-c55: fix dropped last AEC histogram zone weightDavid Carlier
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 <devnexen@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>