commit c1924e059c728edf4138c6343fafb2c6d234ac35 Author: Sasha Levin Date: Wed Mar 4 07:26:00 2026 -0500 Linux 6.12.75 Signed-off-by: Sasha Levin Tested-by: Hardik Garg Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Mark Brown Tested-by: Brett Mastbergen Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Shung-Hsi Yu Tested-by: Francesco Dolcini Tested-by: Florian Fainelli Tested-by: Dominique Martinet Tested-by: Peter Schneider commit bbfe49ffb892bddf32c34bea95b7ff0fc30affb5 Author: Johan Hovold Date: Fri Jan 16 17:29:50 2026 +0100 most: core: fix leak on early registration failure [ Upstream commit 2c198c272f9c9213b0fdf6b4a879f445c574f416 ] A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface. Fix up also the first error path so that the interface is always released on errors. Fixes: 1f4c9d8a1021 ("most: core: fix resource leak in most_register_interface error paths") Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Cc: Christian Gromm Cc: Navaneeth K Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9f3ffd49da12d8369efeae50234530b27cc0bb1d Author: Marc Zyngier Date: Thu Feb 26 08:22:32 2026 +0000 arm64: Fix sampling the "stable" virtual counter in preemptible section [ Upstream commit e5cb94ba5f96d691d8885175d4696d6ae6bc5ec9 ] Ben reports that when running with CONFIG_DEBUG_PREEMPT, using __arch_counter_get_cntvct_stable() results in well deserves warnings, as we access a per-CPU variable without preemption disabled. Fix the issue by disabling preemption on reading the counter. We can probably do a lot better by not disabling preemption on systems that do not require horrible workarounds to return a valid counter value, but this plugs the issue for the time being. Fixes: 29cc0f3aa7c6 ("arm64: Force the use of CNTVCT_EL0 in __delay()") Reported-by: Ben Horgan Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com Tested-by: Ben Horgan Tested-by: André Draszik Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1147ab1336bc1b493382f6b0eb4da521dd955ff8 Author: Darrick J. Wong Date: Wed Feb 18 15:25:35 2026 -0800 xfs: fix copy-paste error in previous fix [ Upstream commit e764dd439d68cfc16724e469db390d779ab49521 ] Chris Mason noticed that there is a copy-paste error in a recent change to xrep_dir_teardown that nulls out pointers after freeing the resources. Fixes: ba408d299a3bb3c ("xfs: only call xf{array,blob}_destroy if we have a valid pointer") Link: https://lore.kernel.org/linux-xfs/20260205194211.2307232-1-clm@meta.com/ Reported-by: Chris Mason Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit c2bc05dc5ff26b2a76efd578f510ec73650a7013 Author: Jani Nikula Date: Mon Dec 15 14:09:08 2025 +0200 drm/i915/wakeref: clean up INTEL_WAKEREF_PUT_* flag macros [ Upstream commit 524696a19e34598c9173fdd5b32fb7e5d16a91d3 ] Commit 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently discarded") started emitting warnings for cases that were previously silently discarded. One such case is in intel_wakeref.h: Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC() instead Arguably kernel-doc should be able to handle this, as it's valid C, but having the flags defined between the function declarator and the body is just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from there, making kernel-doc's life easier. While at it, reduce the unnecessary abstraction levels by removing the enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity. Cc: Andy Shevchenko Cc: Jonathan Corbet Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20251215120908.3515578-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 5af4761d11a7df1f5f469077b159027809eed044 Author: Nathan Chancellor Date: Tue Jan 6 16:08:18 2026 -0700 ALSA: pcm: Revert bufs move in snd_pcm_xfern_frames_ioctl() [ Upstream commit 0585c53b21541cd6b17ad5ab41b371a0d52e358c ] When building with clang older than 17 targeting architectures that use asm goto for their get_user() and put_user(), such as arm64, after commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations"), there are bogus errors around skipping over a variable declared with the cleanup attribute: sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto statement to one of its possible targets if (put_user(result, &_xfern->result)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm' asm goto( ^ sound/core/pcm_native.c:3295:6: note: possible target of asm goto statement if (put_user(0, &_xfern->result)) ^ ... sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with __attribute__((cleanup)) void *bufs __free(kfree) = ^ clang-17 fixed a bug in clang's jump scope checker [1] where all labels in a function were checked as valid targets for all asm goto instances in a function, regardless of whether they were actual targets in a paricular asm goto's provided list of labels. To workaround this, revert the change done to snd_pcm_xfern_frames_ioctl() by commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") to avoid a variable declared with cleanup from existing between multiple uses of asm goto. There are no other uses of cleanup in this function so there should be low risk from moving this variable back to the top of the function. Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512190802.i4Jzbcsl-lkp@intel.com/ Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for-old-clang-v1-1-06a03693423d@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 26034b60d806fc7eedbb14d12d451f59f574504b Author: Koichiro Den Date: Wed Jan 7 13:24:57 2026 +0900 NTB: ntb_transport: Fix too small buffer for debugfs_name [ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: # v3.9+ Reviewed-by: Frank Li Reviewed-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit af45c677dbf9931fbe3ec4f15d03413f854bbbf6 Author: Petr Pavlu Date: Thu Feb 19 17:27:02 2026 +0100 tracing: Wake up poll waiters for hist files when removing an event [ Upstream commit 9678e53179aa7e907360f5b5b275769008a69b80 ] The event_hist_poll() function attempts to verify whether an event file is being removed, but this check may not occur or could be unnecessarily delayed. This happens because hist_poll_wakeup() is currently invoked only from event_hist_trigger() when a hist command is triggered. If the event file is being removed, no associated hist command will be triggered and a waiter will be woken up only after an unrelated hist command is triggered. Fix the issue by adding a call to hist_poll_wakeup() in remove_event_file_dir() after setting the EVENT_FILE_FL_FREED flag. This ensures that a task polling on a hist file is woken up and receives EPOLLERR. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260219162737.314231-3-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 588c08026d6a341c13c73dcf2169fbac930083c2 Author: Petr Pavlu Date: Thu Feb 19 17:27:01 2026 +0100 tracing: Fix checking of freed trace_event_file for hist files [ Upstream commit f0a0da1f907e8488826d91c465f7967a56a95aca ] The event_hist_open() and event_hist_poll() functions currently retrieve a trace_event_file pointer from a file struct by invoking event_file_data(), which simply returns file->f_inode->i_private. The functions then check if the pointer is NULL to determine whether the event is still valid. This approach is flawed because i_private is assigned when an eventfs inode is allocated and remains set throughout its lifetime. Instead, the code should call event_file_file(), which checks for EVENT_FILE_FL_FREED. Using the incorrect access function may result in the code potentially opening a hist file for an event that is being removed or becoming stuck while polling on this file. Correct the access method to event_file_file() in both functions. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260219162737.314231-2-petr.pavlu@suse.com Fixes: 1bd13edbbed6 ("tracing/hist: Add poll(POLLIN) support on hist file") Signed-off-by: Petr Pavlu Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit fea7c9a23c0fbf7743dbb9d9d9f701cec9d55000 Author: Steven Rostedt Date: Wed Feb 18 10:42:44 2026 -0500 fgraph: Do not call handlers direct when not using ftrace_ops [ Upstream commit f4ff9f646a4d373f9e895c2f0073305da288bc0a ] The function graph tracer was modified to us the ftrace_ops of the function tracer. This simplified the code as well as allowed more features of the function graph tracer. Not all architectures were converted over as it required the implementation of HAVE_DYNAMIC_FTRACE_WITH_ARGS to implement. For those architectures, it still did it the old way where the function graph tracer handle was called by the function tracer trampoline. The handler then had to check the hash to see if the registered handlers wanted to be called by that function or not. In order to speed up the function graph tracer that used ftrace_ops, if only one callback was registered with function graph, it would call its function directly via a static call. Now, if the architecture does not support the use of using ftrace_ops and still has the ftrace function trampoline calling the function graph handler, then by doing a direct call it removes the check against the handler's hash (list of functions it wants callbacks to), and it may call that handler for functions that the handler did not request calls for. On 32bit x86, which does not support the ftrace_ops use with function graph tracer, it shows the issue: ~# trace-cmd start -p function -l schedule ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 2) * 11898.94 us | schedule(); 3) # 1783.041 us | schedule(); 1) | schedule() { ------------------------------------------ 1) bash-8369 => kworker-7669 ------------------------------------------ 1) | schedule() { ------------------------------------------ 1) kworker-7669 => bash-8369 ------------------------------------------ 1) + 97.004 us | } 1) | schedule() { [..] Now by starting the function tracer is another instance: ~# trace-cmd start -B foo -p function This causes the function graph tracer to trace all functions (because the function trace calls the function graph tracer for each on, and the function graph trace is doing a direct call): ~# trace-cmd show # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | 1) 1.669 us | } /* preempt_count_sub */ 1) + 10.443 us | } /* _raw_spin_unlock_irqrestore */ 1) | tick_program_event() { 1) | clockevents_program_event() { 1) 1.044 us | ktime_get(); 1) 6.481 us | lapic_next_event(); 1) + 10.114 us | } 1) + 11.790 us | } 1) ! 181.223 us | } /* hrtimer_interrupt */ 1) ! 184.624 us | } /* __sysvec_apic_timer_interrupt */ 1) | irq_exit_rcu() { 1) 0.678 us | preempt_count_sub(); When it should still only be tracing the schedule() function. To fix this, add a macro FGRAPH_NO_DIRECT to be set to 0 when the architecture does not support function graph use of ftrace_ops, and set to 1 otherwise. Then use this macro to know to allow function graph tracer to call the handlers directly or not. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Mark Rutland Link: https://patch.msgid.link/20260218104244.5f14dade@gandalf.local.home Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit b4700c089a10f89de3a5149d57f8a58306458982 Author: Masami Hiramatsu (Google) Date: Mon Feb 16 18:30:15 2026 +0900 tracing: ring-buffer: Fix to check event length before using [ Upstream commit 912b0ee248c529a4f45d1e7f568dc1adddbf2a4a ] Check the event length before adding it for accessing next index in rb_read_data_buffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177123421541.142205.9414352170164678966.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 3b91160e9a91b5a2662875417dc42dc5b0bf03ea Author: Michael Thalmeier Date: Wed Feb 18 09:30:00 2026 +0100 net: nfc: nci: Fix parameter validation for packet data [ Upstream commit 571dcbeb8e635182bb825ae758399831805693c2 ] Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") Cc: stable@vger.kernel.org Signed-off-by: Michael Thalmeier Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260218083000.301354-1-michael.thalmeier@hale.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bd135851106c99db0e0504391fc11096b1307d40 Author: Alex Deucher Date: Mon Feb 16 10:02:32 2026 -0500 drm/amdgpu: keep vga memory on MacBooks with switchable graphics [ Upstream commit 096bb75e13cc508d3915b7604e356bcb12b17766 ] On Intel MacBookPros with switchable graphics, when the iGPU is enabled, the address of VRAM gets put at 0 in the dGPU's virtual address space. This is non-standard and seems to cause issues with the cursor if it ends up at 0. We have the framework to reserve memory at 0 in the address space, so enable it here if the vram start address is 0. Reviewed-and-tested-by: Mario Kleiner Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: stable@vger.kernel.org Cc: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5fc0933641a8732348439b4b7de0b4f011be35bf Author: Marc Zyngier Date: Fri Feb 13 14:16:19 2026 +0000 arm64: Force the use of CNTVCT_EL0 in __delay() [ Upstream commit 29cc0f3aa7c64d3b3cb9d94c0a0984ba6717bf72 ] Quentin forwards a report from Hyesoo Yu, describing an interesting problem with the use of WFxT in __delay() when a vcpu is loaded and that KVM is *not* in VHE mode (either nVHE or hVHE). In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the state of the guest virtual counter. At the same time, __delay() is using get_cycles() to read the counter value, which is indirected to reading CNTPCT_EL0. The core of the issue is that WFxT is using the *virtual* counter, while the kernel is using the physical counter, and that the offset introduces a really bad discrepancy between the two. Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent irrespective of the value of CNTVOFF_EL2. Reported-by: Hyesoo Yu Reported-by: Quentin Perret Reviewed-by: Quentin Perret Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d95f0851cf403d67f89554cf4b2ecca484653755 Author: Ard Biesheuvel Date: Tue Feb 17 12:09:35 2026 +0100 x86/kexec: Copy ACPI root pointer address from config table [ Upstream commit e00ac9e5afb5d80c0168ec88d8e8662a54af8249 ] Dave reports that kexec may fail when the first kernel boots via the EFI stub but without EFI runtime services, as in that case, the RSDP address field in struct bootparams is never assigned. Kexec copies this value into the version of struct bootparams that it provides to the incoming kernel, which may have no other means to locate the ACPI root pointer. So take the value from the EFI config tables if no root pointer has been set in the first kernel's struct bootparams. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Cc: # v6.1 Reported-by: Dave Young Tested-by: Dave Young Link: https://lore.kernel.org/linux-efi/aZQg_tRQmdKNadCg@darkstar.users.ipa.redhat.com/ Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 015cebdfcb97b5347fb7f598ea712a281cb35840 Author: Ruitong Liu Date: Sat Feb 14 01:59:48 2026 +0800 net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash() [ Upstream commit be054cc66f739a9ba615dba9012a07fab8e7dd6f ] Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod = queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping += skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash. Fixes: 38a6f0865796 ("net: sched: support hash selecting tx queue") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Ruitong Liu Link: https://patch.msgid.link/20260213175948.1505257-1-cnitlrt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b1371cd4032ae859838ebc74215f569987bb197 Author: Thomas Fourier Date: Fri Feb 13 17:43:39 2026 +0100 net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle [ Upstream commit ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2 ] dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys. Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260213164340.77272-2-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8122e05bd27bd40601b1dcf664cf20efc46839e2 Author: Gustavo Salvini Date: Tue Feb 10 12:51:56 2026 -0300 ASoC: amd: yc: Add DMI quirk for ASUS Vivobook Pro 15X M6501RR [ Upstream commit ff9cadd1a2c0b2665b7377ac79540d66f212e7e3 ] The ASUS Vivobook Pro 15X (M6501RR) with AMD Ryzen 9 6900HX has an internal DMIC that is not detected without a DMI quirk entry, as the BIOS does not set the AcpDmicConnected ACPI _DSD property. Adding the DMI entry enables the ACP6x DMIC machine driver to probe successfully. Cc: stable@vger.kernel.org Signed-off-by: Gustavo Salvini Link: https://patch.msgid.link/20260210155156.29079-1-guspatagonico@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d731e512134495e0ef490ade0e4d91dc0d515ec Author: Shyam Prasad N Date: Sat Feb 14 15:59:13 2026 +0530 cifs: some missing initializations on replay [ Upstream commit 14f66f44646333d2bfd7ece36585874fd72f8286 ] In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay. This change makes sure that these variables get initialized after the label. Cc: stable@vger.kernel.org Reported-by: Yuchan Nam Tested-by: Yuchan Nam Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f73b3653a4c3586611af01ea9b03aac410d0f2db Author: Thomas Zimmermann Date: Mon Feb 9 17:15:43 2026 +0100 fbcon: Remove struct fbcon_display.inverse [ Upstream commit 30baedeeeab524172abc0b58cb101e8df86b5be8 ] The field inverse in struct fbcon_display is unused. Remove it. Signed-off-by: Thomas Zimmermann Cc: # v6.0+ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8225baf882d52063e349a8ecc8b994c30bb247b4 Author: René Rebe Date: Thu Feb 5 16:49:58 2026 +0100 fbdev: ffb: fix corrupted video output on Sun FFB1 [ Upstream commit b28da0d092461ac239ff034a8ac3129320177ba3 ] Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and initializing window mode to a known state. The issue never appeared on my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM version. /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4] X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered. X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control) X (II) /dev/fb0: Detected Creator/Creator3D [1] https://www.instagram.com/p/DUTcSmSjSem/ [2] https://chaos.social/@ReneRebe/116023241660154102 Signed-off-by: René Rebe Cc: stable@kernel.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit d6f34bbff07476c6abb8672c89d217824871c5ed Author: Weigang He Date: Fri Jan 16 09:57:51 2026 +0000 fbdev: of: display_timing: fix refcount leak in of_get_display_timings() [ Upstream commit eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 ] of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Cc: stable@vger.kernel.org Signed-off-by: Weigang He Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit f47d5b9e8aa6178a0aaf225119ad1ec7d3f49876 Author: Thomas Fourier Date: Mon Jan 12 15:00:27 2026 +0100 fbdev: vt8500lcdfb: fix missing dma_free_coherent() [ Upstream commit 88b3b9924337336a31cefbe99a22ed09401be74a ] fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached. Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb") Cc: Signed-off-by: Thomas Fourier Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 0b038c0be6827dd2dbb1ce4f8d92d97c80cbe9cc Author: Andrey Vatoropin Date: Wed Dec 17 09:11:05 2025 +0000 fbcon: check return value of con2fb_acquire_newinfo() [ Upstream commit 011a0502801c8536f64141a2b61362c14f456544 ] If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes") Cc: stable@vger.kernel.org Signed-off-by: Andrey Vatoropin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e93d898ee9970abf829a24c51f84d8f85cec761d Author: Cui Chao Date: Fri Feb 13 14:03:47 2026 +0800 mm: numa_memblks: Identify the accurate NUMA ID of CFMW [ Upstream commit f043a93fff9e3e3e648b6525483f59104b0819fa ] In some physical memory layout designs, the address space of CFMW (CXL Fixed Memory Window) resides between multiple segments of system memory belonging to the same NUMA node. In numa_cleanup_meminfo, these multiple segments of system memory are merged into a larger numa_memblk. When identifying which NUMA node the CFMW belongs to, it may be incorrectly assigned to the NUMA node of the merged system memory. When a CXL RAM region is created in userspace, the memory capacity of the newly created region is not added to the CFMW-dedicated NUMA node. Instead, it is accumulated into an existing NUMA node (e.g., NUMA0 containing RAM). This makes it impossible to clearly distinguish between the two types of memory, which may affect memory-tiering applications. Example memory layout: Physical address space: 0x00000000 - 0x1FFFFFFF System RAM (node0) 0x20000000 - 0x2FFFFFFF CXL CFMW (node2) 0x40000000 - 0x5FFFFFFF System RAM (node0) 0x60000000 - 0x7FFFFFFF System RAM (node1) After numa_cleanup_meminfo, the two node0 segments are merged into one: 0x00000000 - 0x5FFFFFFF System RAM (node0) // CFMW is inside the range 0x60000000 - 0x7FFFFFFF System RAM (node1) So the CFMW (0x20000000-0x2FFFFFFF) will be incorrectly assigned to node0. To address this scenario, accurately identifying the correct NUMA node can be achieved by checking whether the region belongs to both numa_meminfo and numa_reserved_meminfo. While this issue is only observed in a QEMU configuration, and no known end users are impacted by this problem, it is likely that some firmware implementation is leaving memory map holes in a CXL Fixed Memory Window. CXL hotplug depends on mapping free window capacity, and it seems to be only a coincidence to have not hit this problem yet. Fixes: 779dd20cfb56 ("cxl/region: Add region creation support") Signed-off-by: Cui Chao Cc: stable@vger.kernel.org Reviewed-by: Jonathan Cameron Reviewed-by: Gregory Price Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260213060347.2389818-2-cuichao1753@phytium.com.cn Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 0591d6509c2ff13f09ea2998434aba0c0472e978 Author: Qanux Date: Wed Feb 11 12:04:12 2026 +0800 ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() [ Upstream commit 6db8b56eed62baacaf37486e83378a72635c04cc ] On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00). Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Cc: stable@vger.kernel.org Signed-off-by: Junxi Qian Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260211040412.86195-1-qjx1298677004@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91892dafccb1113d9061477c518e2fcb650ccfaf Author: Shengming Hu Date: Fri Feb 13 14:29:32 2026 +0800 function_graph: Restore direct mode when callbacks drop to one [ Upstream commit 53b2fae90ff01fede6520ca744ed5e8e366497ba ] When registering a second fgraph callback, direct path is disabled and array loop is used instead. When ftrace_graph_active falls back to one, we try to re-enable direct mode via ftrace_graph_enable_direct(true, ...). But ftrace_graph_enable_direct() incorrectly disables the static key rather than enabling it. This leaves fgraph_do_direct permanently off after first multi-callback transition, so direct fast mode is never restored. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260213142932519cuWSpEXeS4-UnCvNXnK2P@zte.com.cn Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function") Signed-off-by: Shengming Hu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 97900f512252a59f23d6ce4ab215cc88fed66e68 Author: Duoming Zhou Date: Tue Feb 10 17:45:37 2026 +0800 atm: fore200e: fix use-after-free in tasklets during device removal [ Upstream commit 8930878101cd40063888a68af73b1b0f8b6c79bc ] When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Suggested-by: Jijie Shao Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210094537.9767-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit df4308cb52dcc2e0780d818d06d6fb9da25ba0c2 Author: Ethan Nelson-Moore Date: Mon Feb 9 18:12:34 2026 -0800 net: intel: fix PCI device ID conflict between i40e and ipw2200 [ Upstream commit d03e094473ecdeb68d853752ba467abe13e1de44 ] The ID 8086:104f is matched by both i40e and ipw2200. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. Fix this by taking advantage of the fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200 devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Cc: stable@vger.kernel.org Acked-by: Johannes Berg Signed-off-by: Ethan Nelson-Moore Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260210021235.16315-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f9fe092084cd04deea18747f58a2304026e76aaa Author: Andrii Nakryiko Date: Tue Feb 10 11:27:38 2026 -0800 procfs: fix possible double mmput() in do_procmap_query() [ Upstream commit 61dc9f776705d6db6847c101b98fa4f0e9eb6fa3 ] When user provides incorrectly sized buffer for build ID for PROCMAP_QUERY we return with -ENAMETOOLONG error. After recent changes this condition happens later, after we unlocked mmap_lock/per-VMA lock and did mmput(), so original goto out is now wrong and will double-mmput() mm_struct. Fix by jumping further to clean up only vm_file and name_buf. Link: https://lkml.kernel.org/r/20260210192738.3041609-1-andrii@kernel.org Fixes: b5cbacd7f86f ("procfs: avoid fetching build ID while holding VMA lock") Signed-off-by: Andrii Nakryiko Reported-by: Ruikai Peng Reported-by: Thomas Gleixner Tested-by: Thomas Gleixner Reviewed-by: Shakeel Butt Reported-by: syzbot+237b5b985b78c1da9600@syzkaller.appspotmail.com Cc: Ruikai Peng Closes: https://lkml.kernel.org/r/CAFD3drOJANTZPuyiqMdqpiRwOKnHwv5QgMNZghCDr-WxdiHvMg@mail.gmail.com Closes: https://lore.kernel.org/all/698aaf3c.050a0220.3b3015.0088.GAE@google.com/T/#u Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 82a7ea35a1526bef8ae170c33ff80e5db7728961 Author: Pierre-Eric Pelloux-Prayer Date: Mon Feb 9 18:54:45 2026 +0100 drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify [ Upstream commit b18fc0ab837381c1a6ef28386602cd888f2d9edf ] Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. Cc: stable@vger.kernel.org Fixes: a448cb003edc ("drm/amdgpu: implement amdgpu_gem_prime_move_notify v2") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f08df326752a7b106aba1244aed76abf0e3c3ac Author: Leo Li Date: Mon Nov 3 11:14:59 2025 -0500 drm/amd/display: Increase DCN35 SR enter/exit latency [ Upstream commit 318917e1d8ecc89f820f4fabf79935f4fed718cd ] [Why & How] On Framework laptops with DDR5 modules, underflow can be observed. It's unclear why it only occurs on specific desktop contents. However, increasing enter/exit latencies by 3us seems to resolve it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4463 Reviewed-by: Nicholas Kazlauskas Signed-off-by: Leo Li Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5cfc202825bacaec4727864aa301e750d49ae6f6 Author: Jens Axboe Date: Wed Feb 11 15:12:03 2026 -0700 io_uring/filetable: clamp alloc_hint to the configured alloc range [ Upstream commit a6bded921ed35f21b3f6bd8e629bf488499ca442 ] Explicit fixed file install/remove operations on slots outside the configured alloc range can corrupt alloc_hint via io_file_bitmap_set() and io_file_bitmap_clear(), which unconditionally update alloc_hint to the bit position. This causes subsequent auto-allocations to fall outside the configured range. For example, if the alloc range is [10, 20) and a file is removed at slot 2, alloc_hint gets set to 2. The next auto-alloc then starts searching from slot 2, potentially returning a slot below the range. Fix this by clamping alloc_hint to [file_alloc_start, file_alloc_end) at the top of io_file_bitmap_get() before starting the search. Cc: stable@vger.kernel.org Fixes: 6e73dffbb93c ("io_uring: let to set a range for file slot allocation") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 74f7e464ad88d7a0951f3f837032af36d065e04b Author: Masami Hiramatsu (Google) Date: Tue Feb 10 17:43:36 2026 +0900 tracing: Fix to set write permission to per-cpu buffer_size_kb [ Upstream commit f844282deed7481cf2f813933229261e27306551 ] Since the per-cpu buffer_size_kb file is writable for changing per-cpu ring buffer size, the file should have the write access permission. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/177071301597.2293046.11683339475076917920.stgit@mhiramat.tok.corp.google.com Fixes: 21ccc9cd7211 ("tracing: Disable "other" permission bits in the tracefs files") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 6e704e89f16fd4a1145756210bc210f14f174f94 Author: Kevin Hao Date: Sun Feb 8 16:45:52 2026 +0800 net: macb: Fix tx/rx malfunction after phy link down and up [ Upstream commit bf9cf80cab81e39701861a42877a28295ade266f ] In commit 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()"), the mog_init_rings() callback was moved from macb_mac_link_up() to macb_open() to resolve a deadlock issue. However, this change introduced a tx/rx malfunction following phy link down and up events. The issue arises from a mismatch between the software queue->tx_head, queue->tx_tail, queue->rx_prepared_head, and queue->rx_tail values and the hardware's internal tx/rx queue pointers. According to the Zynq UltraScale TRM [1], when tx/rx is disabled, the internal tx queue pointer resets to the value in the tx queue base address register, while the internal rx queue pointer remains unchanged. The following is quoted from the Zynq UltraScale TRM: When transmit is disabled, with bit [3] of the network control register set low, the transmit-buffer queue pointer resets to point to the address indicated by the transmit-buffer queue base address register. Disabling receive does not have the same effect on the receive-buffer queue pointer. Additionally, there is no need to reset the RBQP and TBQP registers in a phy event callback. Therefore, move macb_init_buffers() to macb_open(). In a phy link up event, the only required action is to reset the tx software head and tail pointers to align with the hardware's behavior. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260208-macb-init-ring-v1-1-939a32c14635@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 86ad5c4ac79098fcda2a0d27754d2e11209df391 Author: Kevin Hao Date: Sat Feb 7 14:21:46 2026 +0800 net: ti: icssg-prueth: Add optional dependency on HSR [ Upstream commit e3998b6e90f875f19bf758053d79ccfd41880173 ] Commit 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") introduced support for offloading HSR frame forwarding, which relies on functions such as is_hsr_master() provided by the HSR module. Although HSR provides stubs for configurations with HSR disabled, this driver still requires an optional dependency on HSR. Otherwise, build failures will occur when icssg-prueth is built-in while HSR is configured as a module. ld.lld: error: undefined symbol: is_hsr_master >>> referenced by icssg_prueth.c:710 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:710) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:681 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:681) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:1812 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:1812) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(prueth_netdevice_event) in archive vmlinux.a ld.lld: error: undefined symbol: hsr_get_port_ndev >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712) >>> drivers/net/etherneteth_hsr_del_mcast) in archive vmlinux.a >>> referenced by icssg_prueth.c:683 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:683) >>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a >>> referenced 1 more times Fixes: 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260207-icssg-dep-v3-1-8c47c1937f81@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ccef79af58b43787c25710c9da96651c6ddfe50f Author: Bo Sun Date: Fri Feb 6 21:09:24 2026 +0800 octeontx2-af: CGX: fix bitmap leaks [ Upstream commit 3def995c4ede842adf509c410e92d09a0cedc965 ] The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap) are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit(). Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probe Free both bitmaps during teardown. Fixes: e740003874ed ("octeontx2-af: Flow control resource management") Cc: stable@vger.kernel.org Signed-off-by: Bo Sun Reviewed-by: Vadim Fedorenko Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206130925.1087588-2-bo@mboxify.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 84b932bc9899d43e5829e6cf088b72d73a922b2b Author: Thomas Fourier Date: Fri Feb 6 09:53:33 2026 +0100 net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() [ Upstream commit 36bd7d5deef936c4e1e3cd341598140e5c14c1d3 ] The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer. Reviewed-by: Christophe Leroy (CS GROUP) Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") Cc: Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260206085334.21195-2-fourier.thomas@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f73c042724d95caab95b196b8603574ae32b825a Author: Ethan Nelson-Moore Date: Thu Feb 5 23:17:14 2026 -0800 net: ethernet: marvell: skge: remove incorrect conflicting PCI ID [ Upstream commit d01103fdcb871fd83fd06ef5803d576507c6a801 ] The ID 1186:4302 is matched by both r8169 and skge. The same device ID should not be in more than one driver, because in that case, which driver is used is unpredictable. I downloaded the latest drivers for all hardware revisions of the D-Link DGE-530T from D-Link's website, and the only drivers which contain this ID are Realtek drivers. Therefore, remove this device ID from skge. In the kernel bug report which requested addition of this device ID, someone created a patch to add the ID to skge. Then, it was pointed out that this device is an "r8169 in disguise", and a patch was created to add it to r8169. Somehow, both of these patches got merged. See the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=38862 Fixes: c074304c2bcf ("add pci-id for DGE-530T") Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260206071724.15268-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e6e65be0752fd7c45d03d8f58d3e53463e7fa9d7 Author: Tiezhu Yang Date: Tue Feb 10 19:31:17 2026 +0800 LoongArch: Disable instrumentation for setup_ptwalker() [ Upstream commit 7cb37af61f09c9cfd90c43c9275307c16320cbf2 ] According to Documentation/dev-tools/kasan.rst, software KASAN modes use compiler instrumentation to insert validity checks. Such instrumentation might be incompatible with some parts of the kernel, and therefore needs to be disabled, just use the attribute __no_sanitize_address to disable instrumentation for the low level function setup_ptwalker(). Otherwise bringing up the secondary CPUs failed when CONFIG_KASAN is set (especially when PTW is enabled), here are the call chains: smpboot_entry() start_secondary() cpu_probe() per_cpu_trap_init() tlb_init() setup_tlb_handler() setup_ptwalker() The reason is the PGD registers are configured in setup_ptwalker(), but KASAN instrumentation may cause TLB exceptions before that. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 35a384eb064eb8107495e6c5e2b209c0914ce91c Author: Tiezhu Yang Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Guard percpu handler under !CONFIG_PREEMPT_RT [ Upstream commit 70b0faae3590c628a98a627a10e5d211310169d4 ] After commit 88fd2b70120d ("LoongArch: Fix sleeping in atomic context for PREEMPT_RT"), it should guard percpu handler under !CONFIG_PREEMPT_RT to avoid redundant operations. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 808ac152e46a9f5faa441646d9c2c9e709425188 Author: Tiezhu Yang Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Use %px to print unmodified unwinding address [ Upstream commit 77403a06d845db1caf9a6b0867b43e9dd8de8e4a ] Currently, use %p to prevent leaking information about the kernel memory layout when printing the PC address, but the kernel log messages are not useful to debug problem if bt_address() returns 0. Given that the type of "pc" variable is unsigned long, it should use %px to print the unmodified unwinding address. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit af7db33e5d2e28ecb2371090114687727f8e7adc Author: Huacai Chen Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Prefer top-down allocation after arch_mem_init() [ Upstream commit 2172d6ebac9372eb01fe4505a53e18cb061e103b ] Currently we use bottom-up allocation after sparse_init(), the reason is sparse_init() need a lot of memory, and bottom-up allocation may exhaust precious low memory (below 4GB). On the other hand, SWIOTLB and CMA need low memories for DMA32, so swiotlb_init() and dma_contiguous_reserve() need bottom-up allocation. Since swiotlb_init() and dma_contiguous_reserve() are both called in arch_mem_init(), we no longer need bottom-up allocation after that. So we set the allocation policy to top-down at the end of arch_mem_init(), in order to avoid later memory allocations (such as KASAN) exhaust low memory. This solve at least two problems: 1. Some buggy BIOSes use 0xfd000000~0xfe000000 for secondary CPUs, but didn't reserve this range, which causes smpboot failures. 2. Some DMA32 devices, such as Loongson-DRM and OHCI, cannot work with KASAN enabled. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 92adfb707beec0fe956424373654a70aad35ea13 Author: John Garry Date: Tue Feb 10 19:31:12 2026 +0800 LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit 94b0c831eda778ae9e4f2164a8b3de485d8977bb ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Cc: stable@vger.kernel.org Signed-off-by: John Garry Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 4f5b7016e552a2cc30f8d7afdb55c20b7cf48d2a Author: Miguel Ojeda Date: Fri Feb 6 21:45:35 2026 +0100 rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0 [ Upstream commit 0a9be83e57de0d0ca8ca4ec610bc344f17a8e5e7 ] Custom target specifications are unstable, but starting with Rust 1.95.0, `rustc` requires to explicitly pass `-Zunstable-options` to use them [1]: error: error loading target specification: custom targets are unstable and require `-Zunstable-options` | = help: run `rustc --print target-list` for a list of built-in targets David (Rust compiler team lead), writes: "We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them." Thus pass it. Cc: David Wood Cc: Wesley Wiser Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/151534 [1] Reviewed-by: Gary Guo Tested-by: Gary Guo Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 531a76c5a2e44264cee8a70121e63eb28c1ba728 Author: ethanwu Date: Thu Sep 25 18:42:05 2025 +0800 ceph: supply snapshot context in ceph_zero_partial_object() [ Upstream commit f16bd3fa74a2084ee7e16a8a2be7e7399b970907 ] The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!! Cc: stable@vger.kernel.org Fixes: ad7a60de882ac ("ceph: punch hole support") Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit e7d70a77ad6f41b879e1ef63f26b1d13975d162e Author: Jiaxun Yang Date: Thu Feb 5 10:08:42 2026 +0000 MIPS: rb532: Fix MMIO UART resource registration [ Upstream commit e93bb4b76cfefb302534246e892c7667491cb8cc ] Since commit 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()"), registering an 8250 MMIO port without mapbase no longer works, as the resource range is derived from mapbase/mapsize. Populate mapbase and mapsize accordingly. Also drop ugly membase KSEG1 pointer and set UPF_IOREMAP instead, letting the 8250 core perform the ioremap. Fixes: 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()") Cc: stable@vger.kernel.org Reported-by: Waldemar Brodkorb Link: https://lore.kernel.org/linux-mips/aX-d0ShTplHKZT33@waldemar-brodkorb.de/ Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 601dd3b79769b38d30b693c40afdb2a4b7edf9d0 Author: Shyam Prasad N Date: Sun Feb 1 00:21:13 2026 +0530 cifs: Fix locking usage for tcon fields [ Upstream commit 96c4af418586ee9a6aab61738644366426e05316 ] We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization. There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock. Cc: stable@vger.kernel.org Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7d9e0df82207388034a23b3bbebf389bef234714 Author: Shengming Hu Date: Mon Jan 19 21:59:05 2026 +0800 watchdog/softlockup: fix sample ring index wrap in need_counting_irqs() [ Upstream commit cafe4074a7221dca2fa954dd1ab0cf99b6318e23 ] cpustat_tail indexes cpustat_util[], which is a NUM_SAMPLE_PERIODS-sized ring buffer. need_counting_irqs() currently wraps the index using NUM_HARDIRQ_REPORT, which only happens to match NUM_SAMPLE_PERIODS. Use NUM_SAMPLE_PERIODS for the wrap to keep the ring math correct even if the NUM_HARDIRQ_REPORT or NUM_SAMPLE_PERIODS changes. Link: https://lkml.kernel.org/r/tencent_7068189CB6D6689EB353F3D17BF5A5311A07@qq.com Fixes: e9a9292e2368 ("watchdog/softlockup: Report the most frequent interrupts") Signed-off-by: Shengming Hu Reviewed-by: Petr Mladek Cc: Ingo Molnar Cc: Mark Brown Cc: Thomas Gleixner Cc: Zhang Run Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3713af7e95a391ab9ba212154938e4639bc569d3 Author: Alan Maguire Date: Fri Jan 16 09:17:30 2026 +0000 kcsan, compiler_types: avoid duplicate type issues in BPF Type Format [ Upstream commit 9dc052234da736f7749f19ab6936342ec7dbe3ac ] Enabling KCSAN is causing a large number of duplicate types in BTF for core kernel structs like task_struct [1]. This is due to the definition in include/linux/compiler_types.h `#ifdef __SANITIZE_THREAD__ ... `#define __data_racy volatile .. `#else ... `#define __data_racy ... `#endif Because some objects in the kernel are compiled without KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty __data_racy annotation for objects; as a result we get multiple conflicting representations of the associated structs in DWARF, and these lead to multiple instances of core kernel types in BTF since they cannot be deduplicated due to the additional modifier in some instances. Moving the __data_racy definition under CONFIG_KCSAN avoids this problem, since the volatile modifier will be present for both KCSAN and KCSAN_SANITIZE objects in a CONFIG_KCSAN=y kernel. Link: https://lkml.kernel.org/r/20260116091730.324322-1-alan.maguire@oracle.com Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier") Signed-off-by: Alan Maguire Reported-by: Nilay Shroff Tested-by: Nilay Shroff Suggested-by: Marco Elver Reviewed-by: Marco Elver Acked-by: Yonghong Song Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Bart van Assche Cc: Daniel Borkman Cc: Eduard Zingerman Cc: Hao Luo Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Jason A. Donenfeld Cc: Jiri Olsa Cc: John Fastabend Cc: Kees Cook Cc: KP Singh Cc: Martin KaFai Lau Cc: Miguel Ojeda Cc: Naman Jain Cc: Nathan Chancellor Cc: "Paul E . McKenney" Cc: Peter Zijlstra Cc: Stanislav Fomichev Cc: Uros Bizjak Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 04d24a3654ed195485bc6346a9ef326fc494a34e Author: Ethan Tidmore Date: Mon Feb 2 14:54:29 2026 -0600 staging: rtl8723bs: fix null dereference in find_network [ Upstream commit 41460a19654c32d39fd0e3a3671cd8d4b7b8479f ] The variable pwlan has the possibility of being NULL when passed into rtw_free_network_nolock() which would later dereference the variable. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260202205429.20181-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6d2dae6b97bd847aaea0a2709db62d0bf1d8e913 Author: Haoxiang Li Date: Fri Dec 19 21:19:26 2025 +0800 parisc: kernel: replace kfree() with put_device() in create_tree_node() [ Upstream commit dcf69599c47f29ce0a99117eb3f9ddcd2c4e78b6 ] If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 0425aaf20b407d2f2cf3bf469808e4a35f9abb8b Author: Jinhui Guo Date: Fri Dec 12 22:55:28 2025 +0800 PCI: Fix pci_slot_trylock() error handling [ Upstream commit 9368d1ee62829b08aa31836b3ca003803caf0b72 ] Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com Signed-off-by: Sasha Levin commit 87ab6b527f078477c806575e57a81d8202033efe Author: Kevin Hao Date: Thu Feb 5 10:47:02 2026 +0800 net: cpsw_new: Fix unnecessary netdev unregistration in cpsw_probe() error path [ Upstream commit 62db84b7efa63b78aed9fdbdae90f198771be94c ] The current error handling in cpsw_probe() has two issues: - cpsw_unregister_ports() may be called before cpsw_register_ports() has been executed. - cpsw_unregister_ports() is already invoked within cpsw_register_ports() in case of a register_netdev() failure, but the error path would call it again. Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1 - dual-emac") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/20260205-cpsw-error-path-v1-1-6e58bae6b299@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75fb57efdd7863fffbc39db23e9cad7aafda26ed Author: Sunday Clement Date: Mon Feb 2 12:41:39 2026 -0500 drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() [ Upstream commit 8a70a26c9f34baea6c3199a9862ddaff4554a96d ] The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation. Signed-off-by: Sunday Clement Reviewed-by: Alexander Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 43bc12f6d61140595c9947710eacf9282b096771 Author: Daniel Hodges Date: Tue Feb 3 09:56:21 2026 -0500 tipc: fix RCU dereference race in tipc_aead_users_dec() [ Upstream commit 6a65c0cb0ff20b3cbc5f1c87b37dd22cdde14a1c ] tipc_aead_users_dec() calls rcu_dereference(aead) twice: once to store in 'tmp' for the NULL check, and again inside the atomic_add_unless() call. Use the already-dereferenced 'tmp' pointer consistently, matching the correct pattern used in tipc_aead_users_inc() and tipc_aead_users_set(). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Cc: stable@vger.kernel.org Reviewed-by: Eric Dumazet Signed-off-by: Daniel Hodges Link: https://patch.msgid.link/20260203145621.17399-1-git@danielhodges.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4b964b7377c378956cecb8565bee7758a74514c Author: Andrea Scian Date: Wed Feb 4 18:41:44 2026 +0100 mtd: rawnand: pl353: Fix software ECC support [ Upstream commit 89b831ebdaca0df4ca3b226f7e7a1d1db1629060 ] We need to set also write_page_raw in ecc structure to allow choosing SW ECC instead of HW one, otherwise write operation fail. Fixes: 08d8c62164a322 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Andrea Scian Cc: stable@kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 42ef7c504ae5d707c2a67656937da2303b5d85c1 Author: Jisheng Zhang Date: Thu Jan 29 10:15:34 2026 +0800 usb: dwc2: fix resume failure if dr_mode is host [ Upstream commit a52e4f2dff413b58c7200e89bb6540bd995e1269 ] commit 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") removed the dwc2_force_mode(hsotg, true) in dwc2_force_dr_mode() if dr_mode is host. But this brings a bug: the controller fails to resume back as host, further debugging shows that the controller is resumed as peripheral. The reason is dwc2_force_dr_mode() missed the host mode forcing, and when resuming from s2ram, GINTSTS is 0 by default, dwc2_is_device_mode in dwc2_resume() misreads this as the controller is in peripheral mode. Fix the resume failure by adding back the dwc2_force_mode(hsotg, true). Then an obvious question is: why this bug hasn't been observed and fixed for about six years? There are two resons: most dwc2 platforms set the dr_mode as otg; Some platforms don't have suspend & resume support yet. Fixes: 13b1f8e25bfd1 ("usb: dwc2: Force mode optimizations") Cc: stable Signed-off-by: Jisheng Zhang Link: https://patch.msgid.link/20260129021534.10411-1-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a7a80c25b65112768eeba58a7af129d3c52a6d90 Author: Prashanth K Date: Wed Feb 4 11:11:55 2026 +0530 usb: dwc3: gadget: Move vbus draw to workqueue context [ Upstream commit 54aaa3b387c2f580a99dc86a9cc2eb6dfaf599a7 ] Currently dwc3_gadget_vbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic. Fix this by moving the vbus_draw into a workqueue context. Fixes: 99288de36020 ("usb: dwc3: add an alternate path in vbus_draw callback") Cc: stable Tested-by: Samuel Wu Acked-by: Thinh Nguyen Signed-off-by: Prashanth K Link: https://patch.msgid.link/20260204054155.3063825-1-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f3132336db399a4ad099e31523403a6bb178dcf1 Author: Niklas Cassel Date: Tue Jan 27 16:10:39 2026 +0100 PCI: dwc: Fix msg_atu_index assignment [ Upstream commit 58fbf08935d9c4396417e5887df89a4e681fa7e3 ] When dw_pcie_iatu_setup() configures outbound address translation for both type PCIE_ATU_TYPE_MEM and PCIE_ATU_TYPE_IO, the iATU index to use is incremented before calling dw_pcie_prog_outbound_atu(). However for msg_atu_index, the index is not incremented before use, causing the iATU index to be the same as the last configured iATU index, which means that it will incorrectly use the same iATU index that is already in use, breaking outbound address translation. In total there are three problems with this code: -It assigns msg_atu_index the same index that was used for the last outbound address translation window, rather than incrementing the index before assignment. -The index should only be incremented (and msg_atu_index assigned) if the use_atu_msg feature is actually requested/in use (pp->use_atu_msg is set). -If the use_atu_msg feature is requested/in use, and there are no outbound iATUs available, the code should return an error, as otherwise when this this feature is used, it will use an iATU index that is out of bounds. Fixes: e1a4ec1a9520 ("PCI: dwc: Add generic MSG TLP support for sending PME_Turn_Off when system suspend") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Maciej W. Rozycki Reviewed-by: Damien Le Moal Reviewed-by: Hans Zhang Reviewed-by: Frank Li Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260127151038.1484881-6-cassel@kernel.org Signed-off-by: Sasha Levin commit b6e5cef4d6df31f7e61f2e2713b3358a0b48f7e7 Author: Harry Yoo Date: Tue Jan 13 15:18:37 2026 +0900 mm/slab: use unsigned long for orig_size to ensure proper metadata align [ Upstream commit b85f369b81aed457acbea4ad3314218254a72fd2 ] When both KASAN and SLAB_STORE_USER are enabled, accesses to struct kasan_alloc_meta fields can be misaligned on 64-bit architectures. This occurs because orig_size is currently defined as unsigned int, which only guarantees 4-byte alignment. When struct kasan_alloc_meta is placed after orig_size, it may end up at a 4-byte boundary rather than the required 8-byte boundary on 64-bit systems. Note that 64-bit architectures without HAVE_EFFICIENT_UNALIGNED_ACCESS are assumed to require 64-bit accesses to be 64-bit aligned. See HAVE_64BIT_ALIGNED_ACCESS and commit adab66b71abf ("Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"") for more details. Change orig_size from unsigned int to unsigned long to ensure proper alignment for any subsequent metadata. This should not waste additional memory because kmalloc objects are already aligned to at least ARCH_KMALLOC_MINALIGN. Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo Suggested-by: Andrey Ryabinin Cc: stable@vger.kernel.org Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc") Signed-off-by: Harry Yoo Closes: https://lore.kernel.org/all/aPrLF0OUK651M4dk@hyeyoo/ Link: https://patch.msgid.link/20260113061845.159790-2-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit aac2fee7513dd25042a616f86a1469b4858d2c5c Author: Thomas Yen Date: Fri Jan 30 00:51:51 2026 +0800 scsi: ufs: core: Flush exception handling work when RPM level is zero [ Upstream commit f8ef441811ec413717f188f63d99182f30f0f08e ] Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence. Fixes: 57d104c153d3 ("ufs: add UFS power management support") Signed-off-by: Thomas Yen Cc: Stable Tree Reviewed-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260129165156.956601-1-thomasyen@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 00d69f21ef2ab00e6156c764d89e2b3539eb2f33 Author: Robin Murphy Date: Tue Feb 3 14:07:29 2026 +0000 perf/arm-cmn: Reject unsupported hardware configurations [ Upstream commit 36c0de02575ce59dfd879eb4ef63d53a68bbf9ce ] So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. Cc: stable@vger.kernel.org Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection") Reviewed-by: Ilkka Koskinen Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 65379adf7d231c930572db45933ff4538f4c5128 Author: Peng Fan Date: Thu Jan 29 09:44:48 2026 +0800 remoteproc: imx_rproc: Fix invalid loaded resource table detection [ Upstream commit 26aa5295010ffaebcf8f1991c53fa7cf2ee1b20d ] imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan Acked-by: Daniel Baluta Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit e00549dd86f5aaf04d14ba4822134cbc481adbd1 Author: jinbaohong Date: Wed Jan 28 07:06:38 2026 +0000 btrfs: continue trimming remaining devices on failure [ Upstream commit 912d1c6680bdb40b72b1b9204706f32b6eb842c3 ] Commit 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") intended to make device trimming continue even if one device fails, tracking failures and reporting them at the end. However, it used 'break' instead of 'continue', causing the loop to exit on the first device failure. Fix this by replacing 'break' with 'continue'. Fixes: 93bba24d4b5a ("btrfs: Enhance btrfs_trim_fs function to handle error better") CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2f926875dffe2226ea26d129e16d9092cccd03aa Author: Marek Vasut Date: Thu Jan 22 00:26:38 2026 +0100 clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841 [ Upstream commit 5ec820fc28d0b8a0f3890d476b1976f20e8343cc ] The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure there are 8 slots for those newly registered clk_hw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9_driver_data .clk_dif[4..7] field. Since there are other structure members past this struct clk_hw pointer array, writing to .clk_dif[4..7] fields corrupts both the struct rs9_driver_data content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend. Fix this, increase the struct clk_hw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver. Cc: stable@vger.kernel.org Fixes: f0e5e1800204 ("clk: rs9: Add support for 9FGV0841") Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVyQpOBT+Ho+mXY07fndFN9bKJdaaWGn91WOFnnYErLyg@mail.gmail.com Signed-off-by: Marek Vasut Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0ca20d699b642faf16baf78623e00e80b944e3eb Author: Marco Elver Date: Fri Jan 30 14:28:24 2026 +0100 arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y [ Upstream commit bb0c99e08ab9aa6d04b40cb63c72db9950d51749 ] The implementation of __READ_ONCE() under CONFIG_LTO=y incorrectly qualified the fallback "once" access for types larger than 8 bytes, which are not atomic but should still happen "once" and suppress common compiler optimizations. The cast `volatile typeof(__x)` applied the volatile qualifier to the pointer type itself rather than the pointee. This created a volatile pointer to a non-volatile type, which violated __READ_ONCE() semantics. Fix this by casting to `volatile typeof(*__x) *`. With a defconfig + LTO + debug options build, we see the following functions to be affected: xen_manage_runstate_time (884 -> 944 bytes) xen_steal_clock (248 -> 340 bytes) ^-- use __READ_ONCE() to load vcpu_runstate_info structs Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") Cc: stable@vger.kernel.org Reviewed-by: Boqun Feng Signed-off-by: Marco Elver Tested-by: David Laight Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 97c18f074ff1c12d016a0753072a3afdfa0b9611 Author: Niklas Schnelle Date: Tue Dec 16 23:14:03 2025 +0100 PCI/IOV: Fix race between SR-IOV enable/disable and hotplug [ Upstream commit a5338e365c4559d7b4d7356116b0eb95b12e08d5 ] Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") tried to fix a race between the VF removal inside sriov_del_vfs() and concurrent hot unplug by taking the PCI rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock was also taken in sriov_add_vfs() to protect addition of VFs. This approach however causes deadlock on trying to remove PFs with SR-IOV enabled because PFs disable SR-IOV during removal and this removal happens under the PCI rescan/remove lock. So the original fix had to be reverted. Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs hotplug higher up in the callchain by taking the lock in sriov_numvfs_store() before calling into the driver's sriov_configure() callback. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Reviewed-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-2-dac4925a7621@linux.ibm.com Signed-off-by: Sasha Levin commit d47f27e145f8bd13f3c230da5e3af29225b4a2f7 Author: Niklas Schnelle Date: Tue Dec 16 23:14:02 2025 +0100 Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV" [ Upstream commit 2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a ] This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of pci_stop_and_remove_bus_device(). For example with the following sequence of commands: $ echo > /sys/bus/pci/devices//sriov_numvfs $ echo 1 > /sys/bus/pci/devices//remove A trimmed trace of the deadlock on a mlx5 device is as below: zsh/5715 is trying to acquire lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140 but task is already holding lock: 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110 [<00000259779c844e>] print_deadlock_bug+0x31e/0x330 [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0 [<00000259779bffac>] lock_acquire+0x14c/0x350 [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520 [<000002597896413c>] mutex_lock_nested+0x3c/0x50 [<00000259784a07e4>] sriov_disable+0x34/0x140 [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core] [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core] [<00000259784857fc>] pci_device_remove+0x3c/0xa0 [<000002597851012e>] device_release_driver_internal+0x18e/0x280 [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0 [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80 [<00000259784972c2>] remove_store+0x72/0x90 [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200 [<0000025977d7241c>] vfs_write+0x24c/0x300 [<0000025977d72696>] ksys_write+0x86/0x110 [<000002597895b61c>] __do_syscall+0x14c/0x400 [<000002597896e0ee>] system_call+0x6e/0x90 This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on. Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") Reported-by: Benjamin Block Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Acked-by: Gerd Bayer Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-1-dac4925a7621@linux.ibm.com Signed-off-by: Sasha Levin commit 875355152b33436907c2a6d2ffad1431fa86c62b Author: Li Chen Date: Tue Jan 20 20:40:04 2026 +0800 kexec: derive purgatory entry from symbol [ Upstream commit 480e1d5c64bb14441f79f2eb9421d5e26f91ea3d ] kexec_load_purgatory() derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol. WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty: move helper to avoid forward declaration, per Baoquan] Link: https://lkml.kernel.org/r/20260128043511.316860-1-me@linux.beauty Link: https://lkml.kernel.org/r/20260120124005.148381-1-me@linux.beauty Fixes: 8652d44f466a ("kexec: support purgatories with .text.hot sections") Signed-off-by: Li Chen Acked-by: Baoquan He Cc: Alexander Graf Cc: Eric Biggers Cc: Li Chen Cc: Philipp Rudo Cc: Ricardo Ribalda Delgado Cc: Ross Zwisler Cc: Sourabh Jain Cc: Steven Rostedt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b2952dbeac2c3c527cb0519d5ffaeb95b062466a Author: Heming Zhao Date: Wed Dec 10 09:57:24 2025 +0800 ocfs2: fix reflink preserve cleanup issue [ Upstream commit 5138c936c2c82c9be8883921854bc6f7e1177d8c ] commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. Link: https://lkml.kernel.org/r/20251210015725.8409-2-heming.zhao@suse.com Fixes: 0fe9b66c65f3 ("ocfs2: Add preserve to reflink.") Signed-off-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 87272e3e70ec4b666885bd520ff77463c11444ef Author: Haoxiang Li Date: Wed Jan 21 09:35:08 2026 +0800 rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() [ Upstream commit 666183dcdd9ad3b8156a1df7f204f728f720380f ] When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer. Link: https://lkml.kernel.org/r/20260121013508.195836-1-lihaoxiang@isrc.iscas.ac.cn Fixes: e6b585ca6e81 ("rapidio: move net allocation into core code") Signed-off-by: Haoxiang Li Reviewed-by: Andrew Morton Cc: Alexandre Bounine Cc: Matt Porter Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 68b5efd6c6b374b70cb1e041aadfa8e6b4703ae6 Author: William Tambe Date: Thu Dec 11 12:38:19 2025 -0800 mm/highmem: fix __kmap_to_page() build error [ Upstream commit 94350fe6cad77b46c3dcb8c96543bef7647efbc0 ] This changes fixes following build error which is a miss from ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses"). mm/highmem.c:184:66: error: 'pteval' undeclared (first use in this function); did you mean 'pte_val'? 184 | idx = arch_kmap_local_map_idx(i, pte_pfn(pteval)); In __kmap_to_page(), pteval is used but does not exist in the function. (akpm: affects xtensa only) Link: https://lkml.kernel.org/r/SJ0PR07MB86317E00EC0C59DA60935FDCD18DA@SJ0PR07MB8631.namprd07.prod.outlook.com Fixes: ef6e06b2ef87 ("highmem: fix kmap_to_page() for kmap_local_page() addresses") Signed-off-by: William Tambe Reviewed-by: Max Filippov Cc: Chris Zankel Cc: Max Filippov Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 27d953201eae152f4445ca26f73bf01a06111901 Author: David LaPorte Date: Thu Jan 29 17:33:22 2026 -0800 mtd: spinand: Disable continuous read during probe [ Upstream commit b4af7d194dc879353829f3c56988a68fbba1fbdd ] Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level. With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition. All reads and writes that reference the BBT find no good blocks and fail. The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain. Disable continuous read explicitly during spinand probe to ensure quiescent feature state. Fixes: 631cfdd0520d ("mtd: spi-nand: Add continuous read support") Cc: stable@vger.kernel.org Signed-off-by: David LaPorte Reviewed-by: Gunnar Kudrjavets Reviewed-by: Mikhail Kshevetskiy Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 7037f3161a6daeb3936bde2ac1a832792f8c2393 Author: Antoniu Miclaus Date: Thu Jan 29 17:01:45 2026 +0200 iio: gyro: itg3200: Fix unchecked return value in read_raw [ Upstream commit b79b24f578cdb2d657db23e5fafe82c7e6a36b72 ] The return value from itg3200_read_reg_s16() is stored in ret but never checked. The function unconditionally returns IIO_VAL_INT, ignoring potential I2C read failures. This causes garbage data to be returned to userspace when the read fails, with no error reported. Add proper error checking to propagate the failure to callers. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ca46d2092f307385a7acfb42632056570d6dbbbc Author: Guangshuo Li Date: Tue Sep 23 21:32:35 2025 +0800 powerpc/smp: Add check for kcalloc() failure in parse_thread_groups() [ Upstream commit 33c1c6d8a28a2761ac74b0380b2563cf546c2a3a ] As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array(). Fixes: 790a1662d3a26 ("powerpc/smp: Parse ibm,thread-groups with multiple properties") Cc: stable@vger.kernel.org Reviewed-by: Christophe Leroy Signed-off-by: Guangshuo Li Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250923133235.1862108-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin commit ddb57354634b6ba851b79da45f1de42c646f27d0 Author: Eugenio Pérez Date: Mon Jan 19 15:32:54 2026 +0100 vhost: move vdpa group bound check to vhost_vdpa [ Upstream commit cd025c1e876b4e262e71398236a1550486a73ede ] Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them. While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write. Cc: stable@vger.kernel.org Fixes: bda324fd037a ("vdpasim: control virtqueue support") Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-2-eperezma@redhat.com> Signed-off-by: Sasha Levin commit 74a29a02ff653303138f71bacc3c5d7e163c98d4 Author: Leo Yan Date: Fri Jan 23 13:32:03 2026 +0000 tools: Fix bitfield dependency failure [ Upstream commit a537c0da168a08b0b6a7f7bd9e75f4cc8d45ff57 ] A perf build failure was reported by Thomas Voegtle on stable kernel v6.6.120: CC tests/sample-parsing.o CC util/intel-pt-decoder/intel-pt-pkt-decoder.o CC util/perf-regs-arch/perf_regs_csky.o CC util/arm-spe-decoder/arm-spe-pkt-decoder.o CC util/perf-regs-arch/perf_regs_loongarch.o In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.h:10, from util/arm-spe-decoder/arm-spe-pkt-decoder.c:14: /local/git/linux-stable-rc/tools/include/linux/bitfield.h: In function ‘le16_encode_bits’: /local/git/linux-stable-rc/tools/include/linux/bitfield.h:166:31: error: implicit declaration of function ‘cpu_to_le16’; did you mean ‘htole16’? [-Werror=implicit-function-declaration] ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ ^~~~~~~~~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:149:9: note: in definition of macro ‘____MAKE_OP’ return to((v & field_mask(field)) * field_multiplier(field)); \ ^~ /local/git/linux-stable-rc/tools/include/linux/bitfield.h:170:1: note: in expansion of macro ‘__MAKE_OP’ __MAKE_OP(16) Fix this by including linux/kernel.h, which provides the required definitions. The issue was not found on the mainline due to the relevant C files have included kernel.h. It'd be good to merge this change on mainline as well for robustness. Closes: https://lore.kernel.org/stable/3a44500b-d7c8-179f-61f6-e51cb50d3512@lio96.de/ Fixes: 64d86c03e1441742 ("perf arm-spe: Extend branch operations") Reported-by: Hamza Mahfooz Reported-by: Thomas Voegtle Signed-off-by: Leo Yan Cc: Greg Kroah-Hartman Cc: Ian Rogers Cc: James Clark Cc: Leo Yan Cc: Namhyung Kim To: Sasha Levin Cc: stable@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9bc366175509cc38076d1fecb0a436eeb99608d3 Author: Joey Gouly Date: Tue Jan 27 13:39:26 2026 +0000 arm64: poe: fix stale POR_EL0 values for ptrace [ Upstream commit 1f3b950492db411e6c30ee0076b61ef2694c100a ] If a process wrote to POR_EL0 and then crashed before a context switch happened, the coredump would contain an incorrect value for POR_EL0. The value read in poe_get() would be a stale value left in thread.por_el0. Fix this by reading the value from the system register, if the target thread is the current thread. This matches what gcs/fpsimd do. Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE") Reported-by: David Spickett Cc: stable@vger.kernel.org Signed-off-by: Joey Gouly Cc: Kevin Brodsky Cc: Mark Rutland Reviewed-by: Kevin Brodsky Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 052c611bcb283c97322855ce34f06c7a2103bbd8 Author: Benjamin Marzinski Date: Tue Jan 27 19:12:24 2026 -0500 dm mpath: make pg_init_delay_msecs settable [ Upstream commit 218b16992a37ea97b9e09b7659a25a864fb9976f ] "pg_init_delay_msecs X" can be passed as a feature in the multipath table and is used to set m->pg_init_delay_msecs in parse_features(). However, alloc_multipath_stage2(), which is called after parse_features(), resets m->pg_init_delay_msecs to its default value. Instead, set m->pg_init_delay_msecs in alloc_multipath(), which is called before parse_features(), to avoid overwriting a value passed in by the table. Signed-off-by: Benjamin Marzinski Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit a7733b51cd74b2bfb6ff3bb73572c3f46a44d89d Author: Haoxiang Li Date: Sat Jan 24 18:20:54 2026 +0800 bus: fsl-mc: fix an error handling in fsl_mc_device_add() [ Upstream commit 52f527d0916bcdd7621a0c9e7e599b133294d495 ] In fsl_mc_device_add(), device_initialize() is called first. put_device() should be called to drop the reference if error occurs. And other resources would be released via put_device -> fsl_mc_device_release. So remove redundant kfree() in error handling path. Fixes: bbf9d17d9875 ("staging: fsl-mc: Freescale Management Complex (fsl-mc) bus driver") Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/b767348e-d89c-416e-acea-1ebbff3bea20@stanley.mountain/ Signed-off-by: Su Hui Suggested-by: Christophe Leroy (CS GROUP) Signed-off-by: Haoxiang Li Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20260124102054.1613093-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit d1d07cbeca04944d9cac50fbc1112e1d0fbd8654 Author: Jens Axboe Date: Tue Jan 27 21:01:41 2026 -0700 io_uring/net: don't continue send bundle if poll was required for retry [ Upstream commit 806ae939c41e5da1d94a1e2b31f5702e96b6c3e3 ] If a send bundle has picked a bunch of buffers, then it needs to send all of those to be complete. This may require poll arming, if the send buffer ends up being full. Once a send bundle has been poll armed, no further bundles should be attempted. This allows a current bundle to complete even though it needs to go through polling to do so, but it will not allow another bundle to be started once that has happened. Ideally we would abort a bundle if it was only partially sent, but as some parts of it already went out on the wire, this obviously isn't feasible. Not continuing more bundle attempts post encountering a full socket buffer is the second best thing. Cc: stable@vger.kernel.org Fixes: a05d1f625c7a ("io_uring/net: support bundles for send") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 37b14e59db5d2d7bde6ee2a57006954ff40c96fe Author: Haotien Hsu Date: Sat Jan 24 01:31:21 2026 +0800 usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN [ Upstream commit 1132e90840abf3e7db11f1d28199e9fbc0b0e69e ] The COREPLL_PWRDN bit in the BLCG register must be set when the XUSB device controller is powergated and cleared when it is unpowergated. If this bit is not explicitly controlled, the core PLL may remain in an incorrect power state across suspend/resume or ELPG transitions. Therefore, update the driver to explicitly control this bit during powergate transitions. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable Signed-off-by: Haotien Hsu Signed-off-by: Wayne Chang Link: https://patch.msgid.link/20260123173121.4093902-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2efa9c02c9b4c0d6866aa445f11056809b25ca28 Author: Deepanshu Kartikey Date: Mon Jan 12 16:06:12 2026 +0530 mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node [ Upstream commit 5747435e0fd474c24530ef1a6822f47e7d264b27 ] When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions. The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299 Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section. Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load. Link: https://lkml.kernel.org/r/20260112103612.627247-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+d8d4c31d40f868eaea30@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d8d4c31d40f868eaea30 Link: https://lore.kernel.org/all/20260112084723.622910-1-kartikey406@gmail.com/T/ [v1] Suggested-by: Uladzislau Rezki Reviewed-by: Uladzislau Rezki (Sony) Cc: Hillf Danton Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f8f73bf0f8a57ee9b86792456bd42079bc98c6b7 Author: Harshit Mogalapalli Date: Tue Dec 30 22:16:09 2025 -0800 x86/kexec: add a sanity check on previous kernel's ima kexec buffer [ Upstream commit c5489d04337b47e93c0623e8145fcba3f5739efd ] When the second-stage kernel is booted via kexec with a limiting command line such as "mem=", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Link: https://lkml.kernel.org/r/20251231061609.907170-4-harshit.m.mogalapalli@oracle.com Signed-off-by: Harshit Mogalapalli Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb Reviewed-by: Mimi Zohar Cc: Alexander Graf Cc: Ard Biesheuvel Cc: Baoquan He Cc: Borislav Betkov Cc: guoweikang Cc: Henry Willard Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Bohac Cc: Joel Granados Cc: Jonathan McDowell Cc: Mike Rapoport Cc: Sohil Mehta Cc: Sourabh Jain Cc: Thomas Gleinxer Cc: Yifei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 77a31097d6df6bb489c4addf9f6b1a1479599250 Author: Krzysztof Kozlowski Date: Fri Jan 16 17:08:43 2026 +0000 nvmem: Drop OF node reference on nvmem_add_one_cell() failure [ Upstream commit f397bc0781553d01b4cdba506c09334a31cb0ec5 ] If nvmem_add_one_cell() failed, the ownership of "child" (or "info.np"), thus its OF reference, is not passed further and function should clean up by putting the reference it got via earlier of_node_get(). Note that this is independent of references obtained via for_each_child_of_node() loop. Fixes: 50014d659617 ("nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260116170846.733558-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 982815bb04553544fe173248ddc659e1c8c1628e Author: Anthony Iliopoulos Date: Mon Dec 22 14:30:05 2025 -0500 nfsd: fix return error code for nfsd_map_name_to_[ug]id [ Upstream commit 404d779466646bf1461f2090ff137e99acaecf42 ] idmap lookups can time out while the cache is waiting for a userspace upcall reply. In that case cache_check() returns -ETIMEDOUT to callers. The nfsd_map_name_to_[ug]id functions currently proceed with attempting to map the id to a kuid despite a potentially temporary failure to perform the idmap lookup. This results in the code returning the error NFSERR_BADOWNER which can cause client operations to return to userspace with failure. Fix this by returning the failure status before attempting kuid mapping. This will return NFSERR_JUKEBOX on idmap lookup timeout so that clients can retry the operation instead of aborting it. Fixes: 65e10f6d0ab0 ("nfsd: Convert idmap to use kuids and kgids") Cc: stable@vger.kernel.org Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit a437e3bf30e32846079e470c1ba5ee790bccdf89 Author: Jack Wang Date: Tue Jan 20 11:24:56 2026 +0100 md/bitmap: fix GPF in write_page caused by resize race [ Upstream commit 46ef85f854dfa9d5226b3c1c46493d79556c9589 ] A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update. Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u Cc: stable@vger.kernel.org Fixes: d60b479d177a ("md/bitmap: add bitmap_resize function to allow bitmap resizing.") Signed-off-by: Jack Wang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d69de525bc7ab27713342080bf50826df3f6a68f Author: Darrick J. Wong Date: Fri Jan 23 09:27:40 2026 -0800 xfs: check for deleted cursors when revalidating two btrees [ Upstream commit 55e03b8cbe2783ec9acfb88e8adb946ed504e117 ] The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem. Cc: r772577952@gmail.com Link: https://lore.kernel.org/linux-xfs/CANypQFYU5rRPkTy=iG5m1Lp4RWasSgrHXAh3p8YJojxV0X15dQ@mail.gmail.com/T/#m520c7835fad637eccf843c7936c200589427cc7e Cc: # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit d6f3f7d4dd8a179394cef03c00993d57f5f68601 Author: Darrick J. Wong Date: Fri Jan 23 09:27:38 2026 -0800 xfs: check return value of xchk_scrub_create_subord [ Upstream commit ca27313fb3f23e4ac18532ede4ec1c7cc5814c4a ] Fix this function to return NULL instead of a mangled ENOMEM, then fix the callers to actually check for a null pointer and return ENOMEM. Most of the corrections here are for code merged between 6.2 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: 1a5f6e08d4e379 ("xfs: create subordinate scrub contexts for xchk_metadata_inode_subtype") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit 5de5be3ed7e7fa4ebde4f4b58fb9a629644f9202 Author: Darrick J. Wong Date: Fri Jan 23 09:27:37 2026 -0800 xfs: only call xf{array,blob}_destroy if we have a valid pointer [ Upstream commit ba408d299a3bb3c5309f40c5326e4fb83ead4247 ] Only call the xfarray and xfblob destructor if we have a valid pointer, and be sure to null out that pointer afterwards. Note that this patch fixes a large number of commits, most of which were merged between 6.9 and 6.10. Cc: r772577952@gmail.com Cc: # v6.12 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Tested-by: Jiaming Zhang Signed-off-by: Sasha Levin commit 078e78821d91a8ed42c338ed3cf008f198865513 Author: Raag Jadav Date: Sat Jan 24 13:44:54 2026 +0530 pinctrl: intel: Add code name documentation [ Upstream commit fc32c5725fbe1164d353400389d3e29d19960a3a ] Intel pinctrl drivers support large set of platforms and the IPs are often reused by their different variants, but it's currently not possible to figure out the exact driver that supports specific variant. Add user friendly documentation for them. Cc: stable@vger.kernel.org Reported-by: Guido Trentalancia Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220056 Signed-off-by: Raag Jadav Acked-by: Mika Westerberg Acked-by: Guido Trentalancia [andy: added Oxford comma] Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 339191811e6fc4559c4008c5af7a91b05086d596 Author: Manikanta Maddireddy Date: Thu Jan 8 11:57:47 2026 +0530 PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions [ Upstream commit 8754dd7639ab0fd68c3ab9d91c7bdecc3e5740a8 ] struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate two EPCs with EPF") Signed-off-by: Manikanta Maddireddy [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260108062747.1870669-1-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 9f2bfea51151dfbb24b52f452eb3d5f5fe0e506e Author: Vasiliy Kovalev Date: Sat Jan 24 01:28:01 2026 +0300 KVM: x86: Add SRCU protection for reading PDPTRs in __get_sregs2() [ Upstream commit 95d848dc7e639988dbb385a8cba9b484607cf98c ] Add SRCU read-side protection when reading PDPTR registers in __get_sregs2(). Reading PDPTRs may trigger access to guest memory: kvm_pdptr_read() -> svm_cache_reg() -> load_pdptrs() -> kvm_vcpu_read_guest_page() -> kvm_vcpu_gfn_to_memslot() kvm_vcpu_gfn_to_memslot() dereferences memslots via __kvm_memslots(), which uses srcu_dereference_check() and requires either kvm->srcu or kvm->slots_lock to be held. Currently only vcpu->mutex is held, triggering lockdep warning: ============================= WARNING: suspicious RCU usage in kvm_vcpu_gfn_to_memslot 6.12.59+ #3 Not tainted include/linux/kvm_host.h:1062 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.5.1717/15100: #0: ff1100002f4b00b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x1d5/0x1590 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xf0/0x120 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x1e3/0x270 kernel/locking/lockdep.c:6824 __kvm_memslots include/linux/kvm_host.h:1062 [inline] __kvm_memslots include/linux/kvm_host.h:1059 [inline] kvm_vcpu_memslots include/linux/kvm_host.h:1076 [inline] kvm_vcpu_gfn_to_memslot+0x518/0x5e0 virt/kvm/kvm_main.c:2617 kvm_vcpu_read_guest_page+0x27/0x50 virt/kvm/kvm_main.c:3302 load_pdptrs+0xff/0x4b0 arch/x86/kvm/x86.c:1065 svm_cache_reg+0x1c9/0x230 arch/x86/kvm/svm/svm.c:1688 kvm_pdptr_read arch/x86/kvm/kvm_cache_regs.h:141 [inline] __get_sregs2 arch/x86/kvm/x86.c:11784 [inline] kvm_arch_vcpu_ioctl+0x3e20/0x4aa0 arch/x86/kvm/x86.c:6279 kvm_vcpu_ioctl+0x856/0x1590 virt/kvm/kvm_main.c:4663 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xbd/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Sean Christopherson Cc: stable@vger.kernel.org Fixes: 6dba94035203 ("KVM: x86: Introduce KVM_GET_SREGS2 / KVM_SET_SREGS2") Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20260123222801.646123-1-kovalev@altlinux.org Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 1c9b6aad70e56c226a4d6ea6a8dda914025da269 Author: Darrick J. Wong Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix remote xattr valuelblk check [ Upstream commit bd3138e8912c9db182eac5fed1337645a98b7a4f ] In debugging other problems with generic/753, it turns out that it's possible for the system go to down in the middle of a remote xattr set operation such that the leaf block entry is marked incomplete and valueblk is set to zero. Make this no longer a failure. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 084d39d7847f60bfd7b0494180ec7945bf7f735b Author: Darrick J. Wong Date: Fri Jan 23 09:27:33 2026 -0800 xfs: fix the xattr scrub to detect freemap/entries array collisions [ Upstream commit 6fed8270448c246e706921c177e9633013dd3fcf ] In the previous patches, we observed that it's possible for there to be freemap entries with zero size but a nonzero base. This isn't an inconsistency per se, but older kernels can get confused by this and corrupt the block, leading to corruption. If we see this, flag the xattr structure for optimization so that it gets rebuilt. Cc: # v4.15 Fixes: 13791d3b833428 ("xfs: scrub extended attribute leaf space") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ef42a8766ff3fdf51cf72fb36d0859c09d134478 Author: Darrick J. Wong Date: Fri Jan 23 09:27:31 2026 -0800 xfs: fix freemap adjustments when adding xattrs to leaf blocks [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e1b8c6452ee99a30e188a88f3f3f804fb1c6004a Author: Darrick J. Wong Date: Fri Jan 23 09:27:30 2026 -0800 xfs: delete attr leaf freemap entries when empty [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a40f316085985f916ba1599fc303fdbc6a078e86 Author: Francesco Lavra Date: Mon Jan 19 11:23:16 2026 +0100 iio: accel: adxl380: Avoid reading more entries than present in FIFO [ Upstream commit c1b14015224cfcccd5356333763f2f4f401bd810 ] The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present. To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 90cde30d881594615fa808e94a344e53f35bbcbb Author: Johan Hovold Date: Fri Dec 19 12:07:14 2025 +0100 mfd: omap-usb-host: Fix OF populate on driver rebind [ Upstream commit 24804ba508a3e240501c521685a1c4eb9f574f8e ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251219110714.23919-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 428cfd5d5a5066a615db72d28d10ea80a879cf14 Author: Johan Hovold Date: Fri Dec 19 12:09:47 2025 +0100 mfd: qcom-pm8xxx: Fix OF populate on driver rebind [ Upstream commit 27a8acea47a93fea6ad0e2df4c20a9b51490e4d9 ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20251219110947.24101-1-johan@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit db131ef9d8980cf60dcac8cf94c036eccf75e5d0 Author: Douglas Anderson Date: Wed Dec 10 11:30:03 2025 -0800 mfd: core: Add locking around 'mfd_of_node_list' [ Upstream commit 20117c92bcf9c11afd64d7481d8f94fdf410726e ] Manipulating a list in the kernel isn't safe without some sort of mutual exclusion. Add a mutex any time we access / modify 'mfd_of_node_list' to prevent possible crashes. Cc: stable@vger.kernel.org Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251210113002.1.I6ceaca2cfb7eb25737012b166671f516696be4fd@changeid Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9813306610d0d718c863aaa70928bf57d7570ec0 Author: Jinhui Guo Date: Thu Jan 22 09:48:51 2026 +0800 iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode [ Upstream commit 10e60d87813989e20eac1f3eda30b3bae461e7f9 ] Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions. Fixes: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo Link: https://lore.kernel.org/r/20251211035946.2071-3-guojinhui.liam@bytedance.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 34f36f9c6114af781a5a4f7a7c99334c85b73fc7 Author: Benjamin Gaignard Date: Wed Jan 14 10:07:10 2026 +0100 media: verisilicon: AV1: Fix tile info buffer size [ Upstream commit a505ca2db89ad92a8d8d27fa68ebafb12e04a679 ] Each tile info is composed of: row_sb, col_sb, start_pos and end_pos (4 bytes each). So the total required memory is AV1_MAX_TILES * 16 bytes. Use the correct #define to allocate the buffer and avoid writing tile info in non-allocated memory. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2fbc8421d1db102c0e5458607e042a23a03648b1 Author: Christoph Hellwig Date: Fri Jan 9 16:17:40 2026 +0100 xfs: remove xfs_attr_leaf_hasname [ Upstream commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 ] The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values. Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read. Cc: stable@vger.kernel.org # v5.19+ Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Reported-by: Mark Tinguely Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 3628a1a38404822c820e4b467381e282daae931e Author: Darrick J. Wong Date: Thu Dec 18 18:40:50 2025 -0800 xfs: mark data structures corrupt on EIO and ENODATA [ Upstream commit f39854a3fb2f06dc69b81ada002b641ba5b4696b ] I learned a few things this year: first, blk_status_to_errno can return ENODATA for critical media errors; and second, the scrub code doesn't mark data structures as corrupt on ENODATA or EIO. Currently, scrub failing to capture these errors isn't all that impactful -- the checking code will exit to userspace with EIO/ENODATA, and xfs_scrub will log a complaint and exit with nonzero status. Most people treat fsck tools failing as a sign that the fs is corrupt, but online fsck should mark the metadata bad and keep moving. Cc: stable@vger.kernel.org # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 96775be9f12f6a97d1ac16979439dc35b7555b67 Author: Loic Poulain Date: Thu Dec 18 16:13:07 2025 +0100 drm/bridge: anx7625: Fix invalid EDID size [ Upstream commit 1d5362145de96b5d00d590605cc94cdfa572b405 ] DRM checks EDID block count against allocated size in drm_edid_valid function. We have to allocate the right EDID size instead of the max size to prevent the EDID to be reported as invalid. Cc: stable@kernel.org Fixes: 7c585f9a71aa ("drm/bridge: anx7625: use struct drm_edid more") Reviewed-by: Dmitry Baryshkov Signed-off-by: Loic Poulain Link: https://patch.msgid.link/20251218151307.95491-1-loic.poulain@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d764b8dd420098a4d253b8a5b27568c897edb2cf Author: Sanjay Yadav Date: Thu Jan 8 17:02:29 2026 +0530 drm/buddy: Prevent BUG_ON by validating rounded allocation [ Upstream commit 5488a29596cdba93a60a79398dc9b69d5bdadf92 ] When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) = 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) = 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712 Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Cc: # v6.7+ Cc: Christian König Cc: Arunpravin Paneer Selvam Suggested-by: Matthew Auld Signed-off-by: Sanjay Yadav Reviewed-by: Matthew Auld Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260108113227.2101872-5-sanjay.kumar.yadav@intel.com Signed-off-by: Sasha Levin commit 51d54ff2b75041dcedf71ef16e13c1cfd5b85e72 Author: Li Wang Date: Sun Dec 21 20:26:38 2025 +0800 selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs [ Upstream commit 1aa1dd9cc595917882fb6db67725442956f79607 ] charge_reserved_hugetlb.sh mounts a hugetlbfs instance at /mnt/huge with a fixed size of 256M. On systems with large base hugepages (e.g. 512MB), this is smaller than a single hugepage, so the hugetlbfs mount ends up with zero capacity (often visible as size=0 in mount output). As a result, write_to_hugetlbfs fails with ENOMEM and the test can hang waiting for progress. === Error log === # uname -r 6.12.0-xxx.el10.aarch64+64k #./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages = 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ... # mount |grep /mnt/huge none on /mnt/huge type hugetlbfs (rw,relatime,seclabel,pagesize=512M,size=0) # grep -i huge /proc/meminfo ... HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 524288 kB Hugetlb: 5242880 kB Drop the mount args with 'size=256M', so the filesystem capacity is sufficient regardless of HugeTLB page size. Link: https://lkml.kernel.org/r/20251221122639.3168038-3-liwang@redhat.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Li Wang Acked-by: David Hildenbrand (Red Hat) Acked-by: Waiman Long Cc: Mark Brown Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 11165f420b2a7994b2fd53ce2cc0d470a102633b Author: Vlastimil Babka Date: Fri Dec 19 17:31:57 2025 +0100 mm, page_alloc, thp: prevent reclaim for __GFP_THISNODE THP allocations [ Upstream commit 9c9828d3ead69416d731b1238802af31760c823e ] Since commit cc638f329ef6 ("mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations"), THP page fault allocations have settled on the following scheme (from the commit log): 1. local node only THP allocation with no reclaim, just compaction. 2. for madvised VMA's or when synchronous compaction is enabled always - THP allocation from any node with effort determined by global defrag setting and VMA madvise 3. fallback to base pages on any node Recent customer reports however revealed we have a gap in step 1 above. What we have seen is excessive reclaim due to THP page faults on a NUMA node that's close to its high watermark, while other nodes have plenty of free memory. The problem with step 1 is that it promises no reclaim after the compaction attempt, however reclaim is only avoided for certain compaction outcomes (deferred, or skipped due to insufficient free base pages), and not e.g. when compaction is actually performed but fails (we did see compact_fail vmstat counter increasing). THP page faults can therefore exhibit a zone_reclaim_mode-like behavior, which is not the intention. Thus add a check for __GFP_THISNODE that corresponds to this exact situation and prevents continuing with reclaim/compaction once the initial compaction attempt isn't successful in allocating the page. Note that commit cc638f329ef6 has not introduced this over-reclaim possibility; it appears to exist in some form since commit 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations"). Followup commits b39d0ee2632d ("mm, page_alloc: avoid expensive reclaim when compaction may not succeed") and cc638f329ef6 have moved in the right direction, but left the abovementioned gap. Link: https://lkml.kernel.org/r/20251219-costly-noretry-thisnode-fix-v1-1-e1085a4a0c34@suse.cz Fixes: 2f0799a0ffc0 ("mm, thp: restore node-local hugepage allocations") Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Pedro Falcato Acked-by: Zi Yan Cc: Brendan Jackman Cc: "David Hildenbrand (Red Hat)" Cc: David Rientjes Cc: Joshua Hahn Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cbae775b2265068f9ae5cd8967e9df9011c692db Author: Luca Ceresoli Date: Fri Jan 9 08:31:32 2026 +0100 drm: of: drm_of_panel_bridge_remove(): fix device_node leak [ Upstream commit a4b4385d0523e39a7c058cb5a6c8269e513126ca ] drm_of_panel_bridge_remove() uses of_graph_get_remote_node() to get a device_node but does not put the node reference. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: stable@vger.kernel.org # v4.15 Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-1-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 087d915bb1eaf1c498a6214bcf7bb26dd85dc35b Author: Dikshita Agarwal Date: Tue Nov 25 11:04:19 2025 +0530 media: venus: vdec: restrict EOS addr quirk to IRIS2 only [ Upstream commit 63c072e2937e6c9995df1b6a28523ed2ae68d364 ] On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could not handle a dummy device address for EOS buffers, so a NULL device address is sent instead. The existing check used IS_V6() alongside a firmware version gate: if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87)) fdata.device_addr = 0; else fdata.device_addr = 0xdeadb000; However, SC7280 which is also V6, uses a firmware string of the form "1.0.", which the version parser translates to 1.0.0. This unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)` condition on SC7280. Combined with IS_V6() matching there as well, the quirk is incorrectly applied to SC7280, causing VP9 decode failures. Constrain the check to IRIS2 (SM8250) only, which is the only platform that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This restores correct behavior on SC7280 (no forced NULL EOS buffer address). Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command") Cc: stable@vger.kernel.org Reported-by: Mecid Closes: https://github.com/qualcomm-linux/kernel-topics/issues/222 Co-developed-by: Renjiang Han Signed-off-by: Renjiang Han Signed-off-by: Dikshita Agarwal Tested-by: Renjiang Han Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 99cf4a8fbf9e5d03898e317a3196c999270833f2 Author: Renjiang Han Date: Thu Dec 11 15:20:39 2025 +0530 media: venus: vdec: fix error state assignment for zero bytesused [ Upstream commit 93ecd6ee95c38cb533fa25f48d3c1c8cb69f410f ] When hfi_session_flush is issued, all queued buffers are returned to the V4L2 driver. Some of these buffers are not processed and have bytesused = 0. Currently, the driver marks such buffers as error even during drain operations, which can incorrectly flag EOS buffers. Only capture buffers with zero payload (and not EOS) should be marked with VB2_BUF_STATE_ERROR. The check is performed inside the non-EOS branch to ensure correct handling. Fixes: 51df3c81ba10b ("media: venus: vdec: Mark flushed buffers with error state") Signed-off-by: Renjiang Han Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 63922c96e13754a0e0cd7f5c06ac92536b6feb03 Author: Jun Yan Date: Fri Jan 16 23:12:53 2026 +0800 arm64: dts: rockchip: Do not enable hdmi_sound node on Pinebook Pro [ Upstream commit b18247f9dab735c9c2d63823d28edc9011e7a1ad ] Remove the redundant enabling of the hdmi_sound node in the Pinebook Pro board dts file, because the HDMI output is unused on this device. [1][2] This change also eliminates the following kernel log warning, which is caused by the unenabled dependent node of hdmi_sound that ultimately results in the node's probe failure: platform hdmi-sound: deferred probe pending: asoc-simple-card: parse error [1] https://files.pine64.org/doc/PinebookPro/pinebookpro_v2.1_mainboard_schematic.pdf [2] https://files.pine64.org/doc/PinebookPro/pinebookpro_schematic_v21a_20220419.pdf Cc: stable@vger.kernel.org Fixes: 5a65505a69884 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Signed-off-by: Jun Yan Reviewed-by: Peter Robinson Reviewed-by: Dragan Simic Link: https://patch.msgid.link/20260116151253.9223-1-jerrysteve1101@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fbcc04ad7aeca2d98f70da2d610bb7c892cfdc74 Author: Matt Whitlock Date: Sun Jan 18 13:36:15 2026 -0500 dm-unstripe: fix mapping bug when there are multiple targets in a table [ Upstream commit 83c10e8dd43628d0bf86486616556cd749a3c310 ] The "unstriped" device-mapper target incorrectly calculates the sector offset on the mapped device when the target's origin is not zero. Take for example this hypothetical concatenation of the members of a two-disk RAID0: linearized: 0 2097152 unstriped 2 128 0 /dev/md/raid0 0 linearized: 2097152 2097152 unstriped 2 128 1 /dev/md/raid0 0 The intent in this example is to create a single device named /dev/mapper/linearized that comprises all of the chunks of the first disk of the RAID0 set, followed by all of the chunks of the second disk of the RAID0 set. This fails because dm-unstripe.c's map_to_core function does its computations based on the sector number within the mapper device rather than the sector number within the target. The bug turns invisible when the target's origin is at sector zero of the mapper device, as is the common case. In the example above, however, what happens is that the first half of the mapper device gets mapped correctly to the first disk of the RAID0, but the second half of the mapper device gets mapped past the end of the RAID0 device, and accesses to any of those sectors return errors. Signed-off-by: Matt Whitlock Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Sasha Levin commit c6138af1f5454c2631a837916fda958ea72c0d71 Author: Mikulas Patocka Date: Mon Jan 19 15:06:02 2026 +0100 dm-integrity: fix recalculation in bitmap mode [ Upstream commit 118ba36e446c01e3cd34b3eedabf1d9436525e1d ] There's a logic quirk in the handling of suspend in the bitmap mode: This is the sequence of calls if we are reloading a dm-integrity table: * dm_integrity_ctr reads a superblock with the flag SB_FLAG_DIRTY_BITMAP set. * dm_integrity_postsuspend initializes a journal and clears the flag SB_FLAG_DIRTY_BITMAP. * dm_integrity_resume sees the superblock with SB_FLAG_DIRTY_BITMAP set - thus it interprets the journal as if it were a bitmap. This quirk causes recalculation problem if the user increases the size of the device in the bitmap mode. Fix this by reading a fresh copy on the superblock in dm_integrity_resume. This commit also fixes another logic quirk - the branch that sets bitmap bits if the device was extended should only be executed if the flag SB_FLAG_DIRTY_BITMAP is set. Signed-off-by: Mikulas Patocka Tested-by: Ondrej Kozina Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 09d6efc6abd42809956d598906c222ccd1c8ae92 Author: Bartosz Golaszewski Date: Thu Dec 4 10:44:12 2025 +0100 reset: gpio: suppress bind attributes in sysfs [ Upstream commit 16de4c6a8fe9ff497ca1aba33ef0dbee09f11952 ] This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit f0cddb616f7543df7713dc70e3d8c4fada243b29 Author: Niklas Schnelle Date: Thu Jan 8 16:45:53 2026 +0100 s390/pci: Handle futile config accesses of disabled devices directly [ Upstream commit 84d875e69818bed600edccb09be4a64b84a34a54 ] On s390 PCI busses and slots with multiple functions may have holes because PCI functions are passed-through by the hypervisor on a per function basis and some functions may be in standby or reserved. This fact is indicated by returning true from the hypervisor_isolated_pci_functions() helper and triggers common code to scan all possible devfn values. Via pci_scan_single_device() this in turn causes config reads for the device and vendor IDs, even for PCI functions which are in standby and thereofore disabled. So far these futile config reads, as well as potentially writes, which can never succeed were handled by the PCI load/store instructions themselves. This works as the platform just returns an error for a disabled and thus not usable function handle. It does cause spamming of error logs and additional overhead though. Instead check if the used function handle is enabled in zpci_cfg_load() and zpci_cfg_write() and if not enable directly return -ENODEV. Also refactor zpci_cfg_load() and zpci_cfg_store() slightly to accommodate the new logic while meeting modern kernel style guidelines. Cc: stable@vger.kernel.org Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle Reviewed-by: Benjamin Block Reviewed-by: Farhan Ali Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 5aa2b04500314932e53bfefad2796c13f2394554 Author: Haoxiang Li Date: Thu Jan 15 13:05:42 2026 +0800 clk: tegra: tegra124-emc: Fix potential memory leak in tegra124_clk_register_emc() [ Upstream commit fce0d0bd9c20fefd180ea9e8362d619182f97a1d ] If clk_register() fails, call kfree to release "tegra". Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Brian Masney Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit d5952a3bfdd6b182b3a716861dfa303ab5147a8b Author: Mehdi Djait Date: Thu Jan 8 14:57:38 2026 +0100 media: i2c: ov01a10: Fix digital gain range [ Upstream commit 91848c99ed6a98daf77f4cb7d44cf3f13bc6998f ] Digital gain wraps-around at the maximum of 16838 / 0x3fff. Fix the maximum digital gain by setting it to 0x3fff. Signed-off-by: Mehdi Djait Reviewed-by: Hans de Goede Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 330d37a24ecb02b406ae864a9c4c82269c5d3145 Author: Alain Volmat Date: Fri Dec 19 15:30:35 2025 +0100 media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop [ Upstream commit 222f1279edd9008ee35b62de156ddac84e31443c ] Ensure that there are no pending interrupts after we have stopped the pipeline. Indeed, it could happen that new interrupt has been generated during the stop_streaming processing hence clear them in order to avoid getting a new interrupt right from the start of a next start_streaming. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit bac9fc78f367ad330bf00fc8f291eca923c60c8a Author: Shawn Lin Date: Fri Jan 16 08:55:29 2026 +0800 soc: rockchip: grf: Support multiple grf to be handled [ Upstream commit 75fb63ae031211e9264ac888fabc2ca9cd3fcccf ] Currently, only the first matched node will be handled. This leads to jtag switching broken for RK3576, as rk3576-sys-grf is found before rk3576-ioc-grf. Change the code to scan all the possible node to fix the problem. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-3-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 61dfbb6bb9ee57cd144e67b7087ea17c5be5b34e Author: Shawn Lin Date: Fri Jan 16 08:55:28 2026 +0800 soc: rockchip: grf: Fix wrong RK3576_IOCGRF_MISC_CON definition [ Upstream commit 3cdc30c42d4a87444f6c7afbefd6a9381c4caa27 ] RK3576_IOCGRF_MISC_CON is IOC_GRF + 0x40F0, fix it. Fixes: e1aaecacfa13 ("soc: rockchip: grf: Add rk3576 default GRF values") Cc: stable@vger.kernel.org Cc: Detlev Casanova Signed-off-by: Shawn Lin Reviewed-by: Chaoyi Chen Tested-by: Marco Schirrmeister Link: https://patch.msgid.link/1768524932-163929-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 5059221d2ead684d1c944b1f80be6a7e65662191 Author: Janne Grunau Date: Wed Dec 31 13:22:00 2025 +0100 clk: clk-apple-nco: Add "apple,t8103-nco" compatible [ Upstream commit ef9b3b4dbe767e4ac642a88dc0507927ac545047 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nco" anymore [1]. Use "apple,t8103-nco" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Cc: stable@vger.kernel.org Acked-by: Stephen Boyd Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5b958dfe278f6b2cd98326da89dff8d82c90ad88 Author: Johan Hovold Date: Fri Dec 19 12:01:19 2025 +0100 bus: omap-ocp2scp: fix OF populate on driver rebind [ Upstream commit 5eb63e9bb65d88abde647ced50fe6ad40c11de1a ] Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251219110119.23507-1-johan@kernel.org Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit fce2fd4a2ca05670a91015aacccf96a1c26268fd Author: Yosry Ahmed Date: Sat Jan 10 00:48:18 2026 +0000 KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation [ Upstream commit 127ccae2c185f62e6ecb4bf24f9cb307e9b9c619 ] Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB. Fixes: cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") Cc: Maxim Levitsky Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260110004821.3411245-2-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 69aa67c1e22d13e9aad4b08c86304ad8e743dcab Author: Wentao Liang Date: Tue Jan 13 01:47:16 2026 +0000 soc: ti: pruss: Fix double free in pruss_clk_mux_setup() [ Upstream commit 80db65d4acfb9ff12d00172aed39ea8b98261aad ] In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_put(). Fixes: ba59c9b43c86 ("soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260113014716.2464741-1-vulab@iscas.ac.cn Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit eaa16059f9af26d8b8a6f3e887649f58e8ca96c9 Author: Johan Hovold Date: Thu Nov 27 14:49:42 2025 +0100 soc: ti: k3-socinfo: Fix regmap leak on probe failure [ Upstream commit c933138d45176780fabbbe7da263e04d5b3e525d ] The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a5caf03188e4 ("soc: ti: k3-socinfo: Do not use syscon helper to build regmap") Cc: stable@vger.kernel.org # 6.15 Cc: Andrew Davis Signed-off-by: Johan Hovold Acked-by: Andrew Davis Link: https://patch.msgid.link/20251127134942.2121-1-johan@kernel.org Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit e2e738e8dfbbf83bd2bae0467ec4420cc52da42a Author: Michael Liang Date: Fri Jan 9 15:52:54 2026 -0700 dm: clear cloned request bio pointer when last clone bio completes [ Upstream commit fb8a6c18fb9a6561f7a15b58b272442b77a242dd ] Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios. Signed-off-by: Michael Liang Reviewed-by: Mohamed Khalfella Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b95a9810c38c16b567ddd38181a5ebff76c6fdb9 Author: Mikulas Patocka Date: Mon Jan 12 21:15:27 2026 +0100 dm-integrity: fix a typo in the code for write/discard race [ Upstream commit c698b7f417801fcd79f0dc844250b3361d38e6b8 ] If we send a write followed by a discard, it may be possible that the discarded data end up being overwritten by the previous write from the journal. The code tries to prevent that, but there was a typo in this logic that made it not being activated as it should be. Note that if we end up here the second time (when discard_retried is true), it means that the write bio is actually racing with the discard bio, and in this situation it is not specified which of them should win. Cc: stable@vger.kernel.org Fixes: 31843edab7cb ("dm integrity: improve discard in journal mode") Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit e438caff813fa0b96e7efdf68c759c3fbd9f1a86 Author: Srinivas Pandruvada Date: Tue Jan 6 22:02:55 2026 -0800 platform/x86: ISST: Add missing write block check [ Upstream commit 0e5aef2795008c80c515f6fa04e377c6e5715958 ] If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked feature status") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit fdc06d36dab7b28c2bdd16cb7ee4f25e0f55d9ac Author: Bingbu Cao Date: Tue Dec 23 15:22:59 2025 +0800 media: ipu6: Fix RPM reference leak in probe error paths [ Upstream commit 6099f78e4c9223f4de4169d2fd1cded01279da1a ] Several error paths in ipu6_pci_probe() were jumping directly to out_ipu6_bus_del_devices without releasing the runtime PM reference. Add pm_runtime_put_sync() before cleaning up other resources. Cc: Stable@vger.kernel.org Fixes: 25fedc021985 ("media: intel/ipu6: add Intel IPU6 PCI device driver") Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 92019e41c1fed810811405f59c02322e977bb7f2 Author: Bingbu Cao Date: Tue Dec 23 15:22:58 2025 +0800 media: ipu6: Fix typo and wrong constant in ipu6-mmu.c [ Upstream commit 3e0fcc91277d5af114a58aaa68f34b44e8d8a411 ] Fix two coding errors in ipu6-mmu.c: 1. Fix syntax error in page_table_dump() where the closing parenthesis and semicolon were swapped in the TBL_PHYS_ADDR macro call. 2. Fix incorrect loop bound in alloc_l2_pt(). When initializing L2 page table entries, the loop was incorrectly using ISP_L1PT_PTES instead of ISP_L2PT_PTES. Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Cc: stable@vger.kernel.org Signed-off-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 13aa594f5f7e37372cbac1d404c21ec8ecd77873 Author: Xiaolei Wang Date: Fri Dec 5 15:19:18 2025 +0800 media: i2c: ov5647: use our own mutex for the ctrl lock [ Upstream commit 973e42fd5d2b397bff34f0c249014902dbf65912 ] __v4l2_ctrl_handler_setup() and __v4l2_ctrl_modify_range() contains an assertion to verify that the v4l2_ctrl_handler::lock is held, as it should only be called when the lock has already been acquired. Therefore use our own mutex for the ctrl lock, otherwise a warning will be reported. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang [Sakari Ailus: Fix a minor conflict.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e83c4debf2c13be9ad056f7a9ec154e8c9e25429 Author: Sakari Ailus Date: Tue Dec 30 19:22:02 2025 +0200 media: ccs: Fix setting initial sub-device state [ Upstream commit 31e5191aa11931b53e1242acef4f4375f00ca523 ] Fix setting sub-device state for non-source sub-devices. Fixes: 5755be5f15d9 ("media: v4l2-subdev: Rename .init_cfg() operation to .init_state()") Cc: stable@vger.kernel.org # for v6.8 and later Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ecba356cd7c60d25e54423fac18c7bbb8a551163 Author: Jai Luthra Date: Mon Dec 22 13:45:29 2025 +0530 media: i2c: ov5647: Fix PIXEL_RATE value for VGA mode [ Upstream commit c063632b494b02e891442d10f17e37b7fcfab9b3 ] The pixel rate for VGA (640x480) mode is configured in the mode's table to be 58.333 MPix/s instead of 55 MPix/s, so fix it. Fixes: 911f4516ee2b ("media: ov5647: Support V4L2_CID_PIXEL_RATE") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CAPY8ntA2TCf9FuB6Nk%2BOn%2By6N_PMuYPAOAr3Yx8YESwe4skWvw@mail.gmail.com/ Suggested-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fbf2a108ed5eb1c896d3f354bd05314c2e22e78f Author: David Plowman Date: Mon Dec 22 13:45:28 2025 +0530 media: i2c: ov5647: Sensor should report RAW color space [ Upstream commit f007586b1e89dcea40168415d0422cb7a0fc31b1 ] As this sensor captures RAW bayer frames, the colorspace should be V4L2_COLORSPACE_RAW instead of SRGB. Fixes: a8df5af695a1 ("media: ov5647: Add SGGBR10_1X10 modes") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ff65571ffae52b65577121e7696bf22156e1928a Author: David Plowman Date: Mon Dec 22 13:45:27 2025 +0530 media: i2c: ov5647: Correct minimum VBLANK value [ Upstream commit 1438248c5a82c86b4e1f0311c3bb827af747a8cf ] Trial and error reveals that the minimum vblank value appears to be 24 (the OV5647 data sheet does not give any clues). This fixes streaming lock-ups in full resolution mode. Fixes: 2512c06441e3 ("media: ov5647: Support V4L2_CID_VBLANK control") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 58f1767ad5c9eda3dd0befddc1843259d46d64fa Author: David Plowman Date: Mon Dec 22 13:45:26 2025 +0530 media: i2c: ov5647: Correct pixel array offset [ Upstream commit a4e62e597f21bb37db0ad13aca486094e9188167 ] The top offset in the pixel array is actually 6 (see page 3-1 of the OV5647 data sheet). Fixes: 14f70a3232aa ("media: ov5647: Add support for get_selection()") Cc: stable@vger.kernel.org Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2dedda97a64e7735844609c6c77c0dd953d73833 Author: Jai Luthra Date: Mon Dec 22 13:45:25 2025 +0530 media: i2c: ov5647: Initialize subdev before controls [ Upstream commit eee13cbccacb6d0a3120c126b8544030905b069d ] In ov5647_init_controls() we call v4l2_get_subdevdata, but it is initialized by v4l2_i2c_subdev_init() in the probe, which currently happens after init_controls(). This can result in a segfault if the error condition is hit, and we try to access i2c_client, so fix the order. Fixes: 4974c2f19fd8 ("media: ov5647: Support gain, exposure and AWB controls") Cc: stable@vger.kernel.org Suggested-by: Jacopo Mondi Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 32a21ed2ad743fe2d12af48e627089b921a032c2 Author: Sakari Ailus Date: Tue Nov 25 00:24:48 2025 +0200 media: ccs: Avoid possible division by zero [ Upstream commit 679f0b7b6a409750a25754c8833e268e5fdde742 ] Calculating maximum M for scaler configuration involves dividing by MIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumably non-zero, the driver was missing the check it in fact was. Fix this. Reported-by: Josh Poimboeuf Closes: https://lore.kernel.org/all/ahukd6b3wonye3zgtptvwzvrxldcruazs2exfvll6etjhmcxyj@vq3eh6pd375b/ Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Cc: stable@vger.kernel.org # for 5.15 and later Signed-off-by: Sakari Ailus Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor # build Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1b103307df6d461a0731be25aca69ad0335b0933 Author: Alper Ak Date: Mon Dec 29 10:52:17 2025 +0300 media: qcom: camss: vfe: Fix out-of-bounds access in vfe_isr_reg_update() [ Upstream commit d965919af524e68cb2ab1a685872050ad2ee933d ] vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop bound and passes the index to vfe_isr_reg_update(). However, vfe->line[] array is defined with VFE_LINE_NUM_MAX(4): struct vfe_line line[VFE_LINE_NUM_MAX]; When index is 4, 5, 6, the access to vfe->line[line_id] exceeds the array bounds and resulting in out-of-bounds memory access. Fix this by using separate loops for output lines and write masters. Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware version Titan 480") Signed-off-by: Alper Ak Cc: stable@vger.kernel.org Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b9c3b0a1363669ee9ffcc3e34412281b3ea1810d Author: Hans de Goede Date: Tue Oct 14 19:40:14 2025 +0200 media: i2c: ov01a10: Fix test-pattern disabling [ Upstream commit 409fb57c1b3deada4b8e153eb6344afb3c2dfb9c ] When the test-pattern control gets set to 0 (Disabled) 0 should be written to the test-pattern register, rather then doing nothing. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b32a74bdc0a675cd02a81c96e924cc48f76dc176 Author: Hans de Goede Date: Tue Oct 14 19:40:13 2025 +0200 media: i2c: ov01a10: Fix passing stream instead of pad to v4l2_subdev_state_get_format() [ Upstream commit f8563a375e7fba7c776eb591d4498be592c19098 ] The 2 argument version of v4l2_subdev_state_get_format() takes the pad as second argument, not the stream. Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state functions") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 93804dda39f082e36762b4b81327ef30cbf9083a Author: Hans de Goede Date: Tue Oct 14 19:40:12 2025 +0200 media: i2c: ov01a10: Add missing v4l2_subdev_cleanup() calls [ Upstream commit 0dfec6e30c334364145d0acb38bb8c216b9a7a78 ] Add missing v4l2_subdev_cleanup() calls to cleanup after v4l2_subdev_init_finalize(). Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 79dff20b1a57ae23162a3f0ed4fc269637c480d4 Author: Hans de Goede Date: Tue Oct 14 19:40:11 2025 +0200 media: i2c: ov01a10: Fix analogue gain range [ Upstream commit 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc ] A analogue maximum gain of 0xffff / 65525 seems unlikely and testing indeed shows that the gain control wraps-around at 16383, so set the maximum gain to 0x3fff / 16383. The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait [Sakari Ailus: mention analogue gain and update the limit from 4096.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fe3e92312a4652bb6e31acc167e810ff7e3e96fd Author: Hans de Goede Date: Tue Oct 14 19:40:10 2025 +0200 media: i2c: ov01a10: Fix reported pixel-rate value [ Upstream commit 9c632eebf6af4cb7b0f85503fe1ebc5176ff0db1 ] CSI lanes are double-clocked so with a single lane at 400MHZ the resulting pixel-rate for 10-bits pixels is 400 MHz * 2 / 10 = 80 MHz, not 40 MHz. This also matches with the observed frame-rate of 60 fps with the default vblank setting: 80000000 / (1488 * 896) = 60. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 577dafd9f68eb3245cce97e4a94b8cc4d1f87742 Author: Hans de Goede Date: Tue Oct 14 19:40:09 2025 +0200 media: i2c: ov01a10: Fix the horizontal flip control [ Upstream commit ada20c3db0db4f2834d9515f6105111871f04a4d ] During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. So it seems that the horizontal flip control is inverted and needs to be set to 1 to not flip (just like the similar problem recently fixed on the ov08x40 sensor). Invert the hflip control to fix the sensor mirroring by default. As the comment above the newly added OV01A10_MEDIA_BUS_FMT define explains the control being inverted also means that the native Bayer-order of the sensor actually is GBRG not BGGR, but so as to not break userspace the Bayer-order is kept at BGGR. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fb09d8b80046216646f1a344410cfa9cfa6c6c7c Author: Abdun Nihaal Date: Tue Dec 23 11:19:01 2025 +0530 media: i2c/tw9906: Fix potential memory leak in tw9906_probe() [ Upstream commit cad237b6c875fbee5d353a2b289e98d240d17ec8 ] In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: a000e9a02b58 ("[media] tw9906: add Techwell tw9906 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a114918270f0d95c607d69b03a244e6afe54813f Author: Abdun Nihaal Date: Tue Dec 23 11:18:13 2025 +0530 media: i2c/tw9903: Fix potential memory leak in tw9903_probe() [ Upstream commit 9cea16fea47e5553f51d10957677ff735b1eff03 ] In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable@vger.kernel.org Fixes: 0890ec19c65d ("[media] tw9903: add new tw9903 video decoder") Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2df98c45a74a17644564b3883835661b6f9a792a Author: Haoxiang Li Date: Wed Dec 10 16:52:30 2025 +0800 media: cx25821: Add missing unmap in snd_cx25821_hw_params() [ Upstream commit 863f50d583445c3c8b28a0fc4bb9c18fd9656f41 ] In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: 8d8e6d6005de ("[media] cx28521: drop videobuf abuse in cx25821-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9c0a6ff538660c36a98081916a24f08d55a91331 Author: Haoxiang Li Date: Wed Dec 10 11:02:17 2025 +0800 media: cx23885: Add missing unmap in snd_cx23885_hw_params() [ Upstream commit 141c81849fab2ad4d6e3fdaff7cbaa873e8b5eb2 ] In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e3fb15aadfc8643203bbdf97ace0396e4586fa64 Author: Haoxiang Li Date: Wed Dec 10 10:53:48 2025 +0800 media: cx88: Add missing unmap in snd_cx88_hw_params() [ Upstream commit dbc527d980f7ba8559de38f8c1e4158c71a78915 ] In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7fa9754f48cb8eefa566156be341e63d313247e5 Author: Shaurya Rane Date: Thu Nov 27 00:34:10 2025 +0530 media: radio-keene: fix memory leak in error path [ Upstream commit b8bf939d77c0cd01118e953bbf554e0fa15e9006 ] Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized. Reported-by: syzbot+a41b73dce23962a74c72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a41b73dce23962a74c72 Fixes: 1bf20c3a0c61 ("[media] radio-keene: add a driver for the Keene FM Transmitter") Cc: stable@vger.kernel.org Signed-off-by: Shaurya Rane Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cffde73f0d5f3db14ac64b02327e59664a231fb4 Author: Benjamin Gaignard Date: Thu Jan 8 14:29:46 2026 +0100 media: verisilicon: AV1: Set IDR flag for intra_only frame type [ Upstream commit 1c1b79f40ee4444fa1ac96079751608b724c6b2b ] Intra_only frame could be considered as a key frame so Instantaneous Decoding Refresh (IDR) flag must be set of the both case and not only for key frames. Signed-off-by: Benjamin Gaignard Reported-by: Jianfeng Liu Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5da29ade540b51763b950987bd410add7edaf3d1 Author: Alper Ak Date: Sat Dec 27 11:40:37 2025 +0300 media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init() [ Upstream commit 81f8e0e6a2e115df9274d0289779f8fca694479c ] rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is unsupported or invalid. rga_buf_init() does not check the return value and unconditionally dereferences the pointer when accessing f->size. Add proper ERR_PTR checking and return the error to prevent dereferencing an invalid pointer. Fixes: 6040702ade23 ("media: rockchip: rga: allocate DMA descriptors per buffer") Cc: stable@vger.kernel.org Signed-off-by: Alper Ak Reviewed-by: Michael Tretter Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4ff5b0fd1faa7cd4cbfeeb13b6d28111c4901161 Author: Ming Qian Date: Tue Dec 23 14:27:52 2025 +0800 media: amphion: Drop min_queued_buffers assignment [ Upstream commit 5633ec763a2a18cef6c5ac9250e4f4b8786e7999 ] The min_queued_buffers field controls when start_streaming() is called by the vb2 core (it delays the callback until at least N buffers are queued). Setting it to 1 affects the timing of start_streaming(), which breaks the seek flow in decoder scenarios and causes test failures. The current driver implementation does not rely on this minimum buffer requirement and handles streaming start correctly with the default value of 0, so remove these assignments. Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Reviewed-by: Frank Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b19beca4ae66cd591e45d62e8b4edef6d952f8e6 Author: Janne Grunau Date: Thu Jan 8 22:04:01 2026 +0100 arm64: dts: apple: t8112-j473: Keep the HDMI port powered on [ Upstream commit 3e4e729325131fe6f7473a0673f7d8cdde53f5a0 ] Add the display controller and DPTX phy power-domains to the framebuffer node to keep the framebuffer and display out working after device probing finished. The OS has more control about the display pipeline used for the HDMI output on M2 based devices. The HDMI output is driven by an integrated DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now controlled by the OS and no longer by firmware running on the display co-processor. This allows using the second display controller on the second USB type-c port or tunneling 2 DisplayPort connections over USB4/Thunderbolt. The m1n1 bootloader uses the second display controller to drive the HDMI output. Adjust for this difference compared to the notebooks as well. Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees") Cc: stable@vger.kernel.org Signed-off-by: Janne Grunau Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0a8@jannau.net Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit f1ceaaf93ea32d0f2b95c95f784ee155962c52ad Author: Günther Noack Date: Fri Jan 9 13:25:58 2026 +0100 HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() [ Upstream commit 1547d41f9f19d691c2c9ce4c29f746297baef9e9 ] Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e7ac1cd823cd2e9fcbd5cb0b261d6d35dbb79341 Author: Günther Noack Date: Fri Jan 9 11:58:08 2026 +0100 HID: prodikeys: Check presence of pm->input_ep82 [ Upstream commit cee8337e1bad168136aecfe6416ecd7d3aa7529a ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 922bd3e498a4b8e445def6e6ffea2ad3682ad516 Author: Günther Noack Date: Fri Jan 9 11:57:14 2026 +0100 HID: magicmouse: Do not crash on missing msc->input [ Upstream commit 17abd396548035fbd6179ee1a431bd75d49676a7 ] Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device. Cc: stable@vger.kernel.org Signed-off-by: Günther Noack Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 04e50f45b5175bb90a06f5003113cb4ed6ba44c2 Author: Oliver Neukum Date: Wed Nov 19 10:09:57 2025 +0100 HID: hid-pl: handle probe errors [ Upstream commit 3756a272d2cf356d2203da8474d173257f5f8521 ] Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used. Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2in1 Adapter") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 43a19467d3f31a0b80e9e74cb4ae96aba40399e0 Author: Breno Leitao Date: Tue Jan 6 02:16:35 2026 -0800 arm64: Disable branch profiling for all arm64 code [ Upstream commit f22c81bebf8bda6e54dc132df0ed54f6bf8756f9 ] The arm64 kernel doesn't boot with annotated branches (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together. Bisecting it, I found that disabling branch profiling in arch/arm64/mm solved the problem. Narrowing down a bit further, I found that physaddr.c is the file that needs to have branch profiling disabled to get the machine to boot. I suspect that it might invoke some ftrace helper very early in the boot process and ftrace is still not enabled(!?). Rather than playing whack-a-mole with individual files, disable branch profiling for the entire arch/arm64 tree, similar to what x86 already does in arch/x86/Kbuild. Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ce904c8a5bbe697eae0f7e34b07095bd7a6dee19 Author: Sean Christopherson Date: Tue Dec 16 08:17:54 2025 -0800 KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeeding [ Upstream commit fc3ba56385d03501eb582e4b86691ba378e556f9 ] Drop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failing as it is trivially easy to trigger from userspace by modifying CPUID after loading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doing generates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Simply delete the WARN instead of trying to prevent userspace from shoving "illegal" state into CR3. For better or worse, KVM's ABI allows userspace to set CPUID after SREGS, and vice versa, and KVM is very permissive when it comes to guest CPUID. I.e. attempting to enforce the virtual CPU model when setting CPUID could break userspace. Given that the WARN doesn't provide any meaningful protection for KVM or benefit for userspace, simply drop it even though the odds of breaking userspace are minuscule. Opportunistically delete a spurious newline. Fixes: b222b0b88162 ("KVM: nSVM: refactor the CR3 reload on migration") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20251216161755.1775409-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit c481d4edf070fa64927a65ffcff1b8b6a3a47bad Author: Sean Christopherson Date: Tue Dec 30 12:59:48 2025 -0800 KVM: x86: Return "unsupported" instead of "invalid" on access to unsupported PV MSR [ Upstream commit 5bb9ac1865123356337a389af935d3913ee917ed ] Return KVM_MSR_RET_UNSUPPORTED instead of '1' (which for all intents and purposes means "invalid") when rejecting accesses to KVM PV MSRs to adhere to KVM's ABI of allowing host reads and writes of '0' to MSRs that are advertised to userspace via KVM_GET_MSR_INDEX_LIST, even if the vCPU model doesn't support the MSR. E.g. running a QEMU VM with -cpu host,-kvmclock,kvm-pv-enforce-cpuid yields: qemu: error: failed to set MSR 0x12 to 0x0 qemu: target/i386/kvm/kvm.c:3301: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest's CPUID") Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20251230205948.4094097-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit b61843503d54b149e98b5f648465b2d868159a14 Author: Wentao Liang Date: Wed Dec 17 14:21:22 2025 +0000 ARM: omap2: Fix reference count leaks in omap_control_init() [ Upstream commit 93a04ab480c8bbcb7d9004be139c538c8a0c1bc8 ] The of_get_child_by_name() function increments the reference count of child nodes, causing multiple reference leaks in omap_control_init(): 1. scm_conf node never released in normal/error paths 2. clocks node leak when checking existence 3. Missing scm_conf release before np in error paths Fix these leaks by adding proper of_node_put() calls and separate error handling. Fixes: e5b635742e98 ("ARM: OMAP2+: control: add syscon support for register accesses") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20251217142122.1861292-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 8c73302be4752e13e20c8cbdfe78a353f820fe2a Author: Abel Vesa Date: Wed Dec 24 12:53:29 2025 +0200 arm64: dts: qcom: x1e80100: Add missing TCSR ref clock to the DP PHYs [ Upstream commit 0907cab01ff9746ecf08592edd9bd85d2636be58 ] The DP PHYs on X1E80100 need the ref clock which is provided by the TCSR CC. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So lets attach it to each of the DP PHYs in order to do that. Cc: stable@vger.kernel.org # v6.9 Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20251224-phy-qcom-edp-add-missing-refclk-v5-3-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 885e26f6845dda8cae22f700b8e7b0587a7b0cc2 Author: Benjamin Gaignard Date: Tue Dec 9 11:34:17 2025 +0100 media: verisilicon: AV1: Fix tx mode bit setting [ Upstream commit cb3f945c012ab152fd2323e0df34c2b640071738 ] AV1 specification describes 3 possibles tx modes: 4x4 only, largest and select. The hardware allows 5 possibles tx modes: 4x4 only, 8x8, 16x16, 32x32 and select. Since the both aren't exactly matching we need to add a mapping function to set the correct mode on hardware. Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 72e6e79568f321e4ac1a81d57d53ad66291c4845 Author: Benjamin Gaignard Date: Tue Dec 9 11:34:01 2025 +0100 media: verisilicon: AV1: Fix enable cdef computation [ Upstream commit e0f99b810e1181374370f91cd996d761549e147f ] If all the fields of the CDEF parameters are zero (which is the default), then av1_enable_cdef register needs to be unset (despite the V4L2_AV1_SEQUENCE_FLAG_ENABLE_CDEF possibly being set). Signed-off-by: Benjamin Gaignard Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reported-by: Jianfeng Liu Closes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4786 Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: dropped Link tag since it just duplicated the Closes: URL] Signed-off-by: Sasha Levin commit b73d85231d5b1400a4fa5046cdac6c4d7cc6d969 Author: Xulin Sun Date: Thu Dec 4 17:41:53 2025 +0800 media: chips-media: wave5: Fix device cleanup order to prevent kernel panic [ Upstream commit b74cedac643b02aefa7da881b58a3792859d9748 ] Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down. In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback() which queues work to the kthread worker. The worker executes wave5_vpu_irq_work_fn() which reads hardware registers via wave5_vdi_read_register(). The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic. This causes random kernel panics during encoding operations: Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsg_ctrl rpmsg_char ... CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G M W pc : wave5_vdi_read_register+0x10/0x38 [wave5] lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5] Call trace: wave5_vdi_read_register+0x10/0x38 [wave5] kthread_worker_fn+0xd8/0x238 kthread+0x104/0x120 ret_from_fork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception Fixes: 9707a6254a8a ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 156020e889edf4593870d926d3c4a6d06baac44a Author: Xulin Sun Date: Thu Dec 4 17:41:52 2025 +0800 media: chips-media: wave5: Fix kthread worker destruction in polling mode [ Upstream commit 5a0c122e834b2f7f029526422c71be922960bf03 ] Fix the cleanup order in polling mode (irq < 0) to prevent kernel warnings during module removal. Cancel the hrtimer before destroying the kthread worker to ensure work queues are empty. In polling mode, the driver uses hrtimer to periodically trigger wave5_vpu_timer_callback() which queues work via kthread_queue_work(). The kthread_destroy_worker() function validates that both work queues are empty with WARN_ON(!list_empty(&worker->work_list)) and WARN_ON(!list_empty(&worker->delayed_work_list)). The original code called kthread_destroy_worker() before hrtimer_cancel(), creating a race condition where the timer could fire during worker destruction and queue new work, triggering the WARN_ON. This causes the following warning on every module unload in polling mode: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ... Call trace: kthread_destroy_worker+0x84/0x98 wave5_vpu_remove+0xc8/0xe0 [wave5] platform_remove+0x30/0x58 ... ---[ end trace 0000000000000000 ]--- Fixes: ed7276ed2fd0 ("media: chips-media: wave5: Add hrtimer based polling support") Cc: stable@vger.kernel.org Signed-off-by: Xulin Sun Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4f2a51433a3a65d16975d1e32052d80656da077d Author: Haoxiang Li Date: Wed Oct 8 17:01:56 2025 +0800 media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() [ Upstream commit f128bab57b8018e526b7eda854ca20069863af47 ] In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c8737d33d4e8ffae87e5d5edac17f8a705235cc2 Author: Haoxiang Li Date: Wed Oct 8 16:55:03 2025 +0800 media: mtk-mdp: Fix error handling in probe function [ Upstream commit 8a8a3232abac5b972058a5f2cb3e33199d2a8648 ] Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit fe17309d9bf7157ffe41f54ddb95f009fd3d2059 Author: Irui Wang Date: Sun Sep 7 17:35:56 2025 +0800 media: mediatek: encoder: Fix uninitialized scalar variable issue [ Upstream commit 88e935de7cf8795d7a6a51385db87ecb361a7050 ] UNINIT checker finds some instances of variables that are used without being initialized, for example using the uninitialized value enc_result.is_key_frm can result in unpredictable behavior, so initialize these variables after declaring. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Cc: stable@vger.kernel.org Signed-off-by: Irui Wang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9b8dc1d327e2928f3da59ced0595d850d31c0936 Author: Eric Biggers Date: Fri Dec 19 11:29:08 2025 -0800 dm-verity: correctly handle dm_bufio_client_create() failure [ Upstream commit 119f4f04186fa4f33ee6bd39af145cdaff1ff17f ] If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Reviewed-by: Sami Tolvanen Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit ff613d11f78ef37f8e82e3d638c96c26599c7cb8 Author: Abel Vesa Date: Wed Dec 24 12:53:28 2025 +0200 phy: qcom: edp: Make the number of clocks flexible [ Upstream commit 7d51b709262c5aa31d2b9cd31444112c1b2dae03 ] On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: stable@vger.kernel.org # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6ad50d3a16708cb70f312876efb45e8af49950da Author: Niklas Cassel Date: Mon Dec 22 07:42:11 2025 +0100 Revert "PCI: qcom: Enable MSI interrupts together with Link up if 'Global IRQ' is supported" [ Upstream commit 7ebdefb87942073679e56cfbc5a72e8fc5441bfc ] This reverts commit ba4a2e2317b9faeca9193ed6d3193ddc3cf2aba3. Since the Link up IRQ support is going away, revert the MSI logic that got added for it too. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel [mani: reworded the description] Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-12-cassel@kernel.org Signed-off-by: Sasha Levin commit 57fa97ae238534857c2eaf37814eeefb7f4d7f38 Author: Thomas Zimmermann Date: Fri Dec 12 17:00:32 2025 +0100 drm/tests: shmem: Swap names of export tests [ Upstream commit 89f23d42006630dd94c01a8c916f8c648141ad8e ] GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: dri-devel@lists.freedesktop.org Cc: # v6.8+ Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 501ace56f3f8af63b1043b9594a7ec275a9e27f0 Author: Thadeu Lima de Souza Cascardo Date: Mon Dec 15 16:05:50 2025 -0300 fpga: dfl: use subsys_initcall to allow built-in drivers to be added [ Upstream commit 267f53140c9d0bf270bbe0148082e9b8e5011273 ] The dfl code adds a bus. If it is built-in and there is a built-in driver as well, the dfl module_init may be called after the driver module_init, leading to a failure to register the driver as the bus has not been added yet. Use subsys_initcall, which guarantees it will be called before the drivers init code. Without the fix, we see failures like this: [ 0.479475] Driver 'intel-m10-bmc' was unable to register with bus_type 'dfl' because the bus was not initialized. Cc: stable@vger.kernel.org Fixes: 9ba3a0aa09fe ("fpga: dfl: create a dfl bus type to support DFL devices") Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20251215-dfl_subsys-v1-1-21807bad6b10@igalia.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 885ec85776220fd29680f6c454d2df7d04e0d02e Author: Peter Ujfalusi Date: Wed Dec 17 16:39:41 2025 +0200 ASoC: SOF: ipc4-control: Keep the payload size up to date [ Upstream commit ebcfdbe4add923dfb690e6fb9d158da87ae0b6bf ] When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 20b55c3831cf1aa53c621e5e75341e835fb16dbc Author: Peter Ujfalusi Date: Wed Dec 17 16:39:40 2025 +0200 ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data [ Upstream commit c1876fc33c5976837e4c73719c7582617efc6919 ] The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 491956b45b5f4933632ea6d8a8bdfdf045ab81e1 Author: Peter Ujfalusi Date: Wed Dec 17 16:39:39 2025 +0200 ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls [ Upstream commit a653820700b81c9e6f05ac23b7969ecec1a18e85 ] The size of the data behind of scontrol->ipc_control_data for bytes controls is: [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct [2] sizeof(struct sof_abi_hdr)) + payload The max_size specifies the size of [2] and it is coming from topology. Change the function to take this into account and allocate adequate amount of memory behind scontrol->ipc_control_data. With the change we will allocate [1] amount more memory to be able to hold the full size of data. Fixes: a382082ff74b ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BYTES") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 698988dda4dbdfe92b8668be3db5026276e398ac Author: Peter Ujfalusi Date: Wed Dec 17 16:39:38 2025 +0200 ASoC: SOF: ipc4-control: If there is no data do not send bytes update [ Upstream commit 2fa74713744dc5e908fff851c20f5f89fd665fb7 ] When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47671671a370553589b348d76318018d4df7e1e9 Author: Chris Brandt Date: Fri Nov 14 14:45:29 2025 -0500 clk: renesas: rzg2l: Select correct div round macro [ Upstream commit f9451374dcfdfe669ee55b58ee6c11e8638980e4 ] Variable foutvco_rate is an unsigned long, not an unsigned long long. Cc: stable@kernel.org Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/CAMuHMdVf7dSeqAhtyxDCFuCheQRzwS-8996Rr2Ntui21uiBgdA@mail.gmail.com Fixes: dabf72b85f29 ("clk: renesas: rzg2l: Fix FOUTPOSTDIV clk") Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114194529.3304361-1-chris.brandt@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2f7042ca608d15d749f52e9c7a53e7bae8caabdc Author: Chris Brandt Date: Fri Nov 14 14:37:11 2025 -0500 clk: renesas: rzg2l: Fix intin variable size [ Upstream commit a00655d98cd885472c311f01dff3e668d1288d0a ] INTIN is a 12-bit register value, so u8 is too small. Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support") Cc: stable@vger.kernel.org Reported-by: Hugo Villeneuve Closes: https://lore.kernel.org/20251107113058.f334957151d1a8dd94dd740b@hugovil.com Signed-off-by: Chris Brandt Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251114193711.3277912-1-chris.brandt@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 7654e6e3cd6bdee9602f6063b3c670bd556d7e61 Author: Gui-Dong Han Date: Wed Dec 3 01:49:48 2025 +0800 rpmsg: core: fix race in driver_override_show() and use core helper [ Upstream commit 42023d4b6d2661a40ee2dcf7e1a3528a35c638ca ] The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code. Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20251202174948.12693-1-hanguidong02@gmail.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 53d32735d77ab56cc3fc7bd53a7d099418f19be1 Author: Vahagn Vardanian Date: Wed Feb 25 14:06:18 2026 +0100 netfilter: nf_conntrack_h323: fix OOB read in decode_choice() [ Upstream commit baed0d9ba91d4f390da12d5039128ee897253d60 ] In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len(). Fixes: ec8a8f3c31dd ("netfilter: nf_ct_h323: Extend nf_h323_error_boundary to work on bits as well") Signed-off-by: Vahagn Vardanian Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260225130619.1248-2-fw@strlen.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8b841fd529db9faf8bc678d429d4bf4e98b10900 Author: Junrui Luo Date: Tue Feb 24 19:05:56 2026 +0800 dpaa2-switch: validate num_ifs to prevent out-of-bounds write [ Upstream commit 8a5752c6dcc085a3bfc78589925182e4e98468c5 ] The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ... Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains") Signed-off-by: Junrui Luo Reviewed-by: Ioana Ciornei Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ea5d7787635e26ec1194ec7eec0e8e5ae3bd10a5 Author: Jakub Kicinski Date: Mon Feb 23 15:51:00 2026 -0800 net: consume xmit errors of GSO frames [ Upstream commit 7aa767d0d3d04e50ae94e770db7db8197f666970 ] udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link). Link: https://lore.kernel.org/CANn89iJcLepEin7EtBETrZ36bjoD9LrR=k4cfwWh046GB+4f9A@mail.gmail.com Fixes: 1f59533f9ca5 ("qdisc: validate frames going through the direct_xmit path") Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260223235100.108939-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e1407fb7c337373dfaaae2445d828b0b9ae26a29 Author: Jianbo Liu Date: Tue Feb 24 13:46:52 2026 +0200 net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query [ Upstream commit 859380694f434597407632c29f30fdb5e763e6cc ] Fix a "scheduling while atomic" bug in mlx5e_ipsec_init_macs() by replacing mlx5_query_mac_address() with ether_addr_copy() to get the local MAC address directly from netdev->dev_addr. The issue occurs because mlx5_query_mac_address() queries the hardware which involves mlx5_cmd_exec() that can sleep, but it is called from the mlx5e_ipsec_handle_event workqueue which runs in atomic context. The MAC address is already available in netdev->dev_addr, so no need to query hardware. This avoids the sleeping call and resolves the bug. Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 __schedule+0x7ab/0xa20 schedule+0x1c/0xb0 schedule_timeout+0x6e/0xf0 __wait_for_common+0x91/0x1b0 cmd_exec+0xa85/0xff0 [mlx5_core] mlx5_cmd_exec+0x1f/0x50 [mlx5_core] mlx5_query_nic_vport_mac_address+0x7b/0xd0 [mlx5_core] mlx5_query_mac_address+0x19/0x30 [mlx5_core] mlx5e_ipsec_init_macs+0xc1/0x720 [mlx5_core] mlx5e_ipsec_build_accel_xfrm_attrs+0x422/0x670 [mlx5_core] mlx5e_ipsec_handle_event+0x2b9/0x460 [mlx5_core] process_one_work+0x178/0x2e0 worker_thread+0x2ea/0x430 Fixes: cee137a63431 ("net/mlx5e: Handle ESN update events") Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c7bbd8632bcf65fa3bb841512cb408384344c901 Author: Alexandre Cassen Date: Tue Jul 22 17:23:47 2025 +0300 net/mlx5e: Support routed networks during IPsec MACs initialization [ Upstream commit 71670f766b8f4c1490e07ad4394e8e27c03b2e91 ] Remote IPsec tunnel endpoint may refer to a network segment that is not directly connected to the host. In such a case, IPsec tunnel endpoints are connected to a router and reachable via a routing path. In IPsec packet offload mode, HW is initialized with the MAC address of both IPsec tunnel endpoints. Extend the current IPsec init MACs procedure to resolve nexthop for routed networks. Direct neighbour lookup and probe is still used for directly connected networks and as a fallback mechanism if fib lookup fails. Signed-off-by: Alexandre Cassen Signed-off-by: Leon Romanovsky Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/1753194228-333722-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 859380694f43 ("net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query") Signed-off-by: Sasha Levin commit b32498dd76215dc22c4ca311f0d812d5fa6b1219 Author: Leon Romanovsky Date: Tue Mar 4 18:06:19 2025 +0200 net/mlx5e: Separate address related variables to be in struct [ Upstream commit 348ed4b20546b80a67bb87b0fb32397efbae4c87 ] Prepare the code to addition of prefix handling logic which is needed to support matching logic based on source and/or destination network prefixes. Signed-off-by: Leon Romanovsky Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250304160620.417580-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 859380694f43 ("net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query") Signed-off-by: Sasha Levin commit 2e4c6912115668a84adc5efb2bdc3ba0c7f3c8de Author: Shay Drory Date: Tue Feb 24 13:46:51 2026 +0200 net/mlx5: Fix missing devlink lock in SRIOV enable error path [ Upstream commit 60253042c0b87b61596368489c44d12ba720d11c ] The cited commit miss to add locking in the error path of mlx5_sriov_enable(). When pci_enable_sriov() fails, mlx5_device_disable_sriov() is called to clean up. This cleanup function now expects to be called with the devlink instance lock held. Add the missing devl_lock(devlink) and devl_unlock(devlink) Fixes: 84a433a40d0e ("net/mlx5: Lock mlx5 devlink reload callbacks") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53f5c553149aa0830a215631c6c17608647ae16d Author: Shay Drory Date: Tue Feb 24 13:46:50 2026 +0200 net/mlx5: E-switch, Clear legacy flag when moving to switchdev [ Upstream commit d7073e8b978ae925f1f0f08754f33f84d8547ea7 ] The cited commit introduced MLX5_PRIV_FLAGS_SWITCH_LEGACY to identify when a transition to legacy mode is requested via devlink. However, the logic failed to clear this flag if the mode was subsequently changed back to MLX5_ESWITCH_OFFLOADS (switchdev). Consequently, if a user toggled from legacy to switchdev, the flag remained set, leaving the driver with wrong state indicating Fix this by explicitly clearing the MLX5_PRIV_FLAGS_SWITCH_LEGACY bit when the requested mode is MLX5_ESWITCH_OFFLOADS. Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devlink set legacy only") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a825a26f9e300a1e863c7d676cb72a22c9d1bc6 Author: Shay Drory Date: Tue Feb 24 13:46:48 2026 +0200 net/mlx5: DR, Fix circular locking dependency in dump [ Upstream commit 2700b7e603af39ca55fe9fc876ca123efd44680f ] Fix a circular locking dependency between dbg_mutex and the domain rx/tx mutexes that could lead to a deadlock. The dump path in dr_dump_domain_all() was acquiring locks in the order: dbg_mutex -> rx.mutex -> tx.mutex While the table/matcher creation paths acquire locks in the order: rx.mutex -> tx.mutex -> dbg_mutex This inverted lock ordering creates a circular dependency. Fix this by changing dr_dump_domain_all() to acquire the domain lock before dbg_mutex, matching the order used in mlx5dr_table_create() and mlx5dr_matcher_create(). Lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.19.0-rc6net_next_e817c4e #1 Not tainted ------------------------------------------------------ sos/30721 is trying to acquire lock: ffff888102df5900 (&dmn->info.rx.mutex){+.+.}-{4:4}, at: dr_dump_start+0x131/0x450 [mlx5_core] but task is already holding lock: ffff888102df5bc0 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}, at: dr_dump_start+0x10b/0x450 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dmn->dump_info.dbg_mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_matcher_create+0x377/0x5e0 [mlx5_core] mlx5_cmd_dr_create_flow_group+0x62/0xd0 [mlx5_core] mlx5_create_flow_group+0x113/0x1c0 [mlx5_core] mlx5_chains_create_prio+0x453/0x2290 [mlx5_core] mlx5_chains_get_table+0x2e2/0x980 [mlx5_core] esw_chains_create+0x1e6/0x3b0 [mlx5_core] esw_create_offloads_fdb_tables.cold+0x62/0x63f [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dmn->info.tx.mutex){+.+.}-{4:4}: __mutex_lock+0x91/0x1060 mlx5dr_table_create+0x11d/0x530 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x62/0x140 [mlx5_core] __mlx5_create_flow_table+0x46f/0x960 [mlx5_core] mlx5_create_flow_table+0x16/0x20 [mlx5_core] esw_create_offloads_fdb_tables+0x136/0x240 [mlx5_core] esw_offloads_enable+0x76f/0xd20 [mlx5_core] mlx5_eswitch_enable_locked+0x35a/0x500 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x561/0x950 [mlx5_core] devlink_nl_eswitch_set_doit+0x67/0xe0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x188/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x1ed/0x2c0 netlink_sendmsg+0x210/0x450 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #0 (&dmn->info.rx.mutex){+.+.}-{4:4}: __lock_acquire+0x18b6/0x2eb0 lock_acquire+0xd3/0x2c0 __mutex_lock+0x91/0x1060 dr_dump_start+0x131/0x450 [mlx5_core] seq_read_iter+0xe3/0x410 seq_read+0xfb/0x130 full_proxy_read+0x53/0x80 vfs_read+0xba/0x330 ksys_read+0x65/0xe0 do_syscall_64+0x70/0xd00 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.tx.mutex); lock(&dmn->dump_info.dbg_mutex); lock(&dmn->info.rx.mutex); *** DEADLOCK *** Fixes: 9222f0b27da2 ("net/mlx5: DR, Add support for dumping steering info") Signed-off-by: Shay Drory Reviewed-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224114652.1787431-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba3bf0f1bf1d5d0404678485e872980532fcc2c4 Author: Jacob Moroni Date: Tue Feb 24 23:41:53 2026 +0000 RDMA/umem: Fix double dma_buf_unpin in failure path [ Upstream commit 104016eb671e19709721c1b0048dd912dc2e96be ] In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt). Fixes: 1e4df4a21c5a ("RDMA/umem: Allow pinned dmabuf umem usage") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260224234153.1207849-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 67ba6b13dbcaf45681fb6758794c5ac5fa589a6c Author: Ziyi Guo Date: Sun Feb 22 05:06:33 2026 +0000 net: usb: pegasus: enable basic endpoint checking [ Upstream commit 3d7e6ce34f4fcc7083510c28b17a7c36462a25d4 ] pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260222050633.410165-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f21d71a0962a771fe632fbbef536a2075f3ae5a1 Author: Jason Gunthorpe Date: Mon Feb 16 11:02:47 2026 -0400 RDMA/efa: Fix typo in efa_alloc_mr() [ Upstream commit f22c77ce49db0589103d96487dca56f5b2136362 ] The pattern is to check the entire driver request space, not just sizeof something unrelated. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/1-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidia.com Acked-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 200bdb8d367ca9b478f9c56ebe56411604d55c81 Author: Duoming Zhou Date: Thu Feb 19 20:46:37 2026 +0800 net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets [ Upstream commit bae8a5d2e759da2e0cba33ab2080deee96a09373 ] When the FarSync T-series card is being detached, the fst_card_info is deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task may still be running or pending, leading to use-after-free bugs when the already freed fst_card_info is accessed in fst_process_tx_work_q() or fst_process_int_work_q(). A typical race condition is depicted below: CPU 0 (cleanup) | CPU 1 (tasklet) | fst_start_xmit() fst_remove_one() | tasklet_schedule() unregister_hdlc_device()| | fst_process_tx_work_q() //handler kfree(card) //free | do_bottom_half_tx() | card-> //use The following KASAN trace was captured: ================================================================== BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00 Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcb/0x5d0 ? do_bottom_half_tx+0xb88/0xd00 kasan_report+0xb8/0xf0 ? do_bottom_half_tx+0xb88/0xd00 do_bottom_half_tx+0xb88/0xd00 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx___hrtimer_run_queues+0x10/0x10 fst_process_tx_work_q+0x67/0x90 tasklet_action_common+0x1fa/0x720 ? hrtimer_interrupt+0x31f/0x780 handle_softirqs+0x176/0x530 __irq_exit_rcu+0xab/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 41 on cpu 3 at 72.330843s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 __kasan_kmalloc+0x7f/0x90 fst_add_one+0x1a5/0x1cd0 local_pci_probe+0xdd/0x190 pci_device_probe+0x341/0x480 really_probe+0x1c6/0x6a0 __driver_probe_device+0x248/0x310 driver_probe_device+0x48/0x210 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x101/0x190 __device_attach+0x198/0x3a0 device_initial_probe+0x78/0xa0 pci_bus_add_device+0x81/0xc0 pci_bus_add_devices+0x7e/0x190 enable_slot+0x9b9/0x1130 acpiphp_check_bridge.part.0+0x2e1/0x460 acpiphp_hotplug_notify+0x36c/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... Freed by task 41 on cpu 1 at 75.138639s: kasan_save_stack+0x24/0x50 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x135/0x410 fst_remove_one+0x2ca/0x540 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0x364/0x530 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device+0xd/0x20 disable_slot+0x116/0x260 acpiphp_disable_and_eject_slot+0x4b/0x190 acpiphp_hotplug_notify+0x230/0x3c0 acpi_device_hotplug+0x203/0xb10 acpi_hotplug_work_fn+0x59/0x80 ... The buggy address belongs to the object at ffff88800aad1000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 28 bytes inside of freed 1024-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x100000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800aad1000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800aad1080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800aad1100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fix this by ensuring that both fst_tx_task and fst_int_task are properly canceled before the fst_card_info is released. Add tasklet_kill() in fst_remove_one() to synchronize with any pending or running tasklets. Since unregister_hdlc_device() stops data transmission and reception, and fst_disable_intr() prevents further interrupts, it is appropriate to place tasklet_kill() after these calls. The bugs were identified through static analysis. To reproduce the issue and validate the fix, a FarSync T-series card was simulated in QEMU and delays(e.g., mdelay()) were introduced within the tasklet handler to increase the likelihood of triggering the race condition. Fixes: 2f623aaf9f31 ("net: farsync: Fix kmemleak when rmmods farsync") Signed-off-by: Duoming Zhou Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260219124637.72578-1-duoming@zju.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 36abfc850cdf920dac71fe51cf764c7aac6ed6bd Author: Jiri Pirko Date: Tue Jan 27 10:38:39 2026 +0100 RDMA/core: Fix stale RoCE GIDs during netdev events at registration [ Upstream commit 9af0feae8016ba58ad7ff784a903404986b395b1 ] RoCE GID entries become stale when netdev properties change during the IB device registration window. This is reproducible with a udev rule that sets a MAC address when a VF netdev appears: ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth4", \ RUN+="/sbin/ip link set eth4 address 88:22:33:44:55:66" After VF creation, show_gids displays GIDs derived from the original random MAC rather than the configured one. The root cause is a race between netdev event processing and device registration: CPU 0 (driver) CPU 1 (udev/workqueue) ────────────── ────────────────────── ib_register_device() ib_cache_setup_one() gid_table_setup_one() _gid_table_setup_one() ← GID table allocated rdma_roce_rescan_device() ← GIDs populated with OLD MAC ip link set eth4 addr NEW_MAC NETDEV_CHANGEADDR queued netdevice_event_work_handler() ib_enum_all_roce_netdevs() ← Iterates DEVICE_REGISTERED ← Device NOT marked yet, SKIP! enable_device_and_get() xa_set_mark(DEVICE_REGISTERED) ← Too late, event was lost The netdev event handler uses ib_enum_all_roce_netdevs() which only iterates devices marked DEVICE_REGISTERED. However, this mark is set late in the registration process, after the GID cache is already populated. Events arriving in this window are silently dropped. Fix this by introducing a new xarray mark DEVICE_GID_UPDATES that is set immediately after the GID table is allocated and initialized. Use the new mark in ib_enum_all_roce_netdevs() function to iterate devices instead of DEVICE_REGISTERED. This is safe because: - After _gid_table_setup_one(), all required structures exist (port_data, immutable, cache.gid) - The GID table mutex serializes concurrent access between the initial rescan and event handlers - Event handlers correctly update stale GIDs even when racing with rescan - The mark is cleared in ib_cache_cleanup_one() before teardown This also fixes similar races for IP address events (inetaddr_event, inet6addr_event) which use the same enumeration path. Fixes: 0df91bb67334 ("RDMA/devices: Use xarray to store the client_data") Signed-off-by: Jiri Pirko Link: https://patch.msgid.link/20260127093839.126291-1-jiri@resnulli.us Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 075cbc1a4aa251bc33a7f8958b6732cfb9b2292a Author: Tung Nguyen Date: Fri Feb 20 05:05:41 2026 +0000 tipc: fix duplicate publication key in tipc_service_insert_publ() [ Upstream commit 3aa677625c8fad39989496c51bcff3872c1f16f1 ] TIPC uses named table to store TIPC services represented by type and instance. Each time an application calls TIPC API bind() to bind a type/instance to a socket, an entry is created and inserted into the named table. It looks like this: named table: key1, entry1 (type, instance ...) key2, entry2 (type, instance ...) In the above table, each entry represents a route for sending data from one socket to the other. For all publications originated from the same node, the key is UNIQUE to identify each entry. It is calculated by this formula: key = socket portid + number of bindings + 1 (1) where: - socket portid: unique and calculated by using linux kernel function get_random_u32_below(). So, the value is randomized. - number of bindings: the number of times a type/instance pair is bound to a socket. This number is linearly increased, starting from 0. While the socket portid is unique and randomized by linux kernel, the linear increment of "number of bindings" in formula (1) makes "key" not unique anymore. For example: - Socket 1 is created with its associated port number 20062001. Type 1000, instance 1 is bound to socket 1: key1: 20062001 + 0 + 1 = 20062002 Then, bind() is called a second time on Socket 1 to by the same type 1000, instance 1: key2: 20062001 + 1 + 1 = 20062003 Named table: key1 (20062002), entry1 (1000, 1 ...) key2 (20062003), entry2 (1000, 1 ...) - Socket 2 is created with its associated port number 20062002. Type 1000, instance 1 is bound to socket 2: key3: 20062002 + 0 + 1 = 20062003 TIPC looks up the named table and finds out that key2 with the same value already exists and rejects the insertion into the named table. This leads to failure of bind() call from application on Socket 2 with error message EINVAL "Invalid argument". This commit fixes this issue by adding more port id checking to make sure that the key is unique to publications originated from the same port id and node. Fixes: 218527fe27ad ("tipc: replace name table service range array with rb tree") Signed-off-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220050541.237962-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ea3671d70ee07480d80bebe86696397c4e99fb7 Author: Jiayuan Chen Date: Thu Feb 19 09:42:51 2026 +0800 kcm: fix zero-frag skb in frag_list on partial sendmsg error [ Upstream commit ca220141fa8ebae09765a242076b2b77338106b0 ] Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa Reported-by: syzbot+52624bdfbf2746d37d70@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000269a1405a12fdc77@google.com/T/ Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260219014256.370092-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a5de36d6cee74a92c1a21b260bc507e64bc451de Author: Hyunwoo Kim Date: Fri Feb 20 18:40:36 2026 +0900 tls: Fix race condition in tls_sw_cancel_work_tx() [ Upstream commit 7bb09315f93dce6acc54bf59e5a95ba7365c2be4 ] This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock around TX work flush") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/aZgsFO6nfylfvLE7@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ec91078e132179b04e0c3906b599816c056ceaad Author: Luiz Augusto von Dentz Date: Fri Feb 13 13:33:33 2026 -0500 Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ [ Upstream commit 138d7eca445ef37a0333425d269ee59900ca1104 ] This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE. Link: https://lore.kernel.org/linux-bluetooth/5782243.rdbgypaU67@n9w6sw14/ Fixes: 27e2d4c8d28b ("Bluetooth: Add basic LE L2CAP connect request receiving support") Signed-off-by: Luiz Augusto von Dentz Tested-by: Christian Eggers Signed-off-by: Sasha Levin commit ffb7214f04da08cc9b557b4e3b21f04142761336 Author: Luiz Augusto von Dentz Date: Tue Feb 17 13:29:43 2026 -0500 Bluetooth: L2CAP: Fix not checking output MTU is acceptable on L2CAP_ECRED_CONN_REQ [ Upstream commit a8d1d73c81d1e70d2aa49fdaf59d933bb783ffe5 ] Upon receiving L2CAP_ECRED_CONN_REQ the given MTU shall be checked against the suggested MTU of the listening socket as that is required by the likes of PTS L2CAP/ECFC/BV-27-C test which expects L2CAP_CR_LE_UNACCEPT_PARAMS if the MTU is lowers than socket omtu. In order to be able to set chan->omtu the code now allows setting setsockopt(BT_SNDMTU), but it is only allowed when connection has not been stablished since there is no procedure to reconfigure the output MTU. Link: https://github.com/bluez/bluez/issues/1895 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 730058f51b8fb3a4d0894dc8841baa1399cb1f0a Author: Luiz Augusto von Dentz Date: Wed Feb 11 15:18:03 2026 -0500 Bluetooth: L2CAP: Fix response to L2CAP_ECRED_CONN_REQ [ Upstream commit 05761c2c2b5bfec85c47f60c903c461e9b56cf87 ] Similar to 03dba9cea72f ("Bluetooth: L2CAP: Fix not responding with L2CAP_CR_LE_ENCRYPTION") the result code L2CAP_CR_LE_ENCRYPTION shall be used when BT_SECURITY_MEDIUM is set since that means security mode 2 which mean it doesn't require authentication which results in qualification test L2CAP/ECFC/BV-32-C failing. Link: https://github.com/bluez/bluez/issues/1871 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8285742519b51f5c8e8e33c1e502274d73edd33c Author: Jinwang Li Date: Thu Feb 5 14:26:00 2026 +0800 Bluetooth: hci_qca: Cleanup on all setup failures [ Upstream commit 5c4e9a8b18457ad28b57069ef0f14661e3192b2e ] The setup process previously combined error handling and retry gating under one condition. As a result, the final failed attempt exited without performing cleanup. Update the failure path to always perform power and port cleanup on setup failure, and reopen the port only when retrying. Fixes: 9e80587aba4c ("Bluetooth: hci_qca: Enhance retry logic in qca_setup") Signed-off-by: Jinwang Li Reviewed-by: Bartosz Golaszewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 935f324e4b2461df2cf7f02b4195082b4304c708 Author: Luiz Augusto von Dentz Date: Thu Feb 5 15:11:34 2026 -0500 Bluetooth: L2CAP: Fix result of L2CAP_ECRED_CONN_RSP when MTU is too short [ Upstream commit c28d2bff70444a85b3b86aaf241ece9408c7858c ] Test L2CAP/ECFC/BV-26-C expect the response to L2CAP_ECRED_CONN_REQ with and MTU value < L2CAP_ECRED_MIN_MTU (64) to be L2CAP_CR_LE_INVALID_PARAMS rather than L2CAP_CR_LE_UNACCEPT_PARAMS. Also fix not including the correct number of CIDs in the response since the spec requires all CIDs being rejected to be included in the response. Link: https://github.com/bluez/bluez/issues/1868 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1e09410c98feee63b7770f207501f98535c5d4df Author: Luiz Augusto von Dentz Date: Tue Feb 3 15:16:16 2026 -0500 Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ [ Upstream commit 7accb1c4321acb617faf934af59d928b0b047e2b ] This fixes responding with an invalid result caused by checking the wrong size of CID which should have been (cmd_len - sizeof(*req)) and on top of it the wrong result was use L2CAP_CR_LE_INVALID_PARAMS which is invalid/reserved for reconf when running test like L2CAP/ECFC/BI-03-C: > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 64 MPS: 64 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reserved (0x000c) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fiix L2CAP/ECFC/BI-04-C which expects L2CAP_RECONF_INVALID_MPS (0x0002) when more than one channel gets its MPS reduced: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 8 MTU: 264 MPS: 99 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Fix L2CAP/ECFC/BI-05-C when SCID is invalid (85 unconnected): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 65 MPS: 64 ! Source CID: 85 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - one or more Destination CIDs invalid (0x0003) Fix L2CAP/ECFC/BI-06-C when MPS < L2CAP_ECRED_MIN_MPS (64): > ACL Data RX: Handle 64 flags 0x02 dlen 14 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 2 len 6 MTU: 672 ! MPS: 63 Source CID: 64 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Result: Reconfiguration failed - other unacceptable parameters (0x0004) Fix L2CAP/ECFC/BI-07-C when MPS reduced for more than one channel: > ACL Data RX: Handle 64 flags 0x02 dlen 16 LE L2CAP: Enhanced Credit Reconfigure Request (0x19) ident 3 len 8 MTU: 84 ! MPS: 71 Source CID: 64 ! Source CID: 65 < ACL Data TX: Handle 64 flags 0x00 dlen 10 LE L2CAP: Enhanced Credit Reconfigure Respond (0x1a) ident 2 len 2 ! Result: Reconfiguration successful (0x0000) Result: Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time (0x0002) Link: https://github.com/bluez/bluez/issues/1865 Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 464808911fb9ddcea141801808c65326266a8f20 Author: Linus Torvalds Date: Mon Feb 23 11:18:48 2026 -0800 Remove WARN_ALL_UNSEEDED_RANDOM kernel config option [ Upstream commit 7dff99b354601dd01829e1511711846e04340a69 ] This config option goes way back - it used to be an internal debug option to random.c (at that point called DEBUG_RANDOM_BOOT), then was renamed and exposed as a config option as CONFIG_WARN_UNSEEDED_RANDOM, and then further renamed to the current CONFIG_WARN_ALL_UNSEEDED_RANDOM. It was all done with the best of intentions: the more limited rate-limited reports were reporting some cases, but if you wanted to see all the gory details, you'd enable this "ALL" option. However, it turns out - perhaps not surprisingly - that when people don't care about and fix the first rate-limited cases, they most certainly don't care about any others either, and so warning about all of them isn't actually helping anything. And the non-ratelimited reporting causes problems, where well-meaning people enable debug options, but the excessive flood of messages that nobody cares about will hide actual real information when things go wrong. I just got a kernel bug report (which had nothing to do with randomness) where two thirds of the the truncated dmesg was just variations of random: get_random_u32 called from __get_random_u32_below+0x10/0x70 with crng_init=0 and in the process early boot messages had been lost (in addition to making the messages that _hadn't_ been lost harder to read). The proper way to find these things for the hypothetical developer that cares - if such a person exists - is almost certainly with boot time tracing. That gives you the option to get call graphs etc too, which is likely a requirement for fixing any problems anyway. See Documentation/trace/boottime-trace.rst for that option. And if we for some reason do want to re-introduce actual printing of these things, it will need to have some uniqueness filtering rather than this "just print it all" model. Fixes: cc1e127bfa95 ("random: remove ratelimiting for in-kernel unseeded randomness") Acked-by: Jason Donenfeld Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f204c1379a98a1331389a0798f111b0cb7faa3de Author: Johannes Berg Date: Mon Feb 9 19:12:20 2026 +0100 wifi: cfg80211: wext: fix IGTK key ID off-by-one [ Upstream commit c8d7f21ead727485ebf965e2b4d42d4a4f0840f6 ] The IGTK key ID must be 4 or 5, but the code checks against key ID + 1, so must check against 5/6 rather than 4/5. Fix that. Reported-by: Jouni Malinen Fixes: 08645126dd24 ("cfg80211: implement wext key handling") Link: https://patch.msgid.link/20260209181220.362205-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cf95db5e33bd4a3ca227b1ab67a0b4c1e1923e4f Author: Pavan Chebbi Date: Thu Feb 19 10:53:12 2026 -0800 bnxt_en: Fix deleting of Ntuple filters [ Upstream commit c1bbd9900d65ac65b9fce9f129e3369a04871570 ] Ntuple filters can be deleted when the interface is down. The current code blindly sends the filter delete command to FW. When the interface is down, all the VNICs are deleted in the FW. When the VNIC is freed in the FW, all the associated filters are also freed. We need not send the free command explicitly. Sending such command will generate FW error in the dmesg. In order to fix this, we can safely return from bnxt_hwrm_cfa_ntuple_filter_free() when BNXT_STATE_OPEN is not true which confirms the VNICs have been deleted. Fixes: 8336a974f37d ("bnxt_en: Save user configured filters in a lookup list") Suggested-by: Michael Chan Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 348a5f8d06c7bdf954e13c17ad5f80b59a075604 Author: Pavan Chebbi Date: Thu Feb 19 10:53:11 2026 -0800 bnxt_en: Fix RSS context delete logic [ Upstream commit e123d9302d223767bd910bfbcfe607bae909f8ac ] We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context. Reported-by: Jakub Kicinski Fixes: 667ac333dbb7 ("eth: bnxt: allow deleting RSS contexts when the device is down") Reviewed-by: Andy Gospodarek Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260219185313.2682148-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 21d1e80d0d6e7d0c3cd8b1e001ed1fa92fb9f3f5 Author: Linus Walleij Date: Thu Feb 19 12:38:50 2026 +0100 net: ethernet: xscale: Check for PTP support properly [ Upstream commit 594163ea88a03bdb412063af50fc7177ef3cbeae ] In ixp4xx_get_ts_info() ixp46x_ptp_find() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump: root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptp_clock_index from ixp46x_ptp_find+0x1c/0x38 ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64 ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108 __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648 __dev_ethtool from dev_ethtool+0x160/0x234 dev_ethtool from dev_ioctl+0x2cc/0x460 dev_ioctl from sock_ioctl+0x1ec/0x524 sock_ioctl from sys_ioctl+0x51c/0xa94 sys_ioctl from ret_fast_syscall+0x0/0x44 (...) Segmentation fault Check for ixp46x in ixp46x_ptp_find() before trying to set up PTP to avoid this. To avoid altering the returned error code from ixp4xx_hwtstamp_set() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter the error code. The helper function ixp46x_ptp_find() helper returns -ENODEV. Fixes: 9055a2f59162 ("ixp4xx_eth: make ptp support a platform driver") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260219-ixp4xx-fix-ethernet-v3-1-f235ccc3cd46@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d077c45b34b8bc72cb9c70c3c547bd32617a610d Author: Vladimir Oltean Date: Fri May 9 00:10:42 2025 +0300 net: ixp4xx_eth: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() [ Upstream commit c14e1ecefd9e706262ac713fd27530e3344ef85c ] New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the intel ixp4xx ethernet driver to the new API, so that the ndo_eth_ioctl() path can be removed completely. hwtstamp_get() and hwtstamp_set() are only called if netif_running() when the code path is engaged through the legacy ioctl. As I don't want to make an unnecessary functional change which I can't test, preserve that restriction when going through the new operations. When cpu_is_ixp46x() is false, the execution of SIOCGHWTSTAMP and SIOCSHWTSTAMP falls through to phy_mii_ioctl(), which may process it in case of a timestamping PHY, or may return -EOPNOTSUPP. In the new API, the core handles timestamping PHYs directly and does not call the netdev driver, so just return -EOPNOTSUPP directly for equivalent logic. A gratuitous change I chose to do anyway is prefixing hwtstamp_get() and hwtstamp_set() with the driver name, ipx4xx. This reflects modern coding sensibilities, and we are touching the involved lines anyway. The remainder of eth_ioctl() is exactly equivalent to phy_do_ioctl_running(), so use that. Signed-off-by: Vladimir Oltean Reviewed-by: Vadim Fedorenko Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20250508211043.3388702-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 594163ea88a0 ("net: ethernet: xscale: Check for PTP support properly") Signed-off-by: Sasha Levin commit b88194c1cfe7b799f40db469938247a0676e14b4 Author: Martin Pålsson Date: Wed Feb 18 05:28:22 2026 +0000 net: usb: lan78xx: scan all MDIO addresses on LAN7801 [ Upstream commit f1e2f0ce704e4a14e3f367d3b97d3dd2d8e183b7 ] The LAN7801 is designed exclusively for external PHYs (unlike the LAN7800/LAN7850 which have internal PHYs), but lan78xx_mdio_init() restricts PHY scanning to MDIO addresses 0-7 by setting phy_mask to ~(0xFF). This prevents discovery of external PHYs wired to addresses outside that range. One such case is the DP83TC814 100BASE-T1 PHY, which is typically configured at MDIO address 10 via PHYAD bootstrap pins and goes undetected with the current mask. Remove the restrictive phy_mask assignment for the LAN7801 so that the default mask of 0 applies, allowing all 32 MDIO addresses to be scanned during bus registration. Fixes: 02dc1f3d613d ("lan78xx: add LAN7801 MAC only support") Signed-off-by: Martin Pålsson Link: https://patch.msgid.link/0110019c6f388aff-98d99cf0-4425-4fff-b16b-dea5ad8fafe0-000000@eu-north-1.amazonses.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c79b839a63980c7da7ec5db895198045e154112 Author: Ziyi Guo Date: Tue Feb 17 17:50:12 2026 +0000 net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode [ Upstream commit 64868f5ecadeb359a49bc4485bfa7c497047f13a ] kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time. Suggested-by: Paolo Abeni Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260217175012.1234494-1-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7ad8b1d0e421c524604d5076b73232093490d5c Author: Hyunwoo Kim Date: Wed Feb 18 02:16:43 2026 +0900 espintcp: Fix race condition in espintcp_close() [ Upstream commit e1512c1db9e8794d8d130addd2615ec27231d994 ] This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync(). Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Hyunwoo Kim Reviewed-by: Simon Horman Link: https://patch.msgid.link/aZSie7rEdh9Nu0eM@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3c8fede034fa27892f87c863cbd5493167d17ed Author: Tetsuo Handa Date: Fri Jan 30 19:42:47 2026 +0900 xfrm: always flush state and policy upon NETDEV_UNREGISTER event [ Upstream commit 4efa91a28576054aae0e6dad9cba8fed8293aef8 ] syzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") implemented xfrm_dev_unregister() as no-op despite xfrm_dev_state_add() from xfrm_state_construct() acquires a reference to "struct net_device". I guess that that commit expected that NETDEV_DOWN event is fired before NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() is called only if (dev->features & NETIF_F_HW_ESP) != 0. Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_device Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after xfrm_dev_state_add() acquired a reference to "struct net_device". Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit when acquiring a reference to "struct net_device". Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that commit for unknown reason chose to share xfrm_dev_down() between the NETDEV_DOWN event and the NETDEV_UNREGISTER event. I guess that that commit missed the behavior in the previous paragraph. Therefore, we need to re-introduce xfrm_dev_unregister() in order to release the reference to "struct net_device" by unconditionally flushing state and policy. Reported-by: syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Cc: Sabrina Dubroca Signed-off-by: Tetsuo Handa Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2dfbc8c17dd161885336e77e71c336cd62cf6748 Author: Matt Johnston Date: Tue Jan 13 17:41:34 2026 +0800 ipmi: ipmb: initialise event handler read bytes [ Upstream commit 9f235ccecd03c436cb1683eac16b12f119e54aa9 ] IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Matt Johnston Message-ID: <20260113-ipmb-read-init-v1-1-a9cbce7b94e3@codeconstruct.com.au> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit f1713988e9325b6cdb9d8503eaaac4767723d6f4 Author: Leon Romanovsky Date: Tue Jan 27 14:49:23 2026 +0200 xfrm: skip templates check for packet offload tunnel mode [ Upstream commit 0a4524bc69882a4ddb235bb6b279597721bda197 ] In packet offload, hardware is responsible to check templates. The result of its operation is forwarded through secpath by relevant drivers. That secpath is actually removed in __xfrm_policy_check2(). In case packet is forwarded, this secpath is reset in RX, but pushed again to TX where policy is rechecked again against dummy secpath in xfrm_policy_ok(). Such situation causes to unexpected XfrmInTmplMismatch increase. As a solution, simply skip template mismatch check. Fixes: 600258d555f0 ("xfrm: delete intermediate secpath entry in packet offload mode") Signed-off-by: Leon Romanovsky Reviewed-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit dc0abce055134cb83b0d981d31ceb20dda419787 Author: Jiayuan Chen Date: Tue Jan 27 19:38:44 2026 +0800 xfrm6: fix uninitialized saddr in xfrm6_get_saddr() [ Upstream commit 1799d8abeabc68ec05679292aaf6cba93b343c05 ] xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error. Fixes: a1e59abf8249 ("[XFRM]: Fix wildcard as tunnel source") Reported-by: syzbot+e136d86d34b42399a8b1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68bf1024.a70a0220.7a912.02c2.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2e4d5e8d86a969318340be95470bb76e52392082 Author: Maciej Grochowski Date: Thu Feb 13 14:53:17 2025 -0800 ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut [ Upstream commit 186615f8855a0be4ee7d3fcd09a8ecc10e783b08 ] Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 0e930420945106151c6eb3d7837b4e6154e9b144 Author: Maciej Grochowski Date: Thu Feb 13 14:53:18 2025 -0800 ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access [ Upstream commit c8ba7ad2cc1c7b90570aa347b8ebbe279f1eface ] Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid. Signed-off-by: Maciej Grochowski Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit faf7f4073d5d6965ea4587509f152dc3504aa29d Author: Tomas Melin Date: Thu Jan 22 13:53:45 2026 +0000 rtc: zynqmp: correct frequency value [ Upstream commit 2724fb4d429cbb724dcb6fa17953040918ebe3a2 ] Fix calibration value in case a clock reference is provided. The actual calibration value written into register is frequency - 1. Reviewed-by: Harini T Tested-by: Harini T Signed-off-by: Tomas Melin Acked-by: Michal Simek Link: https://patch.msgid.link/20260122-zynqmp-rtc-updates-v4-1-d4edb966b499@vaisala.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit d4c08521c77db29291fb1d7400d9441bade3af01 Author: Alex Hung Date: Wed Feb 4 22:05:16 2026 -0700 drm/amd/display: Remove conditional for shaper 3DLUT power-on [ Upstream commit 1b38a87b8f8020e8ef4563e7752a64182b5a39b9 ] [Why] Shaper programming has high chance to fail on first time after power-on or reboot. This can be verified by running IGT's kms_colorop. [How] Always power on the shaper and 3DLUT before programming by removing the debug flag of low power mode. Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Hung Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5c3de2cae7ced2d1e47b254c8e7e7c3c99ccf63d Author: Arnd Bergmann Date: Mon Feb 16 11:54:21 2026 +0100 arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16) [ Upstream commit 729a2e8e9ac47099a967567389cc9d73ef4194ca ] gcc-16 warns about an instance that older compilers did not: arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_clear': arch/arm64/mm/hugetlbpage.c:369:57: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter=] The issue here is that __pte_clear() does not actually use its second argument, but when CONFIG_ARM64_CONTPTE is enabled it still gets updated. Replace the macro with an inline function to let the compiler see the argument getting passed down. Suggested-by: Catalin Marinas Signed-off-by: Arnd Bergmann Reviewed-by: Dev Jain Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4f2eb019d87bc17081b37f8f4d671b92626907d1 Author: Adarsh Das Date: Tue Feb 3 22:53:57 2026 +0530 btrfs: replace BUG() with error handling in __btrfs_balance() [ Upstream commit be6324a809dbda76d5fdb23720ad9b20e5c1905c ] We search with offset (u64)-1 which should never match exactly. Previously this was handled with BUG(). Now logs an error and return -EUCLEAN. Reviewed-by: Qu Wenruo Signed-off-by: Adarsh Das Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fc9e5af60dc199051dc202ae78e1fe76a9977a5e Author: Takashi Iwai Date: Mon Feb 16 15:12:07 2026 +0100 ALSA: usb-audio: Add sanity check for OOB writes at silencing [ Upstream commit fba2105a157fffcf19825e4eea498346738c9948 ] At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Link: https://patch.msgid.link/20260216141209.1849200-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7a3b0a893b945ce10cdf8db9f5babaf70d3807f5 Author: decce6 Date: Tue Feb 10 07:26:00 2026 +0000 drm/radeon: Add HAINAN clock adjustment [ Upstream commit 908d318f23d6b5d625bea093c5fc056238cdb7ff ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for radeon. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f8431b8672231d378b03176fe74c95adfd3522cf Author: Fabian Godehardt Date: Wed Feb 11 08:26:16 2026 +0100 spi: spidev: fix lock inversion between spi_lock and buf_lock [ Upstream commit 40534d19ed2afb880ecf202dab26a8e7a5808d16 ] The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path: write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks: WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK *** The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor. Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock. buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues. This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour. Signed-off-by: Fabian Godehardt Link: https://patch.msgid.link/20260211072616.489522-1-fg@emlix.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b701db9f535a7ccf8c1cba960e0df359557f6eff Author: Clay King Date: Fri Jan 30 11:40:06 2026 -0500 drm/amd/display: bypass post csc for additional color spaces in dal [ Upstream commit 7d9ec9dc20ecdb1661f4538cd9112cd3d6a5f15a ] [Why] For RGB BT2020 full and limited color spaces, overlay adjustments were applied twice (once by MM and once by DAL). This results in incorrect colours and a noticeable difference between mpo and non-mpo cases. [How] Add RGB BT2020 full and limited color spaces to list that bypasses post csc adjustment. Reviewed-by: Aric Cyr Signed-off-by: Clay King Signed-off-by: Tom Chung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6561e0914ac9cbdcc53af51794317f6da74ac95c Author: decce6 Date: Tue Feb 10 07:24:01 2026 +0000 drm/amdgpu: Add HAINAN clock adjustment [ Upstream commit 49fe2c57bdc0acff9d2551ae337270b6fd8119d9 ] This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for amdgpu. Signed-off-by: decce6 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 32a1f64f8ff6e2c5391f5964baec697bce25b83c Author: Takashi Iwai Date: Mon Feb 16 15:12:05 2026 +0100 ALSA: usb-audio: Update the number of packets properly at receiving [ Upstream commit cf044e44190234a41a788de1cdbb6c21f4a52e1e ] At receiving the packets from the implicit feedback source, we didn't update ctx->packets field but only the ctx->packet_size[] data. In exceptional cases, this might lead to unexpectedly superfluous data transfer (although this won't happen usually due to the nature of USB isochronous transfer). Fix it to update the field properly. Link: https://patch.msgid.link/20260216141209.1849200-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2d9cb8a280aa680280d7c88303151d8817d34277 Author: Ce Sun Date: Tue Feb 10 15:32:01 2026 +0800 drm/amdgpu: Adjust usleep_range in fence wait [ Upstream commit 3ee1c72606bd2842f0f377fd4b118362af0323ae ] Tune the sleep interval in the PSP fence wait loop from 10-100us to 60-100us.This adjustment results in an overall wait window of 1.2s (60us * 20000 iterations) to 2 seconds (100us * 20000 iterations), which guarantees that we can retrieve the correct fence value Signed-off-by: Ce Sun Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3fb5155a39ab3a4718878d8b3d660d7de802c818 Author: Wayne Lin Date: Fri Jan 23 14:47:01 2026 +0800 drm/amd/display: Avoid updating surface with the same surface under MPO [ Upstream commit 1a38ded4bc8ac09fd029ec656b1e2c98cc0d238c ] [Why & How] Although it's dummy updates of surface update for committing stream updates, we should not have dummy_updates[j].surface all indicating to the same surface under multiple surfaces case. Otherwise, copy_surface_update_to_plane() in update_planes_and_stream_state() will update to the same surface only. Reviewed-by: Harry Wentland Signed-off-by: Wayne Lin Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 761b208dfafc843a31f1494167cd642badf21ea1 Author: Tom Chung Date: Tue Jan 20 18:10:31 2026 +0800 drm/amd/display: Fix system resume lag issue [ Upstream commit 64c94cd9be2e188ed07efeafa6a109bce638c967 ] [Why] System will try to apply idle power optimizations setting during system resume. But system power state is still in D3 state, and it will cause the idle power optimizations command not actually to be sent to DMUB and cause some platforms to go into IPS. [How] Set power state to D0 first before calling the dc_dmub_srv_apply_idle_power_optimizations(dm->dc, false) Reviewed-by: Nicholas Kazlauskas Signed-off-by: Tom Chung Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9a4483972bf73673511dcd0c1a22035b7c7751d6 Author: Alex Hung Date: Wed Jan 14 17:20:31 2026 -0700 drm/amd/display: Fix writeback on DCN 3.2+ [ Upstream commit 9ef84a307582a92ef055ef0bd3db10fd8ac75960 ] [WHAT] 1. Set no scaling for writeback as they are hardcoded in DCN3.2+. 2. Set no fast plane update for writeback commits. Reviewed-by: Harry Wentland Signed-off-by: Alex Hung Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8ec5b525221ef386b8a9693acdc60e082b043b7a Author: Thomas Weissschuh Date: Wed Jan 7 10:56:33 2026 +0100 ARM: 9467/1: mm: Don't use %pK through printk [ Upstream commit 012ea376a5948b025f260aa45d2a6ec5d96674ea ] Restricted pointers ("%pK") were never meant to be used through printk(). They can acquire sleeping locks in atomic contexts. Switch to %px over the more secure %p as this usage is a debugging aid, gated behind CONFIG_DEBUG_VIRTUAL and used by WARN(). Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 44c8c02779bfc260cae1a18890ae914257ae1473 Author: Phil Sutter Date: Sat Feb 14 15:54:06 2026 +0100 include: uapi: netfilter_bridge.h: Cover for musl libc [ Upstream commit 4edd4ba71ce0df015303dba75ea9d20d1a217546 ] Musl defines its own struct ethhdr and thus defines __UAPI_DEF_ETHHDR to zero. To avoid struct redefinition errors, user space is therefore supposed to include netinet/if_ether.h before (or instead of) linux/if_ether.h. To relieve them from this burden, include the libc header here if not building for kernel space. Reported-by: Alyssa Ross Suggested-by: Florian Westphal Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 09e437ba3f2d0bc374e90b8c112e9c7ab90788d0 Author: Yauhen Kharuzhy Date: Thu Feb 12 00:22:42 2026 +0200 ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 [ Upstream commit a8c975302868c716afef0f50467bebbd069a35b8 ] The PWM2 on YB1-X90 tablets is used for keyboard backlight control but it is disabled in the ACPI DSDT table. Add it to the override_status_ids list to allow keyboard function control driver (drivers/platform/x86/lenovo/yogabook.c) to use it. Signed-off-by: Yauhen Kharuzhy Link: https://patch.msgid.link/20260211222242.4101162-1-jekhor@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ecd2fc9e4c3237767cd24bf3c198b427cfd1b989 Author: Kaushlendra Kumar Date: Wed Feb 11 08:23:15 2026 +0000 thermal: int340x: Fix sysfs group leak on DLVR registration failure [ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ] When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier. Add proper error unwinding to remove the FIVR group before returning failure. Signed-off-by: Kaushlendra Kumar Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR11MB8768.namprd11.prod.outlook.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1b275bd49e58752efb83767a5d1aed41356c5e64 Author: Ilya Dryomov Date: Fri Jul 4 16:30:50 2025 +0200 libceph: define and enforce CEPH_MAX_KEY_LEN [ Upstream commit ac431d597a9bdfc2ba6b314813f29a6ef2b4a3bf ] When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway. Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit a46cec9cc5b2c022d9ee9de4d04cf99d383ec7a0 Author: ethanwu Date: Thu Sep 25 18:42:06 2025 +0800 ceph: supply snapshot context in ceph_uninline_data() [ Upstream commit 305ff6b3a03c230d3c07b61457e961406d979693 ] The ceph_uninline_data function was missing proper snapshot context handling for its OSD write operations. Both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests were passing NULL instead of the appropriate snapshot context, which could lead to unnecessary object clone. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore // turn on cephfs inline data ./bin/ceph fs set a inline_data true --yes-i-really-really-mean-it // allow fs_a client to take snapshot ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' // mount cephfs with fuse, since kernel cephfs doesn't support inline write ceph-fuse --id fs_a -m 127.0.0.1:40318 --conf ceph.conf -d /mnt/mycephfs/ // bump snapshot seq mkdir /mnt/mycephfs/.snap/snap1 echo "foo" > /mnt/mycephfs/test // umount and mount it again using kernel cephfs client umount /mnt/mycephfs mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf echo "bar" >> /mnt/mycephfs/test ./bin/rados listsnaps -p cephfs.a.data $(printf "%x\n" $(stat -c %i /mnt/mycephfs/test)).00000000 will see this object does unnecessary clone 1000000000a.00000000 (seq:2): cloneid snaps size overlap 2 2 4 [] head - 8 but it's expected to see 10000000000.00000000 (seq:2): cloneid snaps size overlap head - 8 since there's no snapshot between these 2 writes clone happened because the first osd request CEPH_OSD_OP_CREATE doesn't pass snap context so object is created with snap seq 0, but later data writeback is equipped with snapshot context. snap.seq(1) > object snap seq(0), so osd does object clone. This fix properly acquiring the snapshot context before performing write operations. Signed-off-by: ethanwu Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 39aef9080f2728fc34a3ca393c970aee2e6ef88c Author: Konstantin Komarov Date: Mon Feb 9 16:07:32 2026 +0100 fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() [ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ] When ntfs_read_run_nb_ra() is invoked with run == NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512230646.v5hrYXL0-lkp@intel.com/ Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 9b877e5e1cbf8b5007d061c14484d94d6cf5ea16 Author: Konstantin Komarov Date: Fri Dec 12 14:27:48 2025 +0300 fs/ntfs3: drop preallocated clusters for sparse and compressed files [ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ] Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 7ef219656febf5ae06ae56b1fce47ebd05f92b68 Author: Jaehun Gou Date: Tue Dec 2 20:01:46 2025 +0900 fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST [ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it. When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread. This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 78b61f7eac37a63284774b147f38dd0be6cad43c Author: Jaehun Gou Date: Tue Dec 2 20:01:09 2025 +0900 fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata [ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop. This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 398e768d1accd1f5645492ab996005d7aa84a5b0 Author: Jaehun Gou Date: Tue Dec 2 19:59:59 2025 +0900 fs: ntfs3: check return value of indx_find to avoid infinite loop [ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ] We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition. A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash. This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation. Co-developed-by: Seunghun Han Signed-off-by: Seunghun Han Co-developed-by: Jihoon Kwon Signed-off-by: Jihoon Kwon Signed-off-by: Jaehun Gou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0569822bb36c58c4ac59b96bdc8836bb2bbbadee Author: John Garry Date: Wed Jan 7 09:40:06 2026 +0000 MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE [ Upstream commit d55d3fe2d1470ac5b6e93efe7998b728013c9fc8 ] The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Signed-off-by: John Garry Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit f86bee0ef4fd810135fda7e1aa99cb9207bfdd64 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:38 2026 +0100 iio: magnetometer: Remove IRQF_ONESHOT [ Upstream commit a54e9440925e6617c98669066b4753c4cdcea8a0 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The force-threading functionality is required on PREEMPT_RT because the handler is using locks with can sleep on PREEMPT_RT. Remove IRQF_ONESHOT from irqflags. Tested-by: Geert Uytterhoeven Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 48be61552318fc9e04be060596043e6d0a54972a Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:36 2026 +0100 iio: Use IRQF_NO_THREAD [ Upstream commit 04d390af97f2c28166f7ddfe1a6bda622e3a4766 ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handler and this supposed to happen from within the hardirq. Use IRQF_NO_THREAD to forbid forced-threading. Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a4c15468585582e4832a3d07090ac7c48db291db Author: Ilpo Järvinen Date: Tue Jan 13 19:21:50 2026 +0200 mfd: intel-lpss: Add Intel Nova Lake-S PCI IDs [ Upstream commit cefd793fa17de708d043adab50e7f96f414b0f1d ] Add Intel Nova Lake-S LPSS PCI IDs. Signed-off-by: Ilpo Järvinen Acked-by: Andy Shevchenko Link: https://patch.msgid.link/20260113172151.48062-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 1fb137d985f2e252ddd17c48eb5356a77b09633e Author: Marcus Folkesson Date: Mon Nov 24 17:16:51 2025 +0100 Revert "mfd: da9052-spi: Change read-mask to write-mask" [ Upstream commit 12daa9c1954542bf98bb942fb2dadf19de79a44b ] This reverts commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed. Almost every register in this chip can be customized via OTP memory. Somehow the value for R19, which decide if the flag is set on read or write operation, seems to have been overwritten for the chip the original patch were written for. Revert the change to follow the default behavior. Signed-off-by: Marcus Folkesson Link: https://patch.msgid.link/20251124-da9052-revert-v1-1-fbeb2c894002@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 0bfb54195be699d014f7fa8007bf8996be71f757 Author: Xu Yang Date: Tue Jan 20 19:17:12 2026 +0800 phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature [ Upstream commit 27ee0869d77b2cb404770ac49bdceae3aedf658b ] Disabling PHYs in runtime usually causes the client with external abort exception or similar issue due to lack of API to notify clients about PHY removal. This patch removes the possibility to unbind i.MX PHY drivers in runtime. Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260120111712.3159782-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c435e63530f7f5f9fa92e0093332552a770004c9 Author: Aleksandar Gerasimovski Date: Tue Jan 6 15:06:43 2026 +0000 phy: mvebu-cp110-utmi: fix dr_mode property read from dts [ Upstream commit e2ce913452ab56b3330539cc443b97b7ea8c3a1a ] The problem with the current implementation is that it does not consider that the USB controller can have multiple PHY handles with different arguments count, as for example we have in our cn9131 based platform: "phys = <&cp0_comphy1 0>, <&cp0_utmi0>;". In such case calling "of_usb_get_dr_mode_by_phy" with -1 (no phy-cells) leads to not proper phy detection, taking the "marvell,cp110-utmi-phy" dts definition we can call the "of_usb_get_dr_mode_by_phy" with 0 (#phy-cells = <0>) and safely look for that phy. Signed-off-by: Aleksandar Gerasimovski Link: https://patch.msgid.link/20260106150643.922110-1-aleksandar.gerasimovski@belden.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5db6da613e9ca07bd195ee30dc91dd489c0d5995 Author: Oleksandr Suvorov Date: Sun Nov 23 22:24:33 2025 +0200 watchdog: imx7ulp_wdt: handle the nowayout option [ Upstream commit d303d37ef5cf86c8c3b2daefd2a7d7fd8ca1ec14 ] The module parameter `nowayout` indicates whether the watchdog should ever be allowed to stop, but the driver currently ignores this option. Pass the `nowayout` parameter to the watchdog core by setting the WDOG_NO_WAY_OUT flag accordingly. Signed-off-by: Oleksandr Suvorov Reviewed-by: Guenter Roeck Reviewed-by: Frank Li Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 21cc92fddf4fca31d2b0c48b73f6b59ee1baa86f Author: Thomas Weißschuh Date: Wed Jan 7 15:29:50 2026 +0100 binder: don't use %pK through printk [ Upstream commit 56d21267663bad91e8b10121224ec46366a7937e ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260107-restricted-pointers-binder-v1-1-181018bf3812@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bf66b535daed1cd0a0e208a87ccc07325902f7f9 Author: René Rebe Date: Mon Nov 17 13:11:24 2025 +0100 fix it87_wdt early reboot by reporting running timer [ Upstream commit 88b2ab346436f799b99894a3e9518a3ffa344524 ] Some products, such as the Ugreen DXP4800 Plus NAS, ship with the it87 wdt enabled by the firmware and a broken BIOS option that does not allow to change the time or turn it off. As this makes installing Linux rather difficult, change the it87_wdt to report it running to the watchdog core. Signed-off-by: René Rebe Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 29e9413dfae9898078f3dda801471d3b0f51c9bb Author: Moteen Shah Date: Mon Jan 12 13:48:29 2026 +0530 serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done [ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ] Clear rx_running flag only after DMA teardown polling completes. In the previous implementation the flag was being cleared while hardware teardown was still in progress, creating a mismatch between software state (flag = 0, "ready") and hardware state (still terminating). Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aebf83897bb699de1c2bdab3dc79de76e8f1efaa Author: Moteen Shah Date: Mon Jan 12 13:48:28 2026 +0530 serial: 8250: 8250_omap.c: Add support for handling UART error conditions [ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ] The DMA IRQ handler does not accounts for the overrun(OE) or any other errors being reported by the IP before triggering a DMA transaction which leads to the interrupts not being handled resulting into an IRQ storm. The way to handle OE is to: 1. Reset the RX FIFO. 2. Read the UART_RESUME register, which clears the internal flag Earlier, the driver issued DMA transations even in case of OE which shouldn't be done according to the OE handling mechanism mentioned above, as we are resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During Receive" [0]. [0] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-2-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9f70f78e22b321429afc77befecedf05543d4e2c Author: Diksha Kumari Date: Tue Jan 13 14:47:12 2026 +0530 staging: rtl8723bs: fix memory leak on failure path [ Upstream commit abe850d82c8cb72d28700673678724e779b1826e ] cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths. Signed-off-by: Diksha Kumari Reviewed-by: Mukesh Kumar Chaurasiya Link: https://patch.msgid.link/20260113091712.7071-1-dikshakdevgan@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b72b834511d17f4d069d512f78671f3f210a2f1 Author: Mario Peter Date: Thu Jan 8 16:59:02 2026 +0000 usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke() [ Upstream commit cea2a1257a3b5ea3e769a445b34af13e6aa5a123 ] The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers. Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption. The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state. Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=false if bounce buffer exists This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted). Signed-off-by: Mario Peter Reviewed-by: Xu Yang Acked-by: Peter Chen Link: https://patch.msgid.link/20260108165902.795354-1-mario.peter@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f505b91db2c008424d1c896c879335988164170f Author: Sam Day Date: Thu Jan 8 08:30:20 2026 +1000 usb: gadget: f_fs: Fix ioctl error handling [ Upstream commit 8e4c1d06183c25022f6b0002a5cab84979ca6337 ] When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-1-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3875c8eca2df68c9077d2bdbe2d49c10827022e9 Author: Sam Day Date: Thu Jan 8 08:30:21 2026 +1000 usb: gadget: f_fs: fix DMA-BUF OUT queues [ Upstream commit 0145e7acd29855dfba4a2f387d455b5d9a520f0e ] Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day Tested-by: David Heidelberg # OnePlus 6T on sdm845-next-20251119 Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-2-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d55fe3cd765e07c1f7a0c68e01134bf6d35a85e Author: Markus Perkins Date: Tue Dec 2 11:48:24 2025 +0100 misc: eeprom: Fix EWEN/EWDS/ERAL commands for 93xx56 and 93xx66 [ Upstream commit b54c82d6cbfc76647ba558e8e3647eb2b0ba0e2b ] commit 14374fbb3f06 ("misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings") added support for 93xx56 and 93xx66 eeproms, but didn't take into account that the write enable/disable + erase all commands are hardcoded for the 6-bit address of the 93xx46. This commit fixes the command word generation by increasing the number of shifts as the address field grows, keeping the command intact. Also, the check for 8-bit or 16-bit mode is no longer required as this is already taken into account in the edev->addrlen field. Signed-off-by: Markus Perkins Link: https://patch.msgid.link/20251202104823.429869-3-markus@notsyncing.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aa97ccc3dc1eba9f4537f0410e9dbb0b05ccf2fb Author: Tuo Li Date: Thu Dec 11 14:36:37 2025 +0800 misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read() [ Upstream commit ba75ecb97d3f4e95d59002c13afb6519205be6cb ] In the function bcm_vk_read(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences: struct vk_msg_blk tmp_msg = entry->to_h_msg[0]; set_msg_id(&tmp_msg, entry->usr_msg_id); tmp_msg.size = entry->to_h_blks - 1; To prevent these possible null-pointer dereferences, copy to_h_msg, usr_msg_id, and to_h_blks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry. Signed-off-by: Tuo Li Reviewed-by: Scott Branden Link: https://patch.msgid.link/20251211063637.3987937-1-islituo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 297428ee6f6ee7b01a02099bb6bbd67c48c4db48 Author: Thomas Richard (TI.com) Date: Tue Dec 16 15:24:25 2025 +0100 phy: cadence-torrent: restore parent clock for refclk during resume [ Upstream commit 434e1a0ee145d0389b192252be4c993f86cf1134 ] While suspend and resume, parent clock config for refclk was getting lost. So save and restore it in suspend and resume operations. Reviewed-by: Neil Armstrong Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-cadence-torrent-resume-restore-refclk-parent-v3-1-8a7ed84b47e3@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2930ddda92739ea8367d21e23b015a84d41a3811 Author: Thomas Richard (TI.com) Date: Tue Dec 16 15:26:20 2025 +0100 phy: ti: phy-j721e-wiz: restore mux selection during resume [ Upstream commit 53f6240e88c9e8715e09fc19942f13450db4cb33 ] While suspend and resume mux selection was getting lost. So save and restore these values in suspend and resume operations. Signed-off-by: Thomas Richard (TI.com) Link: https://patch.msgid.link/20251216-phy-ti-phy-j721e-wiz-resume-restore-mux-sel-v1-1-771d564db966@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 874558ec341b22f8b9adc89e3cd5ea7221c9e212 Author: Clément Le Goffic Date: Wed Dec 17 09:15:03 2025 +0100 dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warnings [ Upstream commit aaf3bc0265744adbc2d364964ef409cf118d193d ] m2m_hw_period is initialized only when chan_config->m2m_hw is true. This triggers a warning: ‘m2m_hw_period’ may be used uninitialized [-Wmaybe-uninitialized] Although m2m_hw_period is only used when chan_config->m2m_hw is true and ignored otherwise, initialize it unconditionally to 0. ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not empty. This triggers a warning: ‘ccr’ may be used uninitialized [-Wmaybe-uninitialized] Indeed, it could be used uninitialized if the sg list is empty. Initialize it to 0. Signed-off-by: Clément Le Goffic Reviewed-by: Clément Le Goffic Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 340d7c73dab7121696e3969f45e5960d8a8db3cf Author: Chen-Yu Tsai Date: Sun Dec 21 16:04:48 2025 +0800 dmaengine: sun6i: Choose appropriate burst length under maxburst [ Upstream commit 7178c3586ab42693b28bb81014320a7783e5c435 ] maxburst, as provided by the client, specifies the largest amount of data that is allowed to be transferred in one burst. This limit is normally provided to avoid a data burst overflowing the target FIFO. It does not mean that the DMA engine can only do bursts in that size. Let the driver pick the largest supported burst length within the given limit. This lets the driver work correctly with some clients that give a large maxburst value. In particular, the 8250_dw driver will give a quarter of the UART's FIFO size as maxburst. On some systems the FIFO size is 256 bytes, giving a maxburst of 64 bytes, while the hardware only supports bursts of up to 16 bytes. Signed-off-by: Chen-Yu Tsai Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251221080450.1813479-1-wens@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a49028a796d7b94f8e3ab9bd34b18f36be235459 Author: Navaneeth K Date: Thu Nov 27 16:53:37 2025 +0000 most: core: fix resource leak in most_register_interface error paths [ Upstream commit 1f4c9d8a1021281750c6cda126d6f8a40cc24e71 ] The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal Signed-off-by: Navaneeth K Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20251127165337.19172-1-knavaneeth786@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12afc931e7c7e4d170fe7e7b0146e839539ebd8b Author: Romain Gantois Date: Thu Nov 27 16:58:48 2025 +0100 fpga: of-fpga-region: Fail if any bridge is missing [ Upstream commit c141c8221bc5089de915d9f26044df892c343c7e ] When parsing the region bridge list from the "fpga-bridges" device tree property, the of-fpga-region driver will silently ignore bridges which fail to be obtained, for example due to a missing bridge driver or invalid phandle. This can lead to hardware issues if a region bridge stays coupled when partial programming is performed. Fail if any of the bridges specified in "fpga-bridges" cannot be obtained. Signed-off-by: Romain Gantois Link: https://lore.kernel.org/r/20251127-of-fpga-region-fail-if-bridges-not-found-v1-1-ca674f8d07eb@bootlin.com Reviewed-by: Xu Yilun Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 0945ed3284e912c1a3ffca6141711d93adc71e37 Author: Benson Leung Date: Mon Dec 8 17:48:48 2025 +0000 usb: typec: ucsi: psy: Fix voltage and current max for non-Fixed PDOs [ Upstream commit 6811e0a08bdce6b2767414caf17fda24c2e4e032 ] ucsi_psy_get_voltage_max and ucsi_psy_get_current_max are calculated using whichever pdo is in the last position of the src_pdos array, presuming it to be a fixed pdo, so the pdo_fixed_voltage or pdo_max_current helpers are used on that last pdo. However, non-Fixed PDOs such as Battery PDOs, Augmented PDOs (used for AVS and for PPS) may exist, and are always at the end of the array if they do. In the event one of these more advanced chargers are attached the helpers for fixed return mangled values. Here's an example case of a Google Pixel Flex Dual Port 67W USB-C Fast Charger with PPS support: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=13400000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=5790000 POWER_SUPPLY_CURRENT_NOW=3250000 Voltage Max is reading as 13.4V, but that's an incorrect decode of the PPS APDO in the last position. Same goes for CURRENT_MAX. 5.79A is incorrect. Instead, enumerate through the src_pdos and filter just for Fixed PDOs for now, and find the one with the highest voltage and current respectively. After, from the same charger: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=20000000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=4000000 POWER_SUPPLY_CURRENT_NOW=3250000 Signed-off-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20251208174918.289394-3-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3590c1751c1d3969ee765568adbc359f459408c5 Author: Artem Shimko Date: Tue Nov 4 17:54:25 2025 +0300 serial: 8250_dw: handle clock enable errors in runtime_resume [ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ] Add error checking for clk_prepare_enable() calls in dw8250_runtime_resume(). Currently if either clock fails to enable, the function returns success while leaving clocks in inconsistent state. This change implements comprehensive error handling by checking the return values of both clk_prepare_enable() calls. If the second clock enable operation fails after the first clock has already been successfully enabled, the code now properly cleans up by disabling and unpreparing the first clock before returning. The error code is then propagated to the caller, ensuring that clock enable failures are properly reported rather than being silently ignored. Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 98d6bdb521f2c9961afac6d33eb722207d1e2c1d Author: Liang Jie Date: Mon Dec 8 17:27:28 2025 +0800 staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure [ Upstream commit 618b4aec12faabc7579a6b0df046842d798a4c7c ] The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Reviewed-by: fanggeng Signed-off-by: Liang Jie Link: https://patch.msgid.link/20251208092730.262499-1-buaajxlj@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23aaf922bd3eb090b0773416b3b16175d454d031 Author: Maciej Strozek Date: Mon Dec 15 15:17:29 2025 +0000 soundwire: intel_auxdevice: add cs42l45 codec to wake_capable_list [ Upstream commit f87e5575a6bd1925cd55f500b61b661724372e5f ] Add cs42l45 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Maciej Strozek Reviewed-by: Bard Liao Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20251215151729.3911077-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d6f73398da63b035f7085bc40c4313b8d1090e39 Author: Peter Ujfalusi Date: Mon Dec 15 15:09:47 2025 +0200 soundwire: dmi-quirks: add mapping for Avell B.ON (OEM rebranded of NUC15) [ Upstream commit 59946373755d71dbd7614ba235e0093159f80b69 ] Avell B.ON is an OEM re-branded NUC15 'Bishop County' LAPBC510 and LAPBC710. Link: https://github.com/thesofproject/linux/issues/5529 Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://patch.msgid.link/20251215130947.31385-1-peter.ujfalusi@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0e6bf9b4e2917db148df221ee3ba6b0047434c4d Author: Amelie Delaunay Date: Fri Nov 21 14:36:56 2025 +0100 dmaengine: stm32-dma3: use module_platform_driver [ Upstream commit 0d41ed4ea496fabbb4dc21171e32d9a924c2a661 ] Without module_platform_driver(), stm32-dma3 doesn't have a module_exit procedure. Once stm32-dma3 module is inserted, it can't be removed, marked busy. Use module_platform_driver() instead of subsys_initcall() to register (insmod) and unregister (rmmod) stm32-dma3 driver. Reviewed-by: Eugen Hristev Signed-off-by: Amelie Delaunay Link: https://patch.msgid.link/20251121-dma3_improv-v2-1-76a207b13ea6@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a5d00dff97118a32fcf5fec7a4c3f864c4620c4e Author: Stefano Stabellini Date: Thu Jan 29 15:03:48 2026 -0800 9p/xen: protect xen_9pfs_front_free against concurrent calls [ Upstream commit ce8ded2e61f47747e31eeefb44dc24a2160a7e32 ] The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit edc3261ceb73d71efa156ef54cec5fa2769a199f Author: Daniel Palmer Date: Sat Dec 13 21:04:01 2025 +0900 m68k: nommu: fix memmove() with differently aligned src and dest for 68000 [ Upstream commit 590fe2f46c8698bb758f9002cb247ca10ce95569 ] 68000 has different alignment needs to 68020+. memcpy() checks if the destination is aligned and does a smaller copy to fix the alignment and then critically for 68000 it checks if the source is still unaligned and if it is reverts to smaller copies. memmove() does not currently do the second part and malfunctions if one of the pointers is aligned and the other isn't. This is apparently getting triggered by printk. If I put breakpoints into the new checks added by this commit the first hit looks like this: memmove (n=205, src=0x2f3971 , dest=0x2f3980 ) at arch/m68k/lib/memmove.c:82 Signed-off-by: Daniel Palmer Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit bc775cc7c0850215ae1a0d009629ce7c3a02c740 Author: Daniel Peng Date: Mon Nov 17 17:40:41 2025 +0800 HID: i2c-hid: Add FocalTech FT8112 [ Upstream commit 3d9586f1f90c9101b1abf5b0e9d70ca45f5f16db ] Information for touchscreen model HKO/RB116AS01-2 as below: - HID :FTSC1000 - slave address:0X38 - Interface:HID over I2C - Touch control lC:FT8112 - I2C ID: PNP0C50 Signed-off-by: Daniel Peng Acked-by: Jiri Kosina Reviewed-by: Douglas Anderson Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron.corp-partner.google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 563a6ab857b37a277d56b79912c125beffd09a69 Author: Brian Masney Date: Fri Dec 5 14:46:28 2025 -0500 clk: microchip: core: correct return value on *_get_parent() [ Upstream commit 5df96d141cccb37f0c3112a22fc1112ea48e9246 ] roclk_get_parent() and sclk_get_parent() has the possibility of returning -EINVAL, however the framework expects this call to always succeed since the return value is unsigned. If there is no parent map defined, then the current value programmed in the hardware is used. Let's use that same value in the case where -EINVAL is currently returned. This index is only used by clk_core_get_parent_by_index(), and it validates that it doesn't overflow the number of available parents. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202512050233.R9hAWsJN-lkp@intel.com/ Signed-off-by: Brian Masney Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20251205-clk-microchip-fixes-v3-2-a02190705e47@redhat.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 8d6bc7da802118f420df41d963a48d3a82216fee Author: Otto Pflüger Date: Sat Jan 10 16:43:36 2026 +0100 mailbox: sprd: clear delivery flag before handling TX done [ Upstream commit c77661d60d4223bf2ff10d409beb0c3b2021183b ] If there are any pending messages in the mailbox queue, they are sent as soon as a TX done event arrives from the driver. This may trigger a new delivery interrupt while the previous one is still being handled. If the delivery status is cleared after this, the interrupt is lost. To prevent this from happening, clear the delivery status immediately after checking it and before any new messages are sent. Signed-off-by: Otto Pflüger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 22cfa9e10cfa70438b9e0375e2f0b2e99a2b3c6f Author: Tzung-Bi Shih Date: Mon Jan 12 11:07:55 2026 +0000 remoteproc: mediatek: Break lock dependency to `prepare_lock` [ Upstream commit d935187cfb27fc4168f78f3959aef4eafaae76bb ] A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 34035ddfbd77182ab04eccd576344efc18910591 Author: Otto Pflüger Date: Sat Jan 10 16:43:38 2026 +0100 mailbox: sprd: mask interrupts that are not handled [ Upstream commit 75df94d05fc03fd9d861eaf79ce10fbb7a548bd8 ] To reduce the amount of spurious interrupts, disable the interrupts that are not handled in this driver. Signed-off-by: Otto Pflüger Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 9824db3eadb3b18fa199282d8d909de93adf511d Author: Jacky Bai Date: Tue Dec 16 16:00:54 2025 +0800 mailbox: imx: Skip the suspend flag for i.MX7ULP [ Upstream commit 673b570825ace0dcb2ac0c676080559d505c6f40 ] In current imx-mailbox driver, the MU IRQ is configured with 'IRQF_NO_SUSPEND' flag set. So during linux suspend/resume flow, the MU IRQ is always enabled. With commit 892cb524ae8a ("mailbox: imx: fix wakeup failure from freeze mode"), if the MU IRQ is triggered after the priv->suspended flag has been set, the system suspend will be aborted. On i.MX7ULP platform, certain drivers that depend on rpmsg may need to send rpmsg request and receive an acknowledgment from the remote core during the late_suspend stage. Early suspend abort is not expected, and the i.MX7ULP already has additional hardware and software to make sure the system can be wakeup from freeze mode correctly when MU IRQ is trigger. Skip the 'suspend' flag handling logic on i.MX7ULP to avoid the early abort when doing suspend. Signed-off-by: Jacky Bai Reviewed-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit fa3635fa761a6db1f09ecd60cafcd313b611b046 Author: Mark Brown Date: Fri Jan 16 14:07:40 2026 +0000 mailbox: pcc: Remove spurious IRQF_ONESHOT usage [ Upstream commit 673327028cd61db68a1e0c708be2e302c082adf9 ] The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV Signed-off-by: Mark Brown Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit b74e552df8e54ce4da56d64aed93888401d6c32e Author: Iuliana Prodan Date: Thu Dec 4 14:28:23 2025 +0200 remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX channel is uninitialized [ Upstream commit d62e0e92e589c53c4320ed5914af5fe103f5ce7e ] Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251204122825.756106-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 37b7cc18380c6310e1b7fc4873faa6e4efe88975 Author: Colin Lord Date: Mon Feb 9 23:48:10 2026 -0800 tracing: Fix false sharing in hwlat get_sample() [ Upstream commit f743435f988cb0cf1f521035aee857851b25e06d ] The get_sample() function in the hwlat tracer assumes the caller holds hwlat_data.lock, but this is not actually happening. The result is unprotected data access to hwlat_data, and in per-cpu mode can result in false sharing which may show up as false positive latency events. The specific case of false sharing observed was primarily between hwlat_data.sample_width and hwlat_data.count. These are separated by just 8B and are therefore likely to share a cache line. When one thread modifies count, the cache line is in a modified state so when other threads read sample_width in the main latency detection loop, they fetch the modified cache line. On some systems, the fetch itself may be slow enough to count as a latency event, which could set up a self reinforcing cycle of latency events as each event increments count which then causes more latency events, continuing the cycle. The other result of the unprotected data access is that hwlat_data.count can end up with duplicate or missed values, which was observed on some systems in testing. Convert hwlat_data.count to atomic64_t so it can be safely modified without locking, and prevent false sharing by pulling sample_width into a local variable. One system this was tested on was a dual socket server with 32 CPUs on each numa node. With settings of 1us threshold, 1000us width, and 2000us window, this change reduced the number of latency events from 500 per second down to approximately 1 event per minute. Some machines tested did not exhibit measurable latency from the false sharing. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260210074810.6328-1-clord@mykolab.com Signed-off-by: Colin Lord Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f7fc25362c07924939a6c3473e02eee4094f75fd Author: Sergey Matyukevich Date: Sun Jan 25 21:09:56 2026 -0700 riscv: vector: init vector context with proper vlenb [ Upstream commit ef3ff40346db8476a9ef7269fc9d1837e7243c40 ] The vstate in thread_struct is zeroed when the vector context is initialized. That includes read-only register vlenb, which holds the vector register length in bytes. Zeroed state persists until mstatus.VS becomes 'dirty' and a context switch saves the actual hardware values. This can expose the zero vlenb value to the user-space in early debug scenarios, e.g. when ptrace attaches to a traced process early, before any vector instruction except the first one was executed. Fix this by specifying proper vlenb on vector context init. Signed-off-by: Sergey Matyukevich Reviewed-by: Andy Chiu Tested-by: Andy Chiu Link: https://patch.msgid.link/20251214163537.1054292-3-geomatsi@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit d42ec56b30bad4dcc52850813aa337406c6ec91c Author: Keita Morisaki Date: Mon Feb 2 11:45:26 2026 +0900 scsi: ufs: mediatek: Fix page faults in ufs_mtk_clk_scale() trace event [ Upstream commit 9672ed3de7d772ceddd713c769c05e832fc69bae ] The ufs_mtk_clk_scale() trace event currently stores the address of the name string directly via __field(const char *, name). This pointer may become invalid after the module is unloaded, causing page faults when the trace buffer is subsequently accessed. This can occur because the MediaTek UFS driver can be configured as a loadable module (tristate in Kconfig), meaning the name string passed to the trace event may reside in module memory that becomes invalid after module unload. Fix this by using __string() and __assign_str() to copy the string contents into the ring buffer instead of storing the pointer. This ensures the trace data remains valid regardless of module state. This change increases the memory usage for each ftrace entry by a few bytes (clock names are typically 7-15 characters like "ufs_sel" or "ufs_sel_max_src") compared to storing an 8-byte pointer. Note that this change does not affect anything unless all of the following conditions are met: - CONFIG_SCSI_UFS_MEDIATEK is enabled - ftrace tracing is enabled - The ufs_mtk_clk_scale event is enabled in ftrace Signed-off-by: Keita Morisaki Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260202024526.122515-1-keita.morisaki@tier4.jp Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2fcdc1ccc2014953b3d47c058b83c875170bda3a Author: Kommula Shiva Shankar Date: Fri Jan 2 12:27:03 2026 +0530 vhost: fix caching attributes of MMIO regions by setting them explicitly [ Upstream commit 5145b277309f3818e2db507f525d19ac3b910922 ] Explicitly set non-cached caching attributes for MMIO regions. Default write-back mode can cause CPU to cache device memory, causing invalid reads and unpredictable behavior. Invalid read and write issues were observed on ARM64 when mapping the notification area to userspace via mmap. Signed-off-by: Kommula Shiva Shankar Acked-by: Jason Wang Reviewed-by: Jason Gunthorpe Signed-off-by: Michael S. Tsirkin Message-Id: <20260102065703.656255-1-kshankar@marvell.com> Signed-off-by: Sasha Levin commit c45363db0d5f546ac0d11403120df1fae52513b1 Author: Arnd Bergmann Date: Tue Feb 3 17:33:15 2026 +0100 scsi: buslogic: Reduce stack usage [ Upstream commit e17f0d4cc006265dd92129db4bf9da3a2e4a4f66 ] Some randconfig builds run into excessive stack usage with gcc-14 or higher, which use __attribute__((cold)) where earlier versions did not do that: drivers/scsi/BusLogic.c: In function 'blogic_init': drivers/scsi/BusLogic.c:2398:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] The problem is that a lot of code gets inlined into blogic_init() here. Two functions stick out, but they are a bit different: - blogic_init_probeinfo_list() actually uses a few hundred bytes of kernel stack, which is a problem in combination with other functions that also do. Marking this one as noinline means that the stack slots get get reused between function calls - blogic_reportconfig() has a few large variables, but whenever it is not inlined into its caller, the compiler is actually smart enough to reuse stack slots for these automatically, so marking it as noinline saves most of the stack space by itself. The combination of both of these should avoid the problem entirely. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260203163321.2598593-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dbf9416360aa97ac59b8b904c97c67c93e18581f Author: Longfang Liu Date: Thu Jan 22 10:02:03 2026 +0800 hisi_acc_vfio_pci: update status after RAS error [ Upstream commit 8be14dd48dfee0df91e511acceb4beeb2461a083 ] After a RAS error occurs on the accelerator device, the accelerator device will be reset. The live migration state will be abnormal after reset, and the original state needs to be restored during the reset process. Therefore, reset processing needs to be performed in a live migration scenario. Signed-off-by: Longfang Liu Link: https://lore.kernel.org/r/20260122020205.2884497-3-liulongfang@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 9cf87b6bf6fb857df67f15a03ffbd6fa8b7448fa Author: Henry Tseng Date: Mon Dec 1 17:46:22 2025 +0800 ata: libata: avoid long timeouts on hot-unplugged SATA DAS [ Upstream commit 151cabd140322205e27dae5c4bbf261ede0056e3 ] When a SATA DAS enclosure is connected behind a Thunderbolt PCIe switch, hot-unplugging the whole enclosure causes pciehp to tear down the PCI hierarchy before the SCSI layer issues SYNCHRONIZE CACHE and START STOP UNIT for the disks. libata still queues these commands and the AHCI driver tries to access the HBA registers even though the PCI channel is already offline. This results in a series of timeouts and error recovery attempts, e.g.: [ 824.778346] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 891.612720] ata8.00: qc timeout after 5000 msecs (cmd 0xec) [ 902.876501] ata8.00: qc timeout after 10000 msecs (cmd 0xec) [ 934.107998] ata8.00: qc timeout after 30000 msecs (cmd 0xec) [ 936.206431] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 1006.298356] ata1.00: qc timeout after 5000 msecs (cmd 0xec) [ 1017.561926] ata1.00: qc timeout after 10000 msecs (cmd 0xec) [ 1048.791790] ata1.00: qc timeout after 30000 msecs (cmd 0xec) [ 1050.890035] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK With this patch applied, the same hot-unplug looks like: [ 59.965496] pcieport 0000:00:07.0: pciehp: Slot(14): Link Down [ 60.002502] sd 7:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK ... [ 60.103050] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK In this test setup with two disks, the hot-unplug sequence shrinks from about 226 seconds (~3.8 minutes) between the Link Down event and the last SYNCHRONIZE CACHE failure to under a second. Without this patch the total delay grows roughly with the number of disks, because each disk gets its own SYNCHRONIZE CACHE and qc timeout series. If the underlying PCI device is already gone, these commands cannot succeed anyway. Avoid issuing them by introducing ata_adapter_is_online(), which checks pci_channel_offline() for PCI-based hosts. It is used from ata_scsi_find_dev() to return NULL, causing the SCSI layer to fail new commands with DID_BAD_TARGET immediately, and from ata_qc_issue() to bail out before touching the HBA registers. Since such failures would otherwise trigger libata error handling, ata_adapter_is_online() is also consulted from ata_scsi_port_error_handler(). When the adapter is offline, libata skips ap->ops->error_handler(ap) and completes error handling using the existing path, rather than running a full EH sequence against a dead adapter. With this change, SYNCHRONIZE CACHE and START STOP UNIT commands issued during hot-unplug fail quickly once the PCI channel is offline, without qc timeout spam or long libata EH delays. Suggested-by: Damien Le Moal Signed-off-by: Henry Tseng Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 9662e7b1e9153f0003a0b114cfad10d065264b0a Author: Md Haris Iqbal Date: Wed Jan 7 17:15:16 2026 +0100 RDMA/rtrs-clt: For conn rejection use actual err number [ Upstream commit fc290630702b530c2969061e7ef0d869a5b6dc4f ] When the connection establishment request is rejected from the server side, then the actual error number sent back should be used. Signed-off-by: Md Haris Iqbal Link: https://patch.msgid.link/20260107161517.56357-10-haris.iqbal@ionos.com Reviewed-by: Grzegorz Prajsner Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 78ac2b2f981f6cf9048c434a95c8412149462d8a Author: Carl Lee Date: Thu Feb 5 19:11:39 2026 +0800 nfc: nxp-nci: remove interrupt trigger type [ Upstream commit 57be33f85e369ce9f69f61eaa34734e0d3bd47a7 ] For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ed3ab68c1537ac0d19745fcc3d439ecb554aeaa Author: Arnd Bergmann Date: Thu Feb 5 17:28:09 2026 +0100 myri10ge: avoid uninitialized variable use [ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ] While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized] 391 | buf->data0 = htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized] 393 | buf->data2 = htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cbda3855897f9815d82dbe3dc2e08f963a7e5347 Author: Johnny-CC Chang Date: Thu Nov 13 16:44:06 2025 +0800 PCI: Mark Nvidia GB10 to avoid bus reset [ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ] After asserting Secondary Bus Reset to downstream devices via a GB10 Root Port, the link may not retrain correctly, e.g., the link may retrain with a lower lane count or config accesses to downstream devices may fail. Prevent use of Secondary Bus Reset for devices below GB10. Signed-off-by: Johnny-CC Chang [bhelgaas: drop pci_ids.h update (only used once), update commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com Signed-off-by: Sasha Levin commit 7e9a6422820927a1ff6fbce30ab95af4834be6aa Author: Krishna Chaitanya Chundru Date: Fri Jan 9 13:53:32 2026 +0530 PCI: Add ACS quirk for Qualcomm Hamoa & Glymur [ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ] The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. Add an ACS quirk for Hamoa & Glymur. Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109-acs_quirk-v1-1-82adf95a89ae@oss.qualcomm.com Signed-off-by: Sasha Levin commit 7a126c1b6cfa2c4b5a7013164451ecddd210110d Author: Manivannan Sadhasivam Date: Fri Jan 2 21:04:47 2026 +0530 PCI: Enable ACS after configuring IOMMU for OF platforms [ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ] Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets 'pci_acs_enable' to request that ACS be enabled for any devices enumerated in the future. OF platforms called pci_enable_acs() for the first device before of_iommu_configure() called pci_request_acs(), so ACS was never enabled for that device (typically a Root Port). Call pci_enable_acs() later, from pci_dma_configure(), after of_dma_configure() has had a chance to call pci_request_acs(). Here's the call path, showing the move of pci_enable_acs() from pci_acs_init() to pci_dma_configure(), where it always happens after pci_request_acs(): pci_device_add pci_init_capabilities pci_acs_init - pci_enable_acs - if (pci_acs_enable) <-- previous test - ... device_add bus_notify(BUS_NOTIFY_ADD_DEVICE) iommu_bus_notifier iommu_probe_device iommu_init_device dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure of_dma_configure of_iommu_configure pci_request_acs pci_acs_enable = 1 <-- set + pci_enable_acs + if (pci_acs_enable) <-- new test + ... bus_probe_device device_initial_probe ... really_probe dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure ... pci_enable_acs Note that we will now call pci_enable_acs() twice for every device, first from the iommu_probe_device() path and again from the really_probe() path. Presumably that's not an issue since we also call dev->bus->dma_configure() twice. For the ACPI platforms, pci_request_acs() is called during ACPI initialization time itself, independent of the IOMMU framework. Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Tested-by: Naresh Kamboju Link: https://patch.msgid.link/20260102-pci_acs-v3-1-72280b94d288@oss.qualcomm.com Signed-off-by: Sasha Levin commit 63345c47ae43a74c889b4039c45e09886f0f2c56 Author: Keith Busch Date: Fri Jan 30 08:59:51 2026 -0800 PCI: Fix pci_slot_lock () device locking [ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch Signed-off-by: Bjorn Helgaas Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com Signed-off-by: Sasha Levin commit 7ac154e37a91f4fdbe23c4603d71f892d6226abc Author: Lukas Wunner Date: Sun Jan 25 10:25:51 2026 +0100 PCI/AER: Clear stale errors on reporting agents upon probe [ Upstream commit e242d09b58e869f86071b7889acace4cff215935 ] Correctable and Uncorrectable Error Status Registers on reporting agents are cleared upon PCI device enumeration in pci_aer_init() to flush past events. They're cleared again when an error is handled by the AER driver. If an agent reports a new error after pci_aer_init() and before the AER driver has probed on the corresponding Root Port or Root Complex Event Collector, that error is not handled by the AER driver: It clears the Root Error Status Register on probe, but neglects to re-clear the Correctable and Uncorrectable Error Status Registers on reporting agents. The error will eventually be reported when another error occurs. Which is irritating because to an end user it appears as if the earlier error has just happened. Amend the AER driver to clear stale errors on reporting agents upon probe. Skip reporting agents which have not invoked pci_aer_init() yet to avoid using an uninitialized pdev->aer_cap. They're recognizable by the error bits in the Device Control register still being clear. Reporting agents may execute pci_aer_init() after the AER driver has probed, particularly when devices are hotplugged or removed/rescanned via sysfs. For this reason, it continues to be necessary that pci_aer_init() clears Correctable and Uncorrectable Error Status Registers. Reported-by: Lucas Van # off-list Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Lucas Van Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://patch.msgid.link/3011c2ed30c11f858e35e29939add754adea7478.1769332702.git.lukas@wunner.de Signed-off-by: Sasha Levin commit bc8710fd1b92a2ff2b63998507270fca2e237054 Author: Alex Williamson Date: Thu Jan 8 17:02:08 2026 -0700 PCI: Mark ASM1164 SATA controller to avoid bus reset [ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/ Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com Signed-off-by: Sasha Levin commit ba2e3472022f44baddf000621fed150d7a599ea3 Author: Håkon Bugge Date: Mon Feb 2 22:57:20 2026 -0700 net/rds: Clear reconnect pending bit [ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: Håkon Bugge Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260203055723.1085751-6-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ebd51c3f032df8ca765c9bb9608618785577cac Author: Arnd Bergmann Date: Tue Feb 3 17:34:00 2026 +0100 vmw_vsock: bypass false-positive Wnonnull warning with gcc-16 [ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=NULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann Reviewed-by: Bobby Eshleman Reviewed-by: Stefano Garzarella Reviewed-by: Bryan Tan Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73a92ae5a99047632c31f0fd592da79eb8d05144 Author: Ethan Nelson-Moore Date: Mon Feb 2 17:39:09 2026 -0800 net: usb: sr9700: remove code to drive nonexistent multicast filter [ Upstream commit 9a9424c756feee9ee6e717405a9d6fa7bacdef08 ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman (from v1) Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260203013924.28582-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c8847a8eaacbea37c02e6eb036db17d6ff2823de Author: Joe Damato Date: Fri Jan 30 16:30:41 2026 -0800 bnxt_en: Allow ntuple filters for drops [ Upstream commit 61cef6454cfbb9fcdbe41401fb53895f86603081 ] It appears that in commit 7efd79c0e689 ("bnxt_en: Add drop action support for ntuple"), bnxt gained support for ntuple filters for packet drops. However, support for this does not seem to work in recent kernels or against net-next: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 rmgr: Cannot insert RX class rule: Operation not supported Cannot insert classification rule The issue is that the existing code uses ethtool_get_flow_spec_ring_vf, which will return a non-zero value if the ring_cookie is set to RX_CLS_FLOW_DISC, which then causes bnxt_add_ntuple_cls_rule to return -EOPNOTSUPP because it thinks the user is trying to set an ntuple filter for a vf. Fix this by first checking that the ring_cookie is not RX_CLS_FLOW_DISC. After this patch, ntuple filters for drops can be added: % sudo ethtool -U eth0 flow-type udp4 src-ip 1.1.1.1 action -1 Added rule with ID 0 % ethtool -n eth0 44 RX rings available Total 1 rules Filter: 0 Rule Type: UDP over IPv4 Src IP addr: 1.1.1.1 mask: 0.0.0.0 Dest IP addr: 0.0.0.0 mask: 255.255.255.255 TOS: 0x0 mask: 0xff Src port: 0 mask: 0xffff Dest port: 0 mask: 0xffff Action: Drop Reviewed-by: Michael Chan Signed-off-by: Joe Damato Link: https://patch.msgid.link/20260131003042.2570434-1-joe@dama.to Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39c6ab2d2eea568c0d2682f1fe24fa7739d834f8 Author: Ziyi Guo Date: Fri Jan 23 17:56:11 2026 +0000 wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg() [ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwestern.edu [removed excess blank line] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 16ca0282e099b3983cf4987bc23ca3c9373f9a9d Author: Dian-Syuan Yang Date: Tue Jan 27 16:50:35 2026 +0800 wifi: rtw89: pci: restore LDO setting after device resume [ Upstream commit af1e82232b988f8fc6d635c60609765e49221a64 ] The LDO (Low Dropout Regulator) setting is missing after suspend/resume in some platforms, and it will cause card loss. Therefore, reconfigure this setting to avoid it. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260127085036.44060-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 2a4f7827e0014d804cb4b4295b571ae3a558f714 Author: Marek Behún Date: Wed Jan 28 18:00:44 2026 +0100 net: sfp: add quirk for Lantech 8330-265D [ Upstream commit 86a8e8e0ddbc3d14c799536eb888180b84d002f3 ] Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Behún Link: https://patch.msgid.link/20260128170044.15576-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cec2ceb35ce7bc874c43812bb39200d6cf691b87 Author: Geetha sowjanya Date: Tue Jan 27 18:21:47 2026 +0530 octeontx2-af: Workaround SQM/PSE stalls by disabling sticky [ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 416c01dd95f4a82acbf7a1c23364995cae447e3e Author: Jacopo Scannella Date: Tue Jan 20 10:13:04 2026 +0100 Bluetooth: btusb: Add device ID for Realtek RTL8761BU [ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5d0b46ab5d555f15e3f1926207a5cf23a7405aca Author: Shell Chen Date: Wed Jan 14 15:03:35 2026 +1100 Bluetooth: btusb: Add new VID/PID for RTL8852CE [ Upstream commit d9f7c39c6b7548bd70519b241b6c2d1bcc658d4b ] Add VID:PID 13d3:3612 to the quirks_table. This ID pair is found in the Realtek RTL8852CE PCIe module in an ASUS TUF A14 2025 (FA401KM) laptop. Tested on aforementioned laptop. The device info from /sys/kernel/debug/usb/devices is listed as below. T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Shell Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0f5c4d8745d76a9676cac0e92e2f871f4bbe8581 Author: Stefan Sørensen Date: Tue Dec 16 10:20:09 2025 +0100 Bluetooth: hci_conn: use mod_delayed_work for active mode timeout [ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a86ebcb3b08f5e7ee43643bbccfa501170c111ee Author: Stefan Sørensen Date: Tue Dec 16 10:20:10 2025 +0100 Bluetooth: hci_conn: Set link_policy on incoming ACL connections [ Upstream commit 4bb091013ab0f2edfed3f58bebe658a798cbcc4d ] The connection link policy is only set when establishing an outgoing ACL connection causing connection idle modes not to be available on incoming connections. Move the setting of the link policy to the creation of the connection so all ACL connection will use the link policy set on the HCI device. Signed-off-by: Stefan Sørensen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 430bdb44c0b2fa04419233bc3dce4b682d0878f4 Author: Bluecross Date: Wed Dec 10 23:22:25 2025 +0300 Bluetooth: btusb: Add support for MediaTek7920 0489:e158 [ Upstream commit 2630bcc8343a9d2a38dc1793068e6754b3156811 ] Add support for MediaTek7920 0489:e158 /sys/kernel/debug/usb/devices reports for that device: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e158 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Andrew Elatsev Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cdcaafeb40f9e329c163216aa944a2dd64cdfcba Author: Kuniyuki Iwashima Date: Tue Jan 27 04:35:24 2026 +0000 ipv4: fib: Annotate access to struct fib_alias.fa_state. [ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de3974edd057b88991f7c122098168ce365795d9 Author: Ziyi Guo Date: Sun Jan 25 19:30:05 2026 +0000 wifi: iwlegacy: add missing mutex protection in il3945_store_measurement() [ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7d355d937dc320f57b46b701ae3eaebd79729830 Author: Ziyi Guo Date: Sun Jan 25 19:40:39 2026 +0000 wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power() [ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b9074687ffeae3efa440b2cab5866524012477f0 Author: Jijie Shao Date: Fri Jan 23 17:47:55 2026 +0800 net: hns3: extend HCLGE_FD_AD_QID to 11 bits [ Upstream commit 878406d4d6ef85c37fab52074771cc916e532c16 ] Currently, HCLGE_FD_AD_QID has only 10 bits and supports a maximum of 1023 queues. However, there are actually scenarios where the queue_id exceeds 1023. This patch adds an additional bit to HCLGE_FD_AD_QID to ensure that queue_id greater than 1023 are supported. Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 70debb2b34a219d57addaa0b3127682409c870e9 Author: Eric Dumazet Date: Thu Jan 22 17:22:47 2026 +0000 ipv4: igmp: annotate data-races around idev->mr_maxdelay [ Upstream commit e4faaf65a75f650ac4366ddff5dabb826029ca5a ] idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2803d02aa7a18f42db0bbcd42210e0e7ccf060ec Author: Eric Dumazet Date: Thu Jan 22 04:57:17 2026 +0000 gro: change the BUG_ON() in gro_pull_from_frag0() [ Upstream commit cbe41362be2c27e0237a94a404ae413cec9c2ad9 ] Replace the BUG_ON() which never fired with a DEBUG_NET_WARN_ON_ONCE() $ scripts/bloat-o-meter -t vmlinux.1 vmlinux.2 add/remove: 2/2 grow/shrink: 1/1 up/down: 370/-254 (116) Function old new delta gro_try_pull_from_frag0 - 196 +196 napi_gro_frags 771 929 +158 __pfx_gro_try_pull_from_frag0 - 16 +16 __pfx_gro_pull_from_frag0 16 - -16 dev_gro_receive 1514 1464 -50 gro_pull_from_frag0 188 - -188 Total: Before=22565899, After=22566015, chg +0.00% Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260122045720.1221017-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3978714bd4a0b53045106aee7110eac6d8ececa Author: Ojaswin Mujoo Date: Fri Jan 23 11:55:35 2026 +0530 ext4: propagate flags to convert_initialized_extent() [ Upstream commit 3fffa44b6ebf65be92a562a5063303979385a1c9 ] Currently, ext4_zero_range passes EXT4_EX_NOCACHE flag to avoid caching extents however this is not respected by convert_initialized_extent(). Hence, modify it to accept flags from the caller and to pass the flags on to other extent manipulation functions it calls. This makes sure the NOCACHE flag is respected throughout the code path. Also, we no longer explicitly pass CONVERT_UNWRITTEN as the caller takes care of this. Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/07008fbb14db727fddcaf4c30e2346c49f6c8fe0.1769149131.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 81248b1eb3c5954cc1fc7b33b7c03e34d20cb8c8 Author: Gerd Rausch Date: Wed Jan 21 22:52:12 2026 -0700 net/rds: No shortcut out of RDS_CONN_ERROR [ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260122055213.83608-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b0ea9e2a564406d241b99ebb69b2e35ae6774e8b Author: Po-Hao Huang Date: Sat Jan 17 12:41:57 2026 +0800 wifi: rtw89: 8922a: add digital compensation for 2GHz [ Upstream commit 8da7e88682d58a7c2e2c2101e49d3c9c9ac481b0 ] This fixes transmit power too low under 2GHz connection. Previously we missed the settings of 2GHz, add the according calibrated tables. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260117044157.2392958-10-pkshih@realtek.com Signed-off-by: Sasha Levin commit 0a56a63a3bb39336f8109bb29c4d94727bbd223f Author: Po-Hao Huang Date: Wed Jan 14 09:39:50 2026 +0800 wifi: rtw89: fix unable to receive probe responses under MLO connection [ Upstream commit 6f6d7a325fbde4f025ee1b1277f6f44727e21223 ] During MLO connections, A1 of the probe responses we received are in link address, these frames will then be dropped by mac80211 due to not matching the MLD address in ieee80211_scan_accept_presp(). Fix this by using MLD address to scan when not using random MAC address. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260114013950.19704-13-pkshih@realtek.com Signed-off-by: Sasha Levin commit a8347aa567494e6b3380d5b7bd787250edb618d7 Author: Miri Korenblit Date: Mon Nov 10 15:02:15 2025 +0200 wifi: iwlwifi: mvm: check the validity of noa_len [ Upstream commit 1e3fb3c4a8e6c581d0f4533dba887fabf53d607d ] Validate iwl_probe_resp_data_notif::noa_attr::len_low since we are using its value to determine the noa_len, which is later used for the NoA attribute. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251110150012.99b663d9b424.I206fd54c990ca9e1160b9b94fa8be44e67bcc1b9@changeid Signed-off-by: Sasha Levin commit 4cca2bb737174f8e9d464bf5c6ad3f951234bcd6 Author: Mingj Ye Date: Tue Jan 20 09:59:49 2026 +0800 net: usb: r8152: fix transmit queue timeout [ Upstream commit 833dcd75d54f0bf5aa0a0781ff57456b421fbb40 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260120015949.84996-1-insyelu@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6cb281662a6320862550195e25ffca3e070c4576 Author: Brian Masney Date: Tue Jan 20 12:07:23 2026 -0500 openrisc: define arch-specific version of nop() [ Upstream commit 0dfffa5479d6260d04d021f69203b1926f73d889 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601180236.BVy480We-lkp@intel.com/ Signed-off-by: Brian Masney Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 8b300f726640c48c3edfe9c453334dd801f4b74e Author: Florian Westphal Date: Mon Jan 19 12:30:42 2026 +0100 netfilter: xt_tcpmss: check remaining length before reading optlen [ Upstream commit 735ee8582da3d239eb0c7a53adca61b79fb228b3 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit fb0af2fcee1749e18b881b2266dd95c8c83008d7 Author: Yuto Hamaguchi Date: Fri Dec 19 20:53:51 2025 +0900 netfilter: nf_conntrack: Add allow_clash to generic protocol handler [ Upstream commit 8a49fc8d8a3e83dc51ec05bcd4007bdea3c56eec ] The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=true in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic. Signed-off-by: Yuto Hamaguchi Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c51755090c94977a95ff1744f6cbe9e859207c02 Author: Zhang Yi Date: Mon Jan 5 09:45:16 2026 +0800 ext4: use reserved metadata blocks when splitting extent on endio [ Upstream commit 01942af95ab6c9d98e64ae01fdc243a03e4b973f ] When performing buffered writes, we may need to split and convert an unwritten extent into a written one during the end I/O process. However, we do not reserve space specifically for these metadata changes, we only reserve 2% of space or 4096 blocks. To address this, we use EXT4_GET_BLOCKS_PRE_IO to potentially split extents in advance and EXT4_GET_BLOCKS_METADATA_NOFAIL to utilize reserved space if necessary. These two approaches can reduce the likelihood of running out of space and losing data. However, these methods are merely best efforts, we could still run out of space, and there is not much difference between converting an extent during the writeback process and the end I/O process, it won't increase the risk of losing data if we postpone the conversion. Therefore, also use EXT4_GET_BLOCKS_METADATA_NOFAIL in ext4_convert_unwritten_extents_endio() to prepare for the buffered I/O iomap conversion, which may perform extent conversion during the end I/O process. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260105014522.1937690-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 5b5a9abdc5f4878b84d1291c5c4620cfe5efe7b5 Author: Li Chen Date: Thu Dec 11 19:51:42 2025 +0800 ext4: mark group extend fast-commit ineligible [ Upstream commit 1f8dd813a1c771b13c303f73d876164bc9b327cc ] Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-6-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 9e9fb259bcddf459a0168f4a964e979e500a68a5 Author: Baokun Li Date: Tue Dec 9 21:31:16 2025 +0800 ext4: move ext4_percpu_param_init() before ext4_mb_init() [ Upstream commit 270564513489d98b721a1e4a10017978d5213bff ] When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: ================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used. Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20251209133116.731350-1-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 102428f145f92559960dd407c1b124bdf2a77516 Author: Li Chen Date: Thu Dec 11 19:51:41 2025 +0800 ext4: mark group add fast-commit ineligible [ Upstream commit 89b4336fd5ec78f51f9d3a1d100f3ffa3228e604 ] Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=/dev/zero of=/root/fc_resize.img bs=1M count=0 seek=256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /mnt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen Link: https://patch.msgid.link/20251211115146.897420-5-me@linux.beauty Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit bd463fcd7f0cd7679948c89d6cbe0b7e00597083 Author: Eric Dumazet Date: Thu Jan 15 09:41:40 2026 +0000 ipv6: exthdrs: annotate data-race over multiple sysctl [ Upstream commit 978b67d28358b0b4eacfa94453d1ad4e09b123ad ] Following four sysctls can change under us, add missing READ_ONCE(). - ipv6.sysctl.max_dst_opts_len - ipv6.sysctl.max_dst_opts_cnt - ipv6.sysctl.max_hbh_opts_len - ipv6.sysctl.max_hbh_opts_cnt Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 762e76c93823de4af224c7051f858882558ac34b Author: Eric Dumazet Date: Thu Jan 15 09:41:38 2026 +0000 ipv6: annotate data-races over sysctl.flowlabel_reflect [ Upstream commit 5ade47c974b46eb2a1279185962a0ffa15dc5450 ] Add missing READ_ONCE() when reading ipv6.sysctl.flowlabel_reflect, as its value can be changed under us. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45e2b1cf268991f065b271458ddae38a97d6c535 Author: Eric Dumazet Date: Thu Jan 15 09:41:37 2026 +0000 ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}() [ Upstream commit 03e9d91dd64e2f5ea632df5d59568d91757efc4d ] Add missing READ_ONCE() when reading sysctl values. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260115094141.3124990-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 69b4bcaece65ee6518135d9bc842cf8f36cb6cbd Author: Miri Korenblit Date: Wed Jan 7 13:51:57 2026 +0200 wifi: cfg80211: allow only one NAN interface, also in multi radio [ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ] According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can have one NAN management interface. This applies also to multi radio devices. The current code allows a driver to support more than one NAN interface, if those are not in the same radio. Fix it. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e2ee86fefe0185bd68a4a46765f8501fc880e30e Author: Baochen Qiang Date: Mon Jan 12 15:36:24 2026 +0800 wifi: ath12k: fix preferred hardware mode calculation [ Upstream commit 7f852de0003219c431a6f2ffd951fd82a4673660 ] For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 4234f2d90f7b6f9fd84aba44b5bf67a6eb64aea9 Author: Qian Zhang Date: Thu Jan 8 11:46:07 2026 +0800 wifi: ath11k: Fix failure to connect to a 6 GHz AP [ Upstream commit 0bc8c48de6f06c0cac52dde024ffda4433de6234 ] STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260108034607.812885-1-qian.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b71487cb692ef0580e3d077c52812529fbf12a8d Author: Ross Vandegrift Date: Sat Jan 3 17:00:34 2026 -0800 wifi: ath11k: add pm quirk for Thinkpad Z13/Z16 Gen1 [ Upstream commit 4015b1972763d7d513172276e51439f37e622a92 ] Z16 Gen1 has the wakeup-from-suspend issues from [1] but was never added to the appropriate quirk list. I've tested this patch on top of 6.18.2, it fixes the issue for me on 21D4 Mark Pearson provided the other product IDs covering the second Z16 Gen1 and both Z13 Gen1 identifiers. They share the same firmware, and folks in the bugzilla report do indeed see the problem on Z13. [1] - https://bugzilla.kernel.org/show_bug.cgi?id=219196 Signed-off-by: Ross Vandegrift Reviewed-by: Baochen Qiang Tested-by: Mark Pearson Reviewed-by: Mark Pearson Link: https://patch.msgid.link/wj7o2kmb7g54stdjvxp2hjqrnutnq3jbf4s2uh4ctvmlxdq7tf@nbkj2ebakhrd Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 26c82ec5add2139e9c043d505bb413d8925426ca Author: Chin-Yen Lee Date: Sat Jan 10 10:20:13 2026 +0800 wifi: rtw89: wow: add reason codes for disassociation in WoWLAN mode [ Upstream commit 2fd8f953f25173d14981d8736b6f5bfcd757e51b ] Some APs disconnect clients by sending a Disassociation frame rather than a Deauthentication frame. Since these frames use different reason codes in WoWLAN mode, this commit adds support for handling Disassociation to prevent missed disconnection events. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit faac634c2795cb4e2170e329680e7a6f766110ff Author: Ping-Ke Shih Date: Sat Jan 10 10:20:17 2026 +0800 wifi: rtw89: mac: correct page number for CSI response [ Upstream commit aa2a44d0d22d45d659b9f01638809b1735e46cff ] For beamforming procedure, hardware reserve memory page for CSI response. The unit of register is (value - 1), so add one accordingly as expected. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260110022019.2254969-7-pkshih@realtek.com Signed-off-by: Sasha Levin commit 715c263119fd1b918a9fcbd8a36ea5b604a46324 Author: Ankit Soni Date: Mon Dec 1 14:39:40 2025 +0000 iommu/amd: move wait_on_sem() out of spinlock [ Upstream commit d2a0cac10597068567d336e85fa3cbdbe8ca62bf ] With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled. Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled. Signed-off-by: Ankit Soni Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b82073564373e68c6ae3a96039fae14cd002a496 Author: Szymon Wilczek Date: Sun Dec 21 16:58:06 2025 +0100 wifi: libertas: fix WARNING in usb_tx_block [ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek Link: https://patch.msgid.link/20251221155806.23925-1-swilczek.lx@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 939dc5eddae660d1993191af16e8fc26ee366358 Author: Slark Xiao Date: Mon Jan 5 10:26:46 2026 +0800 net: wwan: mhi: Add network support for Foxconn T99W760 [ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ] T99W760 is designed based on Qualcomm SDX35 chip. It use similar architecture with SDX72/SDX75 chip. So we need to assign initial link id for this device to make sure network available. Signed-off-by: Slark Xiao Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65bc40fea4fd6f5f07db550f4fdf4dee7f42116f Author: Alexander Grest Date: Mon Dec 8 13:28:57 2025 -0800 iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency [ Upstream commit df180b1a4cc51011c5f8c52c7ec02ad2e42962de ] The SMMU CMDQ lock is highly contentious when there are multiple CPUs issuing commands and the queue is nearly full. The lock has the following states: - 0: Unlocked - >0: Shared lock held with count - INT_MIN+N: Exclusive lock held, where N is the # of shared waiters - INT_MIN: Exclusive lock held, no shared waiters When multiple CPUs are polling for space in the queue, they attempt to grab the exclusive lock to update the cons pointer from the hardware. If they fail to get the lock, they will spin until either the cons pointer is updated by another CPU. The current code allows the possibility of shared lock starvation if there is a constant stream of CPUs trying to grab the exclusive lock. This leads to severe latency issues and soft lockups. Consider the following scenario where CPU1's attempt to acquire the shared lock is starved by CPU2 and CPU0 contending for the exclusive lock. CPU0 (exclusive) | CPU1 (shared) | CPU2 (exclusive) | `cmdq->lock` -------------------------------------------------------------------------- trylock() //takes | | | 0 | shared_lock() | | INT_MIN | fetch_inc() | | INT_MIN | no return | | INT_MIN + 1 | spins // VAL >= 0 | | INT_MIN + 1 unlock() | spins... | | INT_MIN + 1 set_release(0) | spins... | | 0 see[NOTE] (done) | (sees 0) | trylock() // takes | 0 | *exits loop* | cmpxchg(0, INT_MIN) | 0 | | *cuts in* | INT_MIN | cmpxchg(0, 1) | | INT_MIN | fails // != 0 | | INT_MIN | spins // VAL >= 0 | | INT_MIN | *starved* | | INT_MIN [NOTE] The current code resets the exclusive lock to 0 regardless of the state of the lock. This causes two problems: 1. It opens the possibility of back-to-back exclusive locks and the downstream effect of starving shared lock. 2. The count of shared lock waiters are lost. To mitigate this, we release the exclusive lock by only clearing the sign bit while retaining the shared lock waiter count as a way to avoid starving the shared lock waiters. Also deleted cmpxchg loop while trying to acquire the shared lock as it is not needed. The waiters can see the positive lock count and proceed immediately after the exclusive lock is released. Exclusive lock is not starved in that submitters will try exclusive lock first when new spaces become available. Reviewed-by: Mostafa Saleh Reviewed-by: Nicolin Chen Signed-off-by: Alexander Grest Signed-off-by: Jacob Pan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit cf2d06c9fd4b6521ea5b7f73c99c64c2c6f5e224 Author: Ding Hui Date: Sat Dec 20 20:03:50 2025 +0800 dm: remove fake timeout to avoid leak request [ Upstream commit f3a9c95a15d2f4466acad5c68faeff79ca5e9f47 ] Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui Reviewed-by: Christoph Hellwig Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 209149bd758e4dad135160bc15d129604a44c2a9 Author: Daniel Gomez Date: Sat Dec 20 04:49:37 2025 +0100 dm: replace -EEXIST with -EBUSY [ Upstream commit b13ef361d47f09b7aecd18e0383ecc83ff61057e ] The -EEXIST error code is reserved by the module loading infrastructure to indicate that a module is already loaded. When a module's init function returns -EEXIST, userspace tools like kmod interpret this as "module already loaded" and treat the operation as successful, returning 0 to the user even though the module initialization actually failed. This follows the precedent set by commit 54416fd76770 ("netfilter: conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same issue in nf_conntrack_helper_register(). Affected modules: * dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache * dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity * dm_queue_length dm_service_time dm_snapshot Signed-off-by: Daniel Gomez Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit b4d46b4fb2409591619f8df5ef9fa77699f30121 Author: Bitterblue Smith Date: Wed Dec 24 01:26:45 2025 +0200 wifi: rtw88: Fix inadvertent sharing of struct ieee80211_supported_band data [ Upstream commit fcac0f23d4d20b11014a39f8e2527cdc12ec9c82 ] Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw88 driven devices in the system, channel information may get incoherent, preventing channel use. Copied from commit 0ae36391c804 ("wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band data"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/e94ad653-2b6d-4284-a33c-8c694f88955b@gmail.com Signed-off-by: Sasha Levin commit 9b5418070ee8468fac9e8bf641c83d46b85bff30 Author: Bitterblue Smith Date: Wed Dec 24 01:25:32 2025 +0200 wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() [ Upstream commit 2ba12401cc1f2d970fa2e7d5b15abde3f5abd40d ] Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*"). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/1aa7fdef-2d5b-4a31-a4e9-fac8257ed30d@gmail.com Signed-off-by: Sasha Levin commit 46216a48cd89d5b38fa3c1872ab10a07c369a350 Author: Zong-Zhe Yang Date: Tue Dec 23 11:06:44 2025 +0800 wifi: rtw89: ser: enable error IMR after recovering from L1 [ Upstream commit f4de946bdb379f543e3a599f8f048d741ad4a58e ] After recovering from L1, explicitly enable error IMR to ensure next L1 SER (system error recovery) can work normally. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251223030651.480633-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit e31daf5fbcda9d6bfbf97c1ef64e25719f90fdad Author: Jose Ignacio Tornos Martinez Date: Wed Nov 26 10:18:56 2025 +0100 wifi: rtw89: 8922a: set random mac if efuse contains zeroes [ Upstream commit 41be33d3efc120f6a2c02d12742655f2aa09e1b6 ] I have some rtl8922ae devices with no permanent mac stored in efuse. It could be properly saved and/or configured from user tools like NetworkManager, but it would be desirable to be able to initialize it somehow to get the device working by default. So, in the same way as with other devices, if the mac address read from efuse contains zeros, a random mac address is assigned to at least allow operation, and the user is warned about this in case any action needs to be considered. Signed-off-by: Jose Ignacio Tornos Martinez Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251126091905.217951-1-jtornosm@redhat.com Signed-off-by: Sasha Levin commit 1c7ad1b82ec43672b7c2df79da2aa095dd5d0dab Author: Hsiu-Ming Chang Date: Fri Dec 5 08:32:04 2025 +0800 wifi: rtw88: rtw8821cu: Add ID for Mercusys MU6H [ Upstream commit 77653c327e11c71c5363b18a53fbf2b92ed21da4 ] Add support for Mercusys MU6H AC650 High Gain Wireless Dual Band USB Adapter V1.30. It is based on RTL8811CU, usb device ID is 2c4e:0105. Signed-off-by: Hsiu-Ming Chang Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251205003245.5762-1-cges30901@gmail.com Signed-off-by: Sasha Levin commit 0d0c2fb80ca4c284c397dd7546743a3b5fdf4020 Author: Bitterblue Smith Date: Sun Nov 30 16:50:31 2025 +0200 wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode() [ Upstream commit 44d1f624bbdd2d60319374ba85f7195a28d00c90 ] rtw8822b_set_antenna() can be called from userspace when the chip is powered off. In that case a WARNING is triggered in rtw8822b_config_trx_mode() because trying to read the RF registers when the chip is powered off returns an unexpected value. Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when the chip is powered on. ------------[ cut here ]------------ write RF mode table fail WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1 Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021 RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b] Call Trace: rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- Link: https://github.com/lwfinger/rtw88/issues/366 Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/fb9a3444-9319-4aa2-8719-35a6308bf568@gmail.com Signed-off-by: Sasha Levin commit 400ca64e87accfac6152bfb2c181480d10461a56 Author: Roman Peshkichev Date: Tue Nov 25 23:09:37 2025 +0500 wifi: rtw88: fix DTIM period handling when conf->dtim_period is zero [ Upstream commit 9f68fdcdc9dbf21be2a48feced90ff7f77d07443 ] The function rtw_set_dtim_period() accepted an 'int' dtim_period parameter, while mac80211 provides dtim_period as 'u8' in struct ieee80211_bss_conf. In IBSS (ad-hoc) mode mac80211 may set dtim_period to 0. The driver unconditionally wrote (dtim_period - 1) to REG_DTIM_COUNTER_ROOT, which resulted in 0xFF when dtim_period was 0. This caused delays in broadcast/multicast traffic processing and issues with ad-hoc operation. Convert the function parameter to u8 to match ieee80211_bss_conf and avoid the underflow by writing 0 when dtim_period is 0. Link: https://github.com/lwfinger/rtw88/issues/406 Signed-off-by: Roman Peshkichev Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251125180937.22977-1-roman.peshkichev@gmail.com Signed-off-by: Sasha Levin commit 5d77c36cd4b698649f5c30c5f6c084f4f61d1880 Author: Jori Koolstra Date: Tue Oct 28 13:22:12 2025 +0100 jfs: nlink overflow in jfs_rename [ Upstream commit 9218dc26fd922b09858ecd3666ed57dfd8098da8 ] If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions. Signed-off-by: Jori Koolstra Reported-by: syzbot+9131ddfd7870623b719f@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=9131ddfd7870623b719f Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit aeecd32724c597594d138506e2a1512686cfa915 Author: Haotian Zhang Date: Mon Dec 1 19:38:01 2025 +0800 jfs: Add missing set_freezable() for freezable kthread [ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ] The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(), causing it to remain non-freezable by default. This prevents proper freezing during system suspend. Add set_freezable() to make the thread freezable as intended. Signed-off-by: Haotian Zhang Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit de10c10eb0e8f4eccd91e2a775bba455189b07fb Author: Lianqin Hu Date: Mon Feb 9 08:38:29 2026 +0000 ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio [ Upstream commit ac656d7d7c70f7c352c7652bc2bb0c1c8c2dde08 ] Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: New USB device found, idVendor=001f, idProduct=0b21 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210926172016 Signed-off-by: Lianqin Hu Link: https://patch.msgid.link/TYUPR06MB6217522D0DB6E2C9DF46B56ED265A@TYUPR06MB6217.apcprd06.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ae583f113d15fa97e5234133c20d09f8e6214e47 Author: Takashi Iwai Date: Mon Feb 9 13:12:11 2026 +0100 ALSA: mixer: oss: Add card disconnect checkpoints [ Upstream commit 084d5d44418148662365eced3e126ad1a81ee3e2 ] ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device. For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly. Link: https://patch.msgid.link/20260209121212.171430-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 72210c1ad2d43d12474d2a57b7cbc4a2fa28c8ff Author: Illia Barbashyn <04baril@gmail.com> Date: Sat Feb 7 23:19:37 2026 +0100 ALSA: hda/realtek - Enable mute LEDs on HP ENVY x360 15-es0xxx [ Upstream commit ac1ff574bbc09a6c90f4fe8f9e6b8d66c983064c ] The mute and mic-mute LEDs on HP ENVY x360 Convertible 15-es0xxx (PCI SSID 103c:88b3) do not work with the current driver. This model requires a combination of COEFBIT and GPIO fixups to correctly control the LEDs. Introduce a new fixup function alc245_fixup_hp_envy_x360_mute_led and add a quirk to apply it. Signed-off-by: Illia Barbashyn <04baril@gmail.com> Link: https://patch.msgid.link/20260207221955.24132-1-04baril@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bfefacf1996f00fd2d60d99a89e5a73ae7cc9037 Author: Ziyi Guo Date: Thu Feb 5 05:24:29 2026 +0000 ASoC: fsl: imx-rpmsg: use snd_soc_find_dai_with_mutex() in probe [ Upstream commit 84faa91585fa22a161763f2fe8f84a602a196c87 ] imx_rpmsg_probe() calls snd_soc_find_dai() without holding client_mutex. However, snd_soc_find_dai() has lockdep_assert_held(&client_mutex) indicating callers must hold this lock, as the function iterates over the global component list. All other callers of snd_soc_find_dai() either hold client_mutex via the snd_soc_bind_card() path or use the snd_soc_find_dai_with_mutex() wrapper. Use snd_soc_find_dai_with_mutex() instead to fix the missing lock protection. Signed-off-by: Ziyi Guo Reviewed-by: Frank Li Link: https://patch.msgid.link/20260205052429.4046903-1-n7l8m4@u.northwestern.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 21207c003700f226bbe38fb9fe5dd5d640e51f31 Author: Praveen Talari Date: Wed Feb 4 21:58:52 2026 +0530 spi: geni-qcom: Fix abort sequence execution for serial engine errors [ Upstream commit 96e041647bb0f9d92f95df1d69cb7442d7408b79 ] The driver currently skips the abort sequence for target mode when serial engine errors occur. This leads to improper error recovery as the serial engine may remain in an undefined state without proper cleanup, potentially causing subsequent operations to fail or behave unpredictably. Fix this by ensuring the abort sequence and DMA reset always execute during error recovery, as both are required for proper serial engine error handling. Co-developed-by: Konrad Dybcio Signed-off-by: Konrad Dybcio Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260204162854.1206323-3-praveen.talari@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 10411f1f2c76be67103b1f95822ff629aa25e2aa Author: Ranjani Sridharan Date: Wed Feb 4 10:18:32 2026 +0200 ASoC: SOF: Intel: hda: Fix NULL pointer dereference [ Upstream commit 16c589567a956d46a7c1363af3f64de3d420af20 ] If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken. RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] Signed-off-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Mateusz Redzynia Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260204081833.16630-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 566657cafa5d70a3c5ece4c4e9098847d4751648 Author: Ziyi Guo Date: Fri Jan 30 18:26:51 2026 +0000 power: sequencing: fix missing state_lock in pwrseq_power_on() error path [ Upstream commit e1dccb485c2876ac1318f36ccc0155416c633a48 ] pwrseq_power_on() calls pwrseq_unit_disable() when the post_enable callback fails. However, this call is outside the scoped_guard(mutex, &pwrseq->state_lock) block that ends. pwrseq_unit_disable() has lockdep_assert_held(&pwrseq->state_lock), which will fail when called from this error path. Add the scoped_guard block to cover the post_enable callback and its error handling to ensure the lock is held when pwrseq_unit_disable() is called. Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260130182651.1576579-1-n7l8m4@u.northwestern.edu Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 648a26c3bda4a5fcf66a34551738bea722ff0176 Author: René Rebe Date: Sun Nov 23 13:13:30 2025 +0100 modpost: Amend ppc64 save/restfpr symnames for -Os build [ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 31a37c62e6a5a59823ad348ff2d1c411875662fb Author: Hsieh Hung-En Date: Sat Jan 31 00:00:17 2026 +0800 ASoC: es8328: Add error unwind in resume [ Upstream commit 8232e6079ae6f8d3a61d87973cb427385aa469b9 ] Handle failures in the resume path by unwinding previously enabled resources. If enabling regulators or syncing the regcache fails, disable regulators and unprepare the clock to avoid leaking resources and leaving the device in a partially resumed state. Signed-off-by: Hsieh Hung-En Link: https://patch.msgid.link/20260130160017.2630-6-hungen3108@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c46992fa770a6951c7bc1532b5312093680652cc Author: Bastien Nocera Date: Sun Jan 25 13:12:02 2026 +0100 HID: logitech-hidpp: Add support for Logitech K980 [ Upstream commit af4fe07a9d963a72438ade96cf090e84b3399d0c ] Add support for the solar-charging Logitech K980 keyboard, over Bluetooth. Bolt traffic doesn't get routed through logitech-dj, so this code isn't triggered when Bolt is used. Signed-off-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2ec472ad5c19f1375e6efbb6a9f55ea9ceb8eaf2 Author: Ji-Ze Hong (Peter Hong) Date: Tue Dec 23 13:10:40 2025 +0800 hwmon: (f71882fg) Add F81968 support [ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ] Add hardware monitoring support for the Fintek F81968 Super I/O chip. It is fully compatible with F81866. Several products share compatibility with the F81866. To better distinguish between them, ensure that the Product ID is displayed when the device is probed. Signed-off-by: Ji-Ze Hong (Peter Hong) Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.com.tw Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 066bbecaef26107d15130feb849d41ce29c55fec Author: Denis Pauk Date: Wed Dec 31 17:53:14 2025 +0200 hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SE [ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ] Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. Add the board to the WMI monitoring list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Tested-by: Marcus Link: https://lore.kernel.org/r/20251231155316.2048-1-pauk.denis@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2c7a5235a8c8289d406f42f0261c48910f94e5c2 Author: Armin Wolf Date: Sun Jan 4 01:06:10 2026 +0100 hwmon: (dell-smm) Add support for Dell OptiPlex 7080 [ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ] The Dell OptiPlex 7080 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/16 Signed-off-by: Armin Wolf Acked-by: Pali Rohár Link: https://lore.kernel.org/r/20260104000654.6406-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ba5d922b315333dd578cefbeeda4aaad3738de5b Author: Chen Ni Date: Fri Jan 30 17:19:04 2026 +0800 ASoC: codecs: max98390: Check return value of devm_gpiod_get_optional() in max98390_i2c_probe() [ Upstream commit a1d14d8364eac2611fe1391c73ff0e5b26064f0e ] The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260130091904.3426149-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5a22d4560c35acfa9194ad9d41918df446777bab Author: Zhongwei Date: Tue Jan 13 15:51:42 2026 +0800 drm/amd/display: avoid dig reg access timeout on usb4 link training fail [ Upstream commit 15b1d7b77e9836ff4184093163174a1ef28bbdd7 ] [Why] When usb4 link training fails, the dpia sym clock will be disabled and SYMCLK source should be changed back to phy clock. In enable_streams, it is assumed that link training succeeded and will switch from refclk to phy clock. But phy clk here might not be on. Dig reg access timeout will occur. [How] When enable_stream is hit, check if link training failed for usb4. If it did, fall back to the ref clock to avoid reg access timeout. Reviewed-by: Wenjing Liu Signed-off-by: Zhongwei Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b21402b557227d973482640f9602b075eb3b9f25 Author: Matthew Stewart Date: Fri Jan 9 13:32:42 2026 -0500 drm/amd/display: Fix GFX12 family constant checks [ Upstream commit bdad08670278829771626ea7b57c4db531e2544f ] Using >=, <= for checking the family is not always correct. Reviewed-by: Aurabindo Pillai Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f1c5fcf80d771bd5635227fb58ebac85e0571265 Author: Chin-Ting Kuo Date: Tue Jan 20 20:30:04 2026 +0800 spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end [ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ] spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo Reviewed-by: Paul Menzel Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6d802e37525bdc4e86655b7954788e4f2de5edc3 Author: Chen Ni Date: Tue Jan 27 11:32:50 2026 +0800 ASoC: sunxi: sun50i-dmic: Add missing check for devm_regmap_init_mmio [ Upstream commit 74823db9ba2e13f3ec007b354759b3d8125e462c ] Add check for the return value of devm_regmap_init_mmio() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a85a0ebd33c988f676ff46b1c86ab39d5ccff5c Author: Billy Tsai Date: Fri Jan 23 17:26:26 2026 +0800 gpio: aspeed-sgpio: Change the macro to support deferred probe [ Upstream commit e18533b023ec7a33488bcf33140ce69bbba2894f ] Use module_platform_driver() to replace module_platform_driver_probe(). The former utilizes platform_driver_register(), which allows the driver to defer probing when it doesn't acquire the necessary resources due to probe order. In contrast, the latter uses __platform_driver_probe(), which includes the comment "Note that this is incompatible with deferred probing." Since our SGPIO driver requires access to the clock resource, the former is more suitable. Reviewed-by: Linus Walleij Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@aspeedtech.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit adae2d63f81d133d4acf7d9ccccf4bf183315a5a Author: Damien Dagorn Date: Fri Jan 23 18:14:52 2026 +0100 ALSA: hda/realtek: fix LG Gram Style 14 speakers [ Upstream commit cc051fbd7f40226cc407558bc97c5099513e8657 ] The LG Gram Style 14 (14Z90RS-G.AD77F, SSID 1854:0490) with Realtek ALC298 shows normal routing and volume changes, but internal speakers stay silent unless a userland HDA-verb workaround is applied. Add a dedicated quirk for the LG Gram Style 14 that programs the codec coefficient sequence used by the known workaround and enables the speaker amps only during playback. Tested-by: Damien Dagorn Signed-off-by: Damien Dagorn Link: https://lore.kernel.org/CAN59QMUhd4kHrkRoJA6VzEr2VKezN2yjHnANaQoZn2-Bnwe3bQ@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6e1664116a9609a8d14637558a2de5a256dda0b3 Author: gongqi <550230171hxy@gmail.com> Date: Thu Jan 22 23:55:01 2026 +0800 ALSA: hda/conexant: Add headset mic fix for MECHREVO Wujie 15X Pro [ Upstream commit f2581ea2d9f30844c437e348a462027ea25c12e9 ] The headset microphone on the MECHREVO Wujie 15X Pro requires the CXT_FIXUP_HEADSET_MIC quirk to function properly. Add the PCI SSID (0x1d05:0x3012) to the quirk table. Signed-off-by: gongqi <550230171hxy@gmail.com> Link: https://patch.msgid.link/20260122155501.376199-5-550230171hxy@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f5623483341b64aad68910c8750ee02c244193e9 Author: David Phillips Date: Fri Jan 23 12:56:09 2026 +0900 HID: elecom: Add support for ELECOM HUGE Plus M-HT1MRBK [ Upstream commit b8e5fdf0bd022cd5493a5987ef66f5a24f8352d8 ] New model in the ELECOM HUGE trackball line that has 8 buttons but the report descriptor specifies only 5. The HUGE Plus supports connecting via Bluetooth, 2.4GHz wireless USB dongle, and directly via a USB-C cable. Each connection type reports a different device id, 01AA for cable, 01AB for USB dongle, and 01AC for Bluetooth. This patch adds these device IDs and applies the fixups similar to the other ELECOM devices to get all 8 buttons working for all 3 connection types. For reference, the usbhid-dump output: 001:013:001:DESCRIPTOR 1769085639.598405 05 01 09 02 A1 01 85 01 09 01 A1 00 05 09 19 01 29 05 15 00 25 01 75 01 95 05 81 02 75 03 95 01 81 01 05 01 09 30 09 31 16 01 80 26 FF 7F 75 10 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 81 25 7F 75 08 95 01 81 06 C0 C0 05 0C 09 01 A1 01 85 02 15 01 26 8C 02 19 01 2A 8C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 09 82 09 81 09 83 15 00 25 01 19 01 29 03 75 01 95 03 81 02 95 05 81 01 C0 06 01 FF 09 00 A1 01 85 08 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Signed-off-by: David Phillips Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0fa0a82274c8471f9168b4ac338580981da86078 Author: Thorsten Schmelzer Date: Fri Jan 23 09:57:05 2026 +0100 HID: multitouch: add eGalaxTouch EXC3188 support [ Upstream commit 8e4ac86b2ddd36fe501e20ecfcc080e536df1f48 ] Add support for the for the EXC3188 touchscreen from eGalaxy. Signed-off-by: Thorsten Schmelzer Signed-off-by: Michael Tretter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0f5fe6ae25f996a34ce0bd2edec2723bbb131fc0 Author: Rui Wang Date: Mon Jan 5 12:11:42 2026 -0500 media: rkisp1: Fix filter mode register configuration [ Upstream commit 5a50f2b61104d0d351b59ec179f67abab7870453 ] The rkisp1_flt_config() function performs an initial direct write to RKISP1_CIF_ISP_FILT_MODE without including the RKISP1_CIF_ISP_FLT_ENA bit, which clears the filter enable bit in the hardware. The subsequent read/modify/write sequence then reads back the register with the enable bit already cleared and cannot restore it, resulting in the filter being inadvertently disabled. Remove the redundant direct write. The read/modify/write sequence alone correctly preserves the existing enable bit state while updating the DNR mode and filter configuration bits. Signed-off-by: Rui Wang Reviewed-by: Stefan Klug Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260105171142.147792-2-rui.wang@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a205740a7231e967ac77cb731171642901c327af Author: Ludovic Desroches Date: Fri Oct 24 18:14:53 2025 +0200 drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release [ Upstream commit bc847787233277a337788568e90a6ee1557595eb ] The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit cc18db0860c81bed3ad5dc87284de0f127fef82f Author: Ludovic Desroches Date: Thu Nov 20 11:38:25 2025 +0100 drm/atmel-hlcdc: don't reject the commit if the src rect has fractional parts [ Upstream commit 06682206e2a1883354ed758c09efeb51f435adbd ] Don’t reject the commit when the source rectangle has fractional parts. This can occur due to scaling: drm_atomic_helper_check_plane_state() calls drm_rect_clip_scaled(), which may introduce fractional parts while computing the clipped source rectangle. This does not imply the commit is invalid, so we should accept it instead of discarding it. Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251120-lcd_scaling_fix-v1-1-5ffc98557923@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit 25e832a7830740e72103eb0b527680a4b64bbcb3 Author: Ludovic Desroches Date: Fri Oct 24 18:14:52 2025 +0200 drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback [ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ] After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Signed-off-by: Ludovic Desroches Reviewed-by: Manikandan Muralidharan Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan Signed-off-by: Sasha Levin commit fe3cf809c1e53bf6f4ae745d26f9e8728a08c391 Author: Ovidiu Bunea Date: Fri Jan 2 17:48:59 2026 -0500 drm/amd/display: Disable FEC when powering down encoders [ Upstream commit 8cee62904caf95e5698fa0f2d420f5f22b4dea15 ] [why & how] VBIOS DMCUB FW can enable FEC for capable eDPs, but S/W DC state is only updated for link0 when transitioning into OS with driver loaded. This causes issues when the eDP is immediately hidden and DIG0 is assigned to another link that does not support FEC. Driver will attempt to disable FEC but FEC enablement occurs based on the link state, which does not have fec_state updated since it is a different link. Thus, FEC disablement on DIG0 will get skipped and cause no light up. Reviewed-by: Karen Chen Signed-off-by: Ovidiu Bunea Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c3b6733dd4c94abd28a64c3e48f038198a2fca5e Author: Peter Ujfalusi Date: Tue Jan 20 21:35:04 2026 +0200 PCI: Add Intel Nova Lake audio Device ID [ Upstream commit b190870e0e0cfb375c0d4da02761c32083f3644d ] Add Nova Lake (NVL) audio Device ID The ID will be used by HDA legacy, SOF audio stack and the driver to determine which audio stack should be used (intel-dsp-config). Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Acked-by: Bjorn Helgaas Acked-by: Takashi Iwai Link: https://patch.msgid.link/20260120193507.14019-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 02a4d03515d42e02a86655f4602e9b26ec6ead00 Author: Bard Liao Date: Mon Jan 19 17:17:48 2026 +0800 ASoC: soc-acpi-intel-arl-match: change rt722 amp endpoint to aggregated [ Upstream commit 08c09899960118ffb01417242e659eb6cc067d6a ] rt722 is aggregated with rt1320 amp in arl_rt722_l0_rt1320_l2 and it is the only audio configuration in the ARL platform. Set .aggregated = 1 to represent the fact and avoid unexpected issue. Signed-off-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260119091749.1752088-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ae57ffd142faf89ba4bf153292040136e579db52 Author: Thomas Weißschuh Date: Thu Jan 15 08:35:45 2026 +0100 virt: vbox: uapi: Mark inner unions in packed structs as packed [ Upstream commit c25d01e1c4f2d43f47af87c00e223f5ca7c71792 ] The unpacked unions within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/vbox_vmmdev_types.h:239:4: error: field u within 'struct vmmdev_hgcm_function_parameter32' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:223:2)' and is usually due to 'struct vmmdev_hgcm_function_parameter32' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 239 | } u; | ^ ./usr/include/linux/vbox_vmmdev_types.h:254:6: error: field u within 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:251:4)' and is usually due to 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] With the recent changes to compile-test the UAPI headers in more cases, these warning in combination with CONFIG_WERROR breaks the build. Fix the warnings. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-2-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 359d29e76dba831c782cd731884a0c6ce6e7420b Author: Thomas Weißschuh Date: Thu Jan 15 08:35:44 2026 +0100 hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packed [ Upstream commit 1e5271393d777f6159d896943b4c44c4f3ecff52 ] The unpacked union within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/hyperv.h:361:2: error: field within 'struct hv_kvp_exchg_msg_value' is less aligned than 'union hv_kvp_exchg_msg_value::(anonymous at ./usr/include/linux/hyperv.h:361:2)' and is usually due to 'struct hv_kvp_exchg_msg_value' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 361 | union { | ^ With the recent changes to compile-test the UAPI headers in more cases, this warning in combination with CONFIG_WERROR breaks the build. Fix the warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Acked-by: Wei Liu (Microsoft) Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-1-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 8e1664b9ee43608eb973d357ae5d858d30cbc9ca Author: Xiao Kan <814091656@qq.com> Date: Wed Jan 14 08:22:26 2026 -0500 drm: Account property blob allocations to memcg [ Upstream commit 26b4309a3ab82a0697751cde52eb336c29c19035 ] DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <814091656@qq.com> Signed-off-by: Xiao Kan Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05@qq.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit cc904b44e4e6278143150ef5c6608dbb16d5009c Author: Donet Tom Date: Mon Jan 12 19:36:56 2026 +0530 drm/amdkfd: Fix GART PTE for non-4K pagesize in svm_migrate_gart_map() [ Upstream commit 6c160001661b6c4e20f5c31909c722741e14c2d8 ] In svm_migrate_gart_map(), while migrating GART mapping, the number of bytes copied for the GART table only accounts for CPU pages. On non-4K systems, each CPU page can contain multiple GPU pages, and the GART requires one 8-byte PTE per GPU page. As a result, an incorrect size was passed to the DMA, causing only a partial update of the GART table. Fix this function to work correctly on non-4K page-size systems by accounting for the number of GPU pages per CPU page when calculating the number of bytes to be copied. Acked-by: Christian König Reviewed-by: Philip Yang Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ee0dc6c66a913260311876a4b2b53fe0b9bc3f94 Author: Donet Tom Date: Mon Jan 12 19:36:54 2026 +0530 drm/amdkfd: Relax size checking during queue buffer get [ Upstream commit 42ea9cf2f16b7131cb7302acb3dac510968f8bdc ] HW-supported EOP buffer sizes are 4K and 32K. On systems that do not use 4K pages, the minimum buffer object (BO) allocation size is PAGE_SIZE (for example, 64K). During queue buffer acquisition, the driver currently checks the allocated BO size against the supported EOP buffer size. Since the allocated BO is larger than the expected size, this check fails, preventing queue creation. Relax the strict size validation and allow PAGE_SIZE-sized BOs to be used. Only the required 4K region of the buffer will be used as the EOP buffer and avoids queue creation failures on non-4K page systems. Acked-by: Christian König Suggested-by: Philip Yang Signed-off-by: Donet Tom Signed-off-by: Felix Kuehling Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a2dfdb19f856881b2424c8627d7bf29e46697982 Author: Bharat Dev Burman Date: Tue Jan 13 00:12:40 2026 +0530 ALSA: hda/realtek: add HP Victus 16-e0xxx mute LED quirk [ Upstream commit 72919c57a055f6d7b79d66731dc398e9b433f47c ] HP Victus 16-e0xxx with ALC245 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x88eb using a new ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT fixup, enabling correct mute LED behavior. Signed-off-by: Bharat Dev Burman Link: https://patch.msgid.link/20260112184253.33376-1-bharat.singh7924@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2d9b17a177c0a50c313374b80005cfe7c1db74de Author: Sakari Ailus Date: Wed Jan 7 23:55:31 2026 +0200 media: ipu6: Always close firmware stream [ Upstream commit 2b08b7007e55bd1793a58478d3ecea4fd95849a5 ] Close the firmware stream even when disabling a stream on an upstream sub-device fails. This allows the firmware to release resources related to a stream that is stopped in any case. Suggested-by: Bingbu Cao Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1ff2c616944c765a6ad814af53d7a9f963507b67 Author: Sakari Ailus Date: Thu Dec 18 00:05:38 2025 +0200 media: ipu6: Close firmware streams on streaming enable failure [ Upstream commit 5925a92cc70d10c7d3124923c36da09b9c1a6eeb ] When enabling streaming fails, the stream is stopped in firmware but not closed. Do this to release resources on firmware side. Signed-off-by: Sakari Ailus Reviewed-by: Bingbu Cao Tested-by: Mehdi Djait # Dell XPS 9315 Reviewed-by: Mehdi Djait Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a4257bf492211b499f30255ec0ba9f4a0da1efae Author: Sakari Ailus Date: Thu Nov 27 14:14:22 2025 +0200 media: ipu6: Ensure stream_mutex is acquired when dealing with node list [ Upstream commit 779bdaad2abf718fb8116839e818e58852874b4d ] The ipu6 isys driver maintains the list of video buffer queues related to a stream (in ipu6 context streams on the same CSI-2 virtual channel) and this list is modified through VIDIOC_STREAMON and VIDIOC_STREAMOFF IOCTLs. Ensure the common mutex is acquired when accessing the linked list, i.e. the isys device context's stream_mutex. Add a lockdep assert to ipu6_isys_get_buffer_list() and switch to guard() while at it as the error handling becomes more simple this way. Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 888523a37c93a8702510a23c5ed7b0e03a56ab3f Author: Hans de Goede Date: Tue Dec 30 18:03:10 2025 +0100 media: mt9m114: Return -EPROBE_DEFER if no endpoint is found [ Upstream commit 437e1f6a960035166495a5117aacbc596115eeb6 ] With IPU# bridges, endpoints may only be created when the IPU bridge is initialized. This may happen after the sensor driver's first probe(). Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 22ffbc504a7379b93fea90adcd10592fdc0ee99d Author: Hans de Goede Date: Tue Dec 30 18:03:03 2025 +0100 media: mt9m114: Avoid a reset low spike during probe() [ Upstream commit 84359d0a5e3afce5e3e3b6562efadff690614d5b ] mt9m114_probe() requests the reset GPIO in output low state: sensor->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); and then almost immediately afterwards calls mt9m114_power_on() which does: gpiod_set_value(sensor->reset, 1); fsleep(duration); gpiod_set_value(sensor->reset, 0); which means that if the reset pin was high before this code runs that it will very briefly be driven low because of passing GPIOD_OUT_LOW when requesting the GPIO only to be driven high again possibly directly after that. Such a very brief driving low of the reset pin may put the chip in a confused state. Request the GPIO in high (reset the chip) state instead to avoid this, turning the initial gpiod_set_value() in mt9m114_power_on() into a no-op. and the fsleep() ensures that it will stay high long enough to properly reset the chip. Reviewed-by: Laurent Pinchart Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 461733d83e67ba7e3a5b750c0d203f738e01244f Author: Sakari Ailus Date: Fri Nov 21 13:48:40 2025 +0200 media: v4l2-async: Fix error handling on steps after finding a match [ Upstream commit 7345d6d356336c448d6b9230ed8704f39679fd12 ] Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches. Fix these specific issues: - If v4l2_async_match_notify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2_async_match_notify(). - The async connection's sd field was only set after creating ancillary links in v4l2_async_match_notify(). It was however dereferenced in v4l2_async_unbind_subdev_one(), which was called on error path of v4l2_async_match_notify() failure. Signed-off-by: Sakari Ailus Tested-by: "Yew, Chang Ching" Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e220ec4c4596d634685b8a08d79ad876a720b466 Author: Haoxiang Li Date: Sat Jan 3 15:46:47 2026 +0800 media: cx25821: Fix a resource leak in cx25821_dev_setup() [ Upstream commit 68cd8ac994cac38a305200f638b30e13c690753b ] Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources(). Signed-off-by: Haoxiang Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5849ae68d7b8b6ad55cc1bf0d227dd2ae6362528 Author: Kees Cook Date: Thu Dec 11 19:00:35 2025 -0800 media: solo6x10: Check for out of bounds chip_id [ Upstream commit 0fdf6323c35a134f206dcad5babb4ff488552076 ] Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. Link: https://github.com/ClangBuiltLinux/linux/issues/2144 [1] Suggested-by: Nathan Chancellor Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil [hverkuil: fix checkpatch warning for is_tw286x] Signed-off-by: Sasha Levin commit 58dd722b6c3debcddb4684fb256c90fee7f063e5 Author: Szymon Wilczek Date: Sat Dec 20 19:24:19 2025 +0100 media: pvrusb2: fix URB leak in pvr2_send_request_ex [ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ] When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails. Reported-by: syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=405dcd13121ff75a9e16 Signed-off-by: Szymon Wilczek Acked-by: Mike Isely Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a854c58dc9895898a80fa46cea7e7e9d3bce9447 Author: Thorsten Schmelzer Date: Tue Nov 25 15:29:57 2025 +0100 media: adv7180: fix frame interval in progressive mode [ Upstream commit 90289b67c5c1d4c18784059b27460d292e16d208 ] The ADV7280-M may internally convert interlaced video input to progressive video. If this mode is enabled, the ADV7280-M delivers progressive video frames at the field rate of 50 fields per second (PAL) or 60 fields per second (NTSC). Fix the reported frame interval if progressive video is enabled. Signed-off-by: Thorsten Schmelzer Reviewed-by: Niklas Söderlund Signed-off-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ec2f37bbb733cdd7ed7d04171fca728a532414d5 Author: Tuo Li Date: Thu Dec 18 20:09:55 2025 +0800 drm/panel: Fix a possible null-pointer dereference in jdi_panel_dsi_remove() [ Upstream commit 95eed73b871111123a8b1d31cb1fce7e902e49ea ] In jdi_panel_dsi_remove(), jdi is explicitly checked, indicating that it may be NULL: if (!jdi) mipi_dsi_detach(dsi); However, when jdi is NULL, the function does not return and continues by calling jdi_panel_disable(): err = jdi_panel_disable(&jdi->base); Inside jdi_panel_disable(), jdi is dereferenced unconditionally, which can lead to a NULL-pointer dereference: struct jdi_panel *jdi = to_panel_jdi(panel); backlight_disable(jdi->backlight); To prevent such a potential NULL-pointer dereference, return early from jdi_panel_dsi_remove() when jdi is NULL. Signed-off-by: Tuo Li Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251218120955.11185-1-islituo@gmail.com Signed-off-by: Sasha Levin commit 533bd1c1e2ca0feed8fba9bd135f7d4b1b7b5fe3 Author: Ming Qian Date: Wed Dec 17 11:02:22 2025 +0800 media: amphion: Clear last_buffer_dequeued flag for DEC_CMD_START [ Upstream commit d85f3207d75df6d7a08be6526b15ff398668206c ] The V4L2_DEC_CMD_START command may be used to handle the dynamic source change, which will triggers an implicit decoder drain. The last_buffer_dequeued flag is set in the implicit decoder drain, so driver need to clear it to continue the following decoding flow. Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit aaced618189a5cf27f05b9449d64ccaeb1580f4d Author: Miquel Raynal Date: Fri Jan 9 18:18:01 2026 +0100 spi: spi-mem: Limit octal DTR constraints to octal DTR situations [ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ] In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is considered requiring a duplicated command opcode. This is wrong as this constraint only applies to octal DTR operations (8D-8D-8D). Narrow the application of this constraint to the concerned bus interface. Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2, 4} would benefit from this check either as there is only in octal DTR mode that a single clock edge would be enough to transmit the full opcode. Make sure the constraint of expecting two bytes for the command is applied to the relevant bus interface. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-3-1fff6a2ddb80@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bbc8396394f276ab1c08952460c74a2e81e1c32e Author: Sebastian Krzyszkowiak Date: Mon Jan 5 04:02:10 2026 +0100 ASoC: wm8962: Don't report a microphone if it's shorted to ground on plug [ Upstream commit e590752119029d87ce46d725e11245a52d22e1fe ] This usually means that a TRS plug with no microphone pin has been plugged into a TRRS socket. Cases where a user is plugging in a microphone while pressing a button will be handled via incoming interrupt after the user releases the button, so the microphone will still be detected once it becomes usable. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-3-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 64d7ff20fb03ce9e35a623cd884e1ecb0595c37f Author: Sebastian Krzyszkowiak Date: Mon Jan 5 04:02:08 2026 +0100 ASoC: wm8962: Add WM8962_ADC_MONOMIX to "3D Coefficients" mask [ Upstream commit 66c26346ae30c883eef70acf9cf9054dfdb4fb2f ] This bit is handled by a separate control. Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-1-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5b27fcb5d1ebfba69a09c80946901a716b673a9b Author: Matthew Brost Date: Fri Jan 9 17:27:35 2026 -0800 drm/xe: Only toggle scheduling in TDR if GuC is running [ Upstream commit dd1ef5e2456558876244795bb22a4d90cb24f160 ] If the firmware is not running during TDR (e.g., when the driver is unloading), there's no need to toggle scheduling in the GuC. In such cases, skip this step. v4: - Bail on wait UC not running (Niranjana) Signed-off-by: Matthew Brost Reviewed-by: Niranjana Vishwanathapura Link: https://patch.msgid.link/20260110012739.2888434-4-matthew.brost@intel.com Signed-off-by: Sasha Levin commit 2193fe76d360ac467f7f69f37c97c252c1be5fa2 Author: Dmytro Laktyushkin Date: Tue Dec 16 16:38:50 2025 -0500 drm/amd/display: only power down dig on phy endpoints [ Upstream commit 0839d8d24e6f1fc2587c4a976f44da9fa69ae3d0 ] This avoids any issues with dpia endpoints Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Matthew Stewart Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ef9ed9e786dd40ca056c3e1ab5a40b95de433b35 Author: YuBiao Wang Date: Wed Nov 12 15:16:27 2025 +0800 drm/amdgpu: Skip loading SDMA_RS64 in VF [ Upstream commit 39c21b81112321cbe1267b02c77ecd2161ce19aa ] VFs use the PF SDMA ucode and are unable to load SDMA_RS64. Signed-off-by: YuBiao Wang Signed-off-by: Victor Skvortsov Reviewed-by: Gavin Wan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a951d6630b3a9b007dbfcf689d42b7796fb2c895 Author: Joey Bednar Date: Wed Nov 12 06:06:23 2025 +0000 HID: apple: Add "SONiX KN85 Keyboard" to the list of non-apple keyboards [ Upstream commit 7273acfd0aef106093a8ffa3b4973eb70e5a3799 ] The SoNiX KN85 keyboard identifies as the "Apple, Inc. Aluminium Keyboard" and is not recognized as a non-apple keyboard. Adding "SoNiX KN85 Keyboard" to the list of non-apple keyboards fixes the function keys. Signed-off-by: Joey Bednar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 23e7150afc70da615857f9f07b494ec58540f096 Author: Dmytro Laktyushkin Date: Wed Dec 10 15:52:39 2025 -0500 drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src [ Upstream commit c979d8db7b0f293111f2e83795ea353c8ed75de9 ] Trying to access link enc on a dpia link will cause a crash otherwise Reviewed-by: Charlene Liu Signed-off-by: Dmytro Laktyushkin Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d89aef80790f488d5123179326fa9ee8d5be67bc Author: Alex Deucher Date: Fri Dec 12 11:46:48 2025 -0500 drm/amdgpu: avoid a warning in timedout job handler [ Upstream commit c8cf9ddc549fb93cb5a35f3fe23487b1e6707e74 ] Only set an error on the fence if the fence is not signalled. We can end up with a warning if the per queue reset path signals the fence and sets an error as part of the reset, but fails to recover. Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 11718976c53a258c4d107aa05d68773379d0006f Author: Charlene Liu Date: Wed Dec 10 17:01:17 2025 -0500 drm/amd/display: Fix dsc eDP issue [ Upstream commit 878a4b73c11111ff5f820730f59a7f8c6fd59374 ] [why] Need to add function hook check before use Reviewed-by: Mohit Bawa Signed-off-by: Charlene Liu Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit eba3bc49971d6323b496b0a9d310024dc077475d Author: Tim Huang Date: Thu Dec 12 10:46:47 2024 +0800 drm/amdgpu: add support for HDP IP version 6.1.1 [ Upstream commit e2fd14f579b841f54a9b7162fef15234d8c0627a ] This initializes HDP IP version 6.1.1. Reviewed-by: Mario Limonciello Signed-off-by: Tim Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4394a810dd66f245da5fb6c033f30d48b46f3b8c Author: Nicolas Dufresne Date: Fri Nov 28 14:16:16 2025 -0500 media: mediatek: vcodec: Don't try to decode 422/444 VP9 [ Upstream commit 3e92d7e4935084ecdbdc88880cc4688618ae1557 ] This is not supported by the hardware and trying to decode these leads to LAT timeout errors. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1ba3a56f4854fab439e5bfe694062f9024a324ea Author: Brandon Brnich Date: Tue Oct 21 15:46:18 2025 -0500 media: chips-media: wave5: Process ready frames when CMD_STOP sent to Encoder [ Upstream commit 5da0380de41439ed64ed9a5218850db38544e315 ] CMD_STOP being sent to encoder before last job is executed by device_run can lead to an occasional dropped frame. Ensure that remaining ready buffers are drained by making a call to v4l2_m2m_try_schedule. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2ed2feef3d2a36264388c3e8122da2af9f75d62f Author: Brandon Brnich Date: Tue Oct 21 15:46:17 2025 -0500 media: chips-media: wave5: Fix conditional in start_streaming [ Upstream commit b4e26c6fc1b3c225caf80d4a95c6f9fcbe959e17 ] When STREAMON(CAP) is called after STREAMON(OUT), the driver was failing to switch states from VPU_INST_STATE_OPEN to VPU_INST_STATE_INIT_SEQ and VPU_INST_STATE_PIC_RUN because the capture queue streaming boolean had not yet been set to true. This led to a hang in the encoder since the state was stuck in VPU_INST_STATE_OPEN. During the second call to start_streaming, the sequence initialization and frame buffer allocation should occur. Signed-off-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 39a624a65c77265a88a0b344f7273dc9600a1be1 Author: Hans Verkuil Date: Wed Apr 30 09:21:53 2025 +0200 media: omap3isp: set initial format [ Upstream commit 7575b8dfa91f82fcb34ffd5568ff415ac4685794 ] Initialize the v4l2_format to a default. Empty formats are not allowed in V4L2, so this fixes v4l2-compliance issues: fail: v4l2-test-formats.cpp(514): !pix.width || !pix.height test VIDIOC_G_FMT: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit b78de03a56ced35a82642a80dadfd5b2bf1a0be4 Author: Hans Verkuil Date: Tue Oct 7 17:09:18 2025 +0200 media: omap3isp: isppreview: always clamp in preview_try_format() [ Upstream commit 17e1e1641f74a89824d4de3aa38c78daa5686cc1 ] If prev->input != PREVIEW_INPUT_MEMORY the width and height weren't clamped. Just always clamp. This fixes a v4l2-compliance error: fail: v4l2-test-subdevs.cpp(171): fse.max_width == ~0U || fse.max_height == ~0U fail: v4l2-test-subdevs.cpp(270): ret && ret != ENOTTY test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit 89772f640b0b40669026c1ebabe0cca45fd11f2f Author: Hans Verkuil Date: Fri Oct 17 15:26:40 2025 +0200 media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixes [ Upstream commit 44c03802a5191626996ee9db4bac090b164ca340 ] The isp_video_mbus_to_pix/pix_to_mbus functions did not take the last empty entry { 0, } of the formats array into account. As a result, isp_video_mbus_to_pix would accept code 0 and isp_video_pix_to_mbus would select code 0 if no match was found. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Sasha Levin commit cf510785f74e74c54de40a43a955b7f844857487 Author: Xiaolei Wang Date: Wed Dec 3 21:03:23 2025 +0800 drm/v3d: Set DMA segment size to avoid debug warnings [ Upstream commit 9eb018828b1b30dfba689c060735c50fc5b9f704 ] When using V3D rendering with CONFIG_DMA_API_DEBUG enabled, the kernel occasionally reports a segment size mismatch. This is because 'max_seg_size' is not set. The kernel defaults to 64K. setting 'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()' from complaining about the over-mapping of the V3D segment length. DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536] WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388 CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1 Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_dma_map_sg+0x330/0x388 lr : debug_dma_map_sg+0x330/0x388 sp : ffff8000829a3ac0 x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000 x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000 x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002 x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffff x17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573 x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000 x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7c x8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001 x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280 Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8 Signed-off-by: Xiaolei Wang Link: https://patch.msgid.link/20251203130323.2247072-1-xiaolei.wang@windriver.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 86ba653114bafd6acc28ca35e6d03b1696b423ed Author: Deepak Kumar Date: Thu Dec 18 11:48:28 2025 +0100 spi: stm32: fix Overrun issue at < 8bpw [ Upstream commit 1ac3be217c01d5df55ec5052f81e4f1708f46552 ] When SPI communication is suspended by hardware automatically, it could happen that few bits of next frame are already clocked out due to internal synchronization delay. To achieve a safe suspension, we need to ensure that each word must be at least 8 SPI clock cycles long. That's why, if bpw is less than 8 bits, we need to use midi to reach 8 SPI clock cycles at least. This will ensure that each word achieve safe suspension and prevent overrun condition. Signed-off-by: Deepak Kumar Signed-off-by: Alain Volmat Link: https://patch.msgid.link/20251218-stm32-spi-enhancements-v2-2-3b69901ca9fe@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a57f1024b9d793e321e97d9f117b6ebf51f47201 Author: Hans Verkuil Date: Thu Jun 5 08:57:35 2025 +0200 media: dvb-core: dmxdevfilter must always flush bufs [ Upstream commit c4e620eccbef76aa5564ebb295e23d6540e27215 ] Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1aa3db5864d9934c65948eb8efa8436178ef51b4 Author: Peter Ujfalusi Date: Wed Dec 17 16:39:43 2025 +0200 ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET [ Upstream commit d96cb0b86d6e8bbbbfa425771606f6c1aebc318e ] There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca36d953d7bb3e1a4833f68e7e8c452661321082 Author: LinCheng Ku Date: Wed Dec 3 10:18:16 2025 +0800 drm/amd/display: Add USB-C DP Alt Mode lane limitation in DCN32 [ Upstream commit cea573a8e1ed83840a2173d153dd68e172849d44 ] [Why] USB-C DisplayPort Alt Mode with concurrent USB data needs lane count limitation to prevent incorrect 4-lane DP configuration when only 2 lanes are available due to hardware lane sharing between DP and USB3. [How] Query DMUB for Alt Mode status (is_dp_alt_disable, is_usb, is_dp4) in dcn32_link_encoder_get_max_link_cap() and cap DP to 2 lanes when USB is active on USB-C port. Added inline documentation explaining the USB-C lane sharing constraint. Reviewed-by: PeiChen Huang Signed-off-by: LinCheng Ku Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 46e108c702278ef7490c2dde38c3b41e549a0bb3 Author: Jonathan Marek Date: Thu Nov 20 16:12:00 2025 -0500 spi-geni-qcom: use xfer->bits_per_word for can_dma() [ Upstream commit fb2bbe3838728f572485706677590e4fc41eec5c ] mas->cur_bits_per_word may not reflect the value of xfer->bits_per_word when can_dma() is called. Use the right value instead. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-3-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e15d7f3597debca23f015829af4f6a72bf5ec67d Author: Jonathan Marek Date: Thu Nov 20 16:12:01 2025 -0500 spi-geni-qcom: initialize mode related registers to 0 [ Upstream commit 739062a9f1e9a77a9687c8fd30f8e5dd12ec70be ] setup_fifo_params assumes these will be zero, it won't write these registers if the initial mode is zero. Signed-off-by: Jonathan Marek Link: https://patch.msgid.link/20251120211204.24078-4-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3a26d1d0a3713f33516f7fca9e2180d8af02a2f Author: Philip Yang Date: Wed Nov 19 16:32:45 2025 -0500 drm/amdkfd: Handle GPU reset and drain retry fault race [ Upstream commit 5b57c3c3f22336e8fd5edb7f0fef3c7823f8eac1 ] Only check and drain IH1 ring if CAM is not enabled. If GPU is under reset, don't access IH to drain retry fault. Signed-off-by: Philip Yang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 29fd416e0e08aa6d5a97fd313749d08d83de0826 Author: Likun Gao Date: Fri Jul 12 11:07:40 2024 +0800 drm/amdgpu: fix NULL pointer issue buffer funcs [ Upstream commit 9877a865d62c9c3e0f4cc369dc9ca9f7f24f5ee9 ] If SDMA block not enabled, buffer_funcs will not initialize, fix the null pointer issue if buffer_funcs not initialized. Signed-off-by: Likun Gao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0c11e9f7cf949c8ec112f6f348263babff57ed5c Author: Alexey Klimov Date: Wed Dec 3 07:45:55 2025 +0000 gpu/panel-edp: add AUO panel entry for B140HAN06.4 [ Upstream commit 2976aeb0de77da599ad37691963efbdcb07435ce ] Add an eDP panel entry for AUO B140HAN06.4 that is also used in some variants of Lenovo Flex 5G with Qcom SC8180 SoC. The raw edid of the panel is: 00 ff ff ff ff ff ff 00 06 af 3d 64 00 00 00 00 2b 1d 01 04 a5 1f 11 78 03 b8 1a a6 54 4a 9b 26 0e 52 55 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 14 37 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 10 2c 80 b8 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 42 31 34 30 48 41 4e 30 36 2e 34 20 0a 00 eb I do not have access to the datasheet and but it is tested on above mentioned laptop for a few weeks and seems to work just fine with timing info of similar panels. Cc: Bjorn Andersson Cc: Vinod Koul Signed-off-by: Alexey Klimov Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20251203074555.690613-1-alexey.klimov@linaro.org Signed-off-by: Sasha Levin commit 3f44cdb5371faf225af37d5caba8f21ec0572469 Author: Suraj Kandpal Date: Wed Nov 19 15:16:50 2025 +0530 drm/display/dp_mst: Add protection against 0 vcpi [ Upstream commit 342ccffd9f77fc29fe1c05fd145e4d842bd2feaa ] When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayed_destroy_work ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0. Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc [drm_display_helper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work [drm_display_helper] <4> [515.287303] Call Trace: <4> [515.287304] <4> [515.287306] dump_stack_lvl+0xc1/0xf0 <4> [515.287313] dump_stack+0x10/0x20 <4> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0 <4> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0 <4> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper] <4> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe] <4> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0 <4> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60 <4> [515.287562] intel_atomic_check+0x119/0x2b80 [xe] <4> [515.287740] ? find_held_lock+0x31/0x90 <4> [515.287747] ? lock_release+0xce/0x2a0 <4> [515.287754] drm_atomic_check_only+0x6a2/0xb40 <4> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140 <4> [515.287765] drm_atomic_commit+0x6e/0xf0 <4> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10 <4> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0 <4> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0 <4> [515.287795] ? mutex_lock_nested+0x1b/0x30 <4> [515.287801] drm_client_modeset_commit+0x26/0x50 <4> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110 <4> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140 <4> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0 <4> [515.287819] drm_client_hotplug+0x6c/0xf0 <4> [515.287824] drm_client_dev_hotplug+0x9e/0xd0 <4> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30 <4> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410 [drm_display_helper] <4> [515.287861] process_one_work+0x22b/0x6f0 <4> [515.287874] worker_thread+0x1e8/0x3d0 <4> [515.287879] ? __pfx_worker_thread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? __pfx_kthread+0x10/0x10 <4> [515.287890] ret_from_fork+0x2d7/0x310 <4> [515.287894] ? __pfx_kthread+0x10/0x10 <4> [515.287897] ret_from_fork_asm+0x1a/0x30 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6303 Signed-off-by: Suraj Kandpal Reviewed-by: Imre Deak Reviewed-by: Lyude Paul Link: https://patch.msgid.link/20251119094650.799135-1-suraj.kandpal@intel.com Signed-off-by: Sasha Levin commit 47af25d855b71fbcddee4eadb848201ffe5f7fbf Author: Helge Deller Date: Tue Jan 27 17:58:55 2026 +0100 parisc: Prevent interrupts during reboot [ Upstream commit 35ac5a728c878594f2ea6c43b57652a16be3c968 ] Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 589b7b0fc87e52cd6295543b140ded2c3b37818b Author: Diogo Ivo Date: Thu Dec 4 21:27:21 2025 +0000 arm64: tegra: smaug: Add usb-role-switch support [ Upstream commit dfa93788dd8b2f9c59adf45ecf592082b1847b7b ] The USB2 port on Smaug is configured for OTG operation but lacked the required 'usb-role-switch' property, leading to a failed probe and a non-functioning USB port. Add the property along with setting the default role to host. Signed-off-by: Diogo Ivo Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit eece81eeda10eb42c687399fb5aa69977ae15664 Author: Tomas Melin Date: Tue Nov 25 09:53:54 2025 +0200 Revert "arm64: zynqmp: Add an OP-TEE node to the device tree" [ Upstream commit c197179990124f991fca220d97fac56779a02c6d ] This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fcaf6@vaisala.com Signed-off-by: Sasha Levin commit 3dcd45cfda1b8a72b12587299bf096b86b9d75bb Author: Haoxiang Li Date: Wed Dec 10 11:16:56 2025 +0800 firmware: arm_ffa: Unmap Rx/Tx buffers on init failure [ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8d849adfbc3e98417fb541620568db1a759ef441 Author: Ruipeng Qi Date: Tue Feb 3 10:03:58 2026 +0800 pstore: ram_core: fix incorrect success return when vmap() fails [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit d53d092019f86b881719a435c4ce2274cc884617 Author: Joel Fernandes Date: Mon Jan 26 10:59:00 2026 +0100 sched/debug: Fix updating of ppos on server write ops [ Upstream commit 6080fb211672aec6ce8f2f5a2e0b4eae736f2027 ] Updating "ppos" on error conditions does not make much sense. The pattern is to return the error code directly without modifying the position, or modify the position on success and return the number of bytes written. Since on success, the return value of apply is 0, there is no point in modifying ppos either. Fix it by removing all this and just returning error code or number of bytes written on success. Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Andrea Righi Acked-by: Tejun Heo Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-3-arighi@nvidia.com Signed-off-by: Sasha Levin commit c821922bb7683235cb5688871d032a90e5be96e7 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:29 2026 +0100 char: tpm: cr50: Remove IRQF_ONESHOT [ Upstream commit 1affd29ffbd50125a5492c6be1dbb1f04be18d4f ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Jarkko Sakkinen Link: https://patch.msgid.link/20260128095540.863589-10-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 117fe6b91c51fbaf4650098727164e051fb2710d Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:24 2026 +0100 mailbox: bcm-ferxrm-mailbox: Use default primary handler [ Upstream commit 03843d95a4a4e0ba22ad4fcda65ccf21822b104c ] request_threaded_irq() is invoked with a primary and a secondary handler and no flags are passed. The primary handler is the same as irq_default_primary_handler() so there is no need to have an identical copy. The lack of the IRQF_ONESHOT flag can be dangerous because the interrupt source is not masked while the threaded handler is active. This means, especially on LEVEL typed interrupt lines, the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-5-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit a321dd2b6356d0a61975342d9ad83b86eab86c66 Author: Chenghai Huang Date: Sat Jan 17 18:18:03 2026 +0800 crypto: hisilicon/qm - move the barrier before writing to the mailbox register [ Upstream commit ebf35d8f9368816c930f5d70783a72716fab5e19 ] Before sending the data via the mailbox to the hardware, to ensure that the data accessed by the hardware is the most up-to-date, a write barrier should be added before writing to the mailbox register. The current memory barrier is placed after writing to the register, the barrier order should be modified to be before writing to the register. Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 76f7abd4ee0188f06465bdd3c053fdc5e8595152 Author: Haoxiang Li Date: Sun Jan 25 22:44:52 2026 +0800 PCI/MSI: Unmap MSI-X region on error [ Upstream commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202 ] msix_capability_init() fails to unmap the MSI-X region if msix_setup_interrupts() fails. Add the missing iounmap() for that error path. [ tglx: Massaged change log ] Signed-off-by: Haoxiang Li Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260125144452.2103812-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Sasha Levin commit bd1be0d58b61ba4bf25fb3d8a820993ccfb1b2d6 Author: Bartosz Golaszewski Date: Fri Jan 16 12:17:23 2026 +0100 clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency on OF [ Upstream commit 2246464821e2820572e6feefca2029f17629cc50 ] This driver accesses the of_aliases global variable declared in linux/of.h and defined in drivers/base/of.c. It requires OF support or will cause a link failure. Add the missing Kconfig dependency. Closes: https://lore.kernel.org/oe-kbuild-all/202601152233.og6LdeUo-lkp@intel.com/ Signed-off-by: Bartosz Golaszewski Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260116111723.10585-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Sasha Levin commit 88c76792180dffd83f1c5b9dc8fdaeb145cb94e0 Author: Niklas Söderlund Date: Tue Dec 2 23:13:41 2025 +0100 clocksource/drivers/sh_tmu: Always leave device running after probe [ Upstream commit b1278972b08e480990e2789bdc6a7c918bc349be ] The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe. Signed-off-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251202221341.1856773-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin commit dea9989a3f3961faede93752cd81eb5a9514d911 Author: Alexei Starovoitov Date: Mon Jan 12 12:13:57 2026 -0800 bpf: Recognize special arithmetic shift in the verifier [ Upstream commit bffacdb80b93b7b5e96b26fad64cc490a6c7d6c7 ] cilium bpf_wiregard.bpf.c when compiled with -O1 fails to load with the following verifier log: 192: (79) r2 = *(u64 *)(r10 -304) ; R2=pkt(r=40) R10=fp0 fp-304=pkt(r=40) ... 227: (85) call bpf_skb_store_bytes#9 ; R0=scalar() 228: (bc) w2 = w0 ; R0=scalar() R2=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) ... 232: (66) if w2 s> 0xffffffff goto pc+125 ; R2=scalar(smin=umin=umin32=0x80000000,smax=umax=umax32=0xffffff7a,smax32=-134,var_off=(0x80000000; 0x7fffff7a)) ... 238: (79) r4 = *(u64 *)(r10 -304) ; R4=scalar() R10=fp0 fp-304=scalar() 239: (56) if w2 != 0xffffff78 goto pc+210 ; R2=0xffffff78 // -136 ... 258: (71) r1 = *(u8 *)(r4 +0) R4 invalid mem access 'scalar' The error might confuse most bpf authors, since fp-304 slot had 'pkt' pointer at insn 192 and became 'scalar' at 238. That happened because bpf_skb_store_bytes() clears all packet pointers including those in the stack. On the first glance it might look like a bug in the source code, since ctx->data pointer should have been reloaded after the call to bpf_skb_store_bytes(). The relevant part of cilium source code looks like this: // bpf/lib/nodeport.h int dsr_set_ipip6() { if (ctx_adjust_hroom(...)) return DROP_INVALID; // -134 if (ctx_store_bytes(...)) return DROP_WRITE_ERROR; // -141 return 0; } bool dsr_fail_needs_reply(int code) { if (code == DROP_FRAG_NEEDED) // -136 return true; return false; } tail_nodeport_ipv6_dsr() { ret = dsr_set_ipip6(...); if (!IS_ERR(ret)) { ... } else { if (dsr_fail_needs_reply(ret)) return dsr_reply_icmp6(...); } } The code doesn't have arithmetic shift by 31 and it reloads ctx->data every time it needs to access it. So it's not a bug in the source code. The reason is DAGCombiner::foldSelectCCToShiftAnd() LLVM transformation: // If this is a select where the false operand is zero and the compare is a // check of the sign bit, see if we can perform the "gzip trick": // select_cc setlt X, 0, A, 0 -> and (sra X, size(X)-1), A // select_cc setgt X, 0, A, 0 -> and (not (sra X, size(X)-1)), A The conditional branch in dsr_set_ipip6() and its return values are optimized into BPF_ARSH plus BPF_AND: 227: (85) call bpf_skb_store_bytes#9 228: (bc) w2 = w0 229: (c4) w2 s>>= 31 ; R2=scalar(smin=0,smax=umax=0xffffffff,smin32=-1,smax32=0,var_off=(0x0; 0xffffffff)) 230: (54) w2 &= -134 ; R2=scalar(smin=0,smax=umax=umax32=0xffffff7a,smax32=0x7fffff7a,var_off=(0x0; 0xffffff7a)) after insn 230 the register w2 can only be 0 or -134, but the verifier approximates it, since there is no way to represent two scalars in bpf_reg_state. After fallthough at insn 232 the w2 can only be -134, hence the branch at insn 239: (56) if w2 != -136 goto pc+210 should be always taken, and trapping insn 258 should never execute. LLVM generated correct code, but the verifier follows impossible path and rejects valid program. To fix this issue recognize this special LLVM optimization and fork the verifier state. So after insn 229: (c4) w2 s>>= 31 the verifier has two states to explore: one with w2 = 0 and another with w2 = 0xffffffff which makes the verifier accept bpf_wiregard.c A similar pattern exists were OR operation is used in place of the AND operation, the verifier detects that pattern as well by forking the state before the OR operation with a scalar in range [-1,0]. Note there are 20+ such patterns in bpf_wiregard.o compiled with -O1 and -O2, but they're rarely seen in other production bpf programs, so push_stack() approach is not a concern. Reported-by: Hao Sun Signed-off-by: Alexei Starovoitov Co-developed-by: Puranjay Mohan Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260112201424.816836-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4e3e57dbf46dad3498f8c4219ce2dba756875962 Author: Sami Tolvanen Date: Sat Jan 10 08:25:50 2026 +0000 bpf: crypto: Use the correct destructor kfunc type [ Upstream commit b40a5d724f29fc2eed23ff353808a9aae616b48a ] With CONFIG_CFI enabled, the kernel strictly enforces that indirect function calls use a function pointer type that matches the target function. I ran into the following type mismatch when running BPF self-tests: CFI failure at bpf_obj_free_fields+0x190/0x238 (target: bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc) Internal error: Oops - CFI: 00000000f2008228 [#1] SMP ... As bpf_crypto_ctx_release() is also used in BPF programs and using a void pointer as the argument would make the verifier unhappy, add a simple stub function with the correct type and register it as the destructor kfunc instead. Signed-off-by: Sami Tolvanen Acked-by: Yonghong Song Tested-by: Viktor Malik Link: https://lore.kernel.org/r/20260110082548.113748-7-samitolvanen@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit caa44eb450d9434717eff49ba0de9be6f9cb5b1e Author: Martin Schiller Date: Mon Nov 24 08:48:46 2025 +0100 perf/x86/cstate: Add Airmont NP [ Upstream commit 3006911f284d769b0f66c12b39da130325ef1440 ] From the perspective of Intel cstate residency counters, the Airmont NP (aka Lightning Mountain) is identical to the Airmont. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-4-ms@dev.tdt.de Signed-off-by: Sasha Levin commit af1e3d63c8e23a32e4f21e267f6c224b1c615b3b Author: Martin Schiller Date: Mon Nov 24 08:48:44 2025 +0100 perf/x86/msr: Add Airmont NP [ Upstream commit 63dbadcafc1f4d1da796a8e2c0aea1e561f79ece ] Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain) supports SMI_COUNT MSR. Signed-off-by: Martin Schiller Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20251124074846.9653-2-ms@dev.tdt.de Signed-off-by: Sasha Levin commit 17440ef493aaf0bd54ada4b348b03d15a97ffc35 Author: Cupertino Miranda Date: Tue Dec 2 18:02:19 2025 +0000 bpf: verifier improvement in 32bit shift sign extension pattern [ Upstream commit d18dec4b8990048ce75f0ece32bb96b3fbd3f422 ] This patch improves the verifier to correctly compute bounds for sign extension compiler pattern composed of left shift by 32bits followed by a sign right shift by 32bits. Pattern in the verifier was limitted to positive value bounds and would reset bound computation for negative values. New code allows both positive and negative values for sign extension without compromising bound computation and verifier to pass. This change is required by GCC which generate such pattern, and was detected in the context of systemd, as described in the following GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119731 Three new tests were added in verifier_subreg.c. Signed-off-by: Cupertino Miranda Signed-off-by: Andrew Pinski Acked-by: Eduard Zingerman Cc: David Faust Cc: Jose Marchesi Cc: Elena Zannoni Link: https://lore.kernel.org/r/20251202180220.11128-2-cupertino.miranda@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5ab9a958681ec058b11ea53912b2366fbc7dffe5 Author: Sam James Date: Wed Feb 4 13:40:29 2026 +0000 sparc: don't reference obsolete termio struct for TC* constants [ Upstream commit be0bccffcde3308150d2a90e55fc10e249098909 ] Similar in nature to commit ab107276607a ("powerpc: Fix struct termio related ioctl macros"). glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 8e6b0e2adf86b9ff68b5d52ea4d5f1506a6c5967 Author: Andreas Larsson Date: Mon Jan 19 15:47:52 2026 +0100 sparc: Synchronize user stack on fork and clone [ Upstream commit e38eba3b77878ada327a572a41596a3b0b44e522 ] Flush all uncommitted user windows before calling the generic syscall handlers for clone, fork, and vfork. Prior to entering the arch common handlers sparc_{clone|fork|vfork}, the arch-specific syscall wrappers for these syscalls will attempt to flush all windows (including user windows). In the window overflow trap handlers on both SPARC{32|64}, if the window can't be stored (i.e due to MMU related faults) the routine backups the user window and increments a thread counter (wsaved). By adding a synchronization point after the flush attempt, when fault handling is enabled, any uncommitted user windows will be flushed. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=31394 Closes: https://lore.kernel.org/sparclinux/fe5cc47167430007560501aabb28ba154985b661.camel@physik.fu-berlin.de/ Signed-off-by: Andreas Larsson Signed-off-by: Ludwig Rydberg Tested-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/20260119144753.27945-2-ludwig.rydberg@gaisler.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit bfc2420bac712c34a3083768cdd14f8869c2d88a Author: Luke Wang Date: Wed Feb 4 11:40:02 2026 +0800 block: decouple secure erase size limit from discard size limit [ Upstream commit ee81212f74a57c5d2b56cf504f40d528dac6faaf ] Secure erase should use max_secure_erase_sectors instead of being limited by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from REQ_OP_DISCARD to allow each operation to use its own size limit. Signed-off-by: Luke Wang Reviewed-by: Ulf Hansson Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1f0221070f02b5b8e567ca8f50d537dc1b0a2060 Author: Yu Kuai Date: Mon Feb 2 16:05:22 2026 +0800 blk-mq-debugfs: add missing debugfs_mutex in blk_mq_debugfs_register_hctxs() [ Upstream commit 9d20fd6ce1ba9733cd5ac96fcab32faa9fc404dd ] In blk_mq_update_nr_hw_queues(), debugfs_mutex is not held while creating debugfs entries for hctxs. Hence add debugfs_mutex there, it's safe because queue is not frozen. Signed-off-by: Yu Kuai Reviewed-by: Nilay Shroff Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7fb2e1fa6e980e1cbc56c93c19d33cf0b2531804 Author: Jason Andryuk Date: Wed Nov 19 17:47:29 2025 -0500 xenbus: Use .freeze/.thaw to handle xenbus devices [ Upstream commit e08dd1ee49838750a514e83c0aa60cd12ba6ecbb ] The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming from s3 or s2idle disconnects its PV devices during resume. The backends are not expecting this and do not reconnect. b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/ resume/chkpt") changed xen_suspend()/do_suspend() from PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the suspend/resume callbacks remained. .freeze/restore are used with hiberation where Linux restarts in a new place in the future. .suspend/resume are useful for runtime power management for the duration of a boot. The current behavior of the callbacks works for an xl save/restore or live migration where the domain is restored/migrated to a new location and connecting to a not-already-connected backend. Change xenbus_pm_ops to use .freeze/thaw/restore and drop the .suspend/resume hook. This matches the use in drivers/xen/manage.c for save/restore and live migration. With .suspend/resume empty, PV devices are left connected during s2idle and s3, so PV devices are not changed and work after resume. Signed-off-by: Jason Andryuk Acked-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20251119224731.61497-2-jason.andryuk@amd.com> Signed-off-by: Sasha Levin commit 6ac7d51ae076746933c617b204dca7bea0b5bddc Author: Ata İlhan Köktürk Date: Thu Jan 29 17:48:56 2026 +0300 ACPI: battery: fix incorrect charging status when current is zero [ Upstream commit bb1256e0ddc7e9e406164319769b9f8d8389f056 ] On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata İlhan Köktürk [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260129144856.43058-1-atailhan2006@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7aa95b6f14658142047430806ae1947d3963bd79 Author: Jakob Riemenschneider Date: Tue Jan 27 21:01:21 2026 +0100 ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display) [ Upstream commit 229ecbaac6b31f89c554b77eb407377a5eade7d4 ] Windows 11, version 22H2 introduced a new function index (Function 9) to the Microsoft LPS0 _DSM, titled "Turn On Display Notification". According to Microsoft documentation, this function signals to the system firmware that the OS intends to turn on the display when exiting Modern Standby. This allows the firmware to release Power Limits (PLx) earlier. Crucially, this patch fixes a functional issue observed on the Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard backlights fail to resume after suspend. Investigation linked shows the EC on this device turns off these components during sleep but requires the Function 9 notification to wake them up again. This patch defines the new function index (ACPI_MS_TURN_ON_DISPLAY) and invokes it in acpi_s2idle_restore_early_lps0(). The execution order is updated to match the logic of an "intent" signal: 1. LPS0 Exit (Function 6) 2. Turn On Display Intent (Function 9) 3. Modern Standby Exit (Function 8) 4. Screen On (Function 4) Invoking Function 9 before the Modern Standby Exit ensures the firmware has time to restore power rails and functionality (like fans) before the software fully exits the sleep state. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications#turn-on-display-notification-function-9 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220505 Suggested-by: Antheas Kapenekakis Signed-off-by: Jakob Riemenschneider Link: https://patch.msgid.link/20260127200121.1292216-1-riemenschneiderjakob@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e3f21fdea4cb33395a86fdb28e7871ebf16b2f20 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:34 2026 +0100 perf/cxlpmu: Replace IRQF_ONESHOT with IRQF_NO_THREAD [ Upstream commit ab26d9c85554c4ff1d95ca8341522880ed9219d6 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also disallows force-threading of the primary handler and the irq-core will warn about this. The intention here was probably not allowing forced-threading. Replace IRQF_ONESHOT with IRQF_NO_THREAD. Reviewed-by: Jonathan Cameron Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7f5a66a18b5c839c642066264b81a359104ccc2a Author: Thomas Richter Date: Fri Jan 23 10:14:12 2026 +0100 s390/perf: Disable register readout on sampling events [ Upstream commit b2c04fc1239062b39ddfdd8731ee1a10810dfb74 ] Running commands # ./perf record -IR0,R1 -a sleep 1 extracts and displays register value of general purpose register r1 and r0. However the value displayed of any register is random and does not reflect the register value recorded at the time of the sample interrupt. The sampling device driver on s390 creates a very large buffer for the hardware to store the samples. Only when that large buffer gets full an interrupt is generated and many hundreds of sample entries are processed and copied to the kernel ring buffer and eventually get copied to the perf tool. It is during the copy to the kernel ring buffer that each sample is processed (on s390) and at that time the register values are extracted. This is not the original goal, the register values should be read when the samples are created not when the samples are copied to the kernel ring buffer. Prevent this event from being installed in the first place and return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER. Signed-off-by: Thomas Richter Reviewed-by: Jan Polensky Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit e35db916e8039f0db5ed616026fc89914eaaac44 Author: Konrad Dybcio Date: Tue Jan 13 16:25:35 2026 +0100 cpufreq: dt-platdev: Block the driver from probing on more QC platforms [ Upstream commit 7b781899072c5701ef9538c365757ee9ab9c00bd ] Add a number of QC platforms to the blocklist, they all use either the qcom-cpufreq-hw driver. Signed-off-by: Konrad Dybcio Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit dec123825c1ed74d98fd5fc7571a851dea4f46ff Author: Jiasheng Jiang Date: Sat Jan 17 14:59:03 2026 +0000 md-cluster: fix NULL pointer dereference in process_metadata_update [ Upstream commit f150e753cb8dd756085f46e86f2c35ce472e0a3c ] The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro. While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run): 1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until later in md_run(). If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic. To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it. Link: https://lore.kernel.org/linux-raid/20260117145903.28921-1-jiashengjiangcool@gmail.com Signed-off-by: Jiasheng Jiang Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit d4ca6ca2c6f5a1d19d9014c5b36d96637846b5d6 Author: Magnus Lindholm Date: Fri Jan 2 18:30:43 2026 +0100 alpha: fix user-space corruption during memory compaction [ Upstream commit dd5712f3379cfe760267cdd28ff957d9ab4e51c7 ] Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled. Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation. The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration. Fix this by introducing a migration-specific helper that combines: - MM context invalidation (ASN rollover), - immediate per-CPU TLB invalidation (TBI), - synchronous cross-CPU shootdown when required. The helper is used only by migration/compaction paths to avoid changing global TLB semantics. Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering. This fixes observed crashes on both UP and SMP Alpha systems. Reviewed-by: Ivan Kokshaysky Tested-by: Matoro Mahri Tested-by: Michael Cree Signed-off-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260102173603.18247-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit 33f53ac8e9d5f16e218bfae1183796cdb41bb4c5 Author: Daniel Tang Date: Wed Jan 14 21:01:52 2026 -0500 powercap: intel_rapl: Add PL4 support for Ice Lake [ Upstream commit 54b3cd55a515c7c0fcfa0c1f0b10d62c11d64bcc ] Microsoft Surface Pro 7 firmware throttles the processor upon boot/resume. Userspace needs to be able to restore the correct value. Link: https://github.com/linux-surface/linux-surface/issues/706 Signed-off-by: Daniel Tang Link: https://patch.msgid.link/6088605.ChMirdbgyp@daniel-desktop3 Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 61103a85e632a9c5053806c1d2749c0adf235701 Author: Armin Wolf Date: Wed Jan 14 13:25:33 2026 +0100 ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP [ Upstream commit 026ad376a6a48538b576f3589331daa94daae6f0 ] The ACPI specification states that when executing AML_FATAL_OP, the OS should log the fatal error event and shutdown in a timely fashion. Windows complies with this requirement by immediatly entering a Bso_d, effectively aborting the execution of the AML bytecode in question. ACPICA however might continue with the AML bytecode execution should acpi_os_signal() simply return AE_OK. This will cause issues because ACPI BIOS implementations might assume that the Fatal() operator does not return. Fix this by aborting the AML bytecode execution in such a case by returning AE_ERROR. Also turn struct acpi_signal_fatal_info into a local variable because of its small size (12 bytes) and to ensure that acpi_os_signal() always receives valid information about the fatal ACPI BIOS error. Link: https://github.com/acpica/acpica/commit/d516c7758ba6 Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3325491.5fSG56mABF@rafael.j.wysocki Signed-off-by: Sasha Levin commit 5e7c8b5cce4c44b75f0ef88e37ab7aa700d2bbd9 Author: Ai Chao Date: Tue Jan 13 15:27:19 2026 +0800 ACPI: resource: Add JWIPC JVC9100 to irq1_level_low_skip_override[] [ Upstream commit ba6ded26dffe511b862a98a25955955e7154bfa8 ] Like the JWIPC JVC9100 has its serial IRQ (10 and 11) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the serial. irq 10, level, active-low, shared, skip-override irq 11, level, active-low, shared, skip-override Add the JVC9100 to the irq1_level_low_skip_override[] quirk table to fix this. Signed-off-by: Ai Chao Link: https://patch.msgid.link/20260113072719.4154485-1-aichao@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b803811485ac0b2f774b6bf3abc8b999ba3b7033 Author: Tuo Li Date: Mon Jan 12 00:32:14 2026 +0800 ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4() [ Upstream commit f132e089fe89cadc2098991f0a3cb05c3f824ac6 ] In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...); If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...); To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value. Signed-off-by: Tuo Li [ rjw: Subject adjustment, added an empty code line ] Link: https://patch.msgid.link/20260111163214.202262-1-islituo@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit be10c1bdf64a39832998f54900aa309b3917abcf Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:04 2026 +0100 EFI/CPER: don't go past the ARM processor CPER record buffer [ Upstream commit eae21beecb95a3b69ee5c38a659f774e171d730e ] There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/41cd9f6b3ace3cdff7a5e864890849e4b1c58b63.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 242c652849d979d0133c315a42d9acea0ff88390 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:03 2026 +0100 APEI/GHES: ARM processor Error: don't go past allocated memory [ Upstream commit 87880af2d24e62a84ed19943dbdd524f097172f2 ] If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info = (struct cper_arm_err_info *)(err + 1); 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err = (u8 *)ctx_info; 73 74 for (n = 0; n < err->context_info_num; n++) { 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len += sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/7fd9f38413be05ee2d7cfdb0dc31ea2274cf1a54.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b6be51a12441136fdf8c49b2525689fbea1856e1 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:05 2026 +0100 APEI/GHES: ensure that won't go past CPER allocated record [ Upstream commit fa2408a24f8f0db14d9cfc613ef162dc267d7ad4 ] The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/4e70310a816577fabf37d94ed36cde4ad62b1e0a.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7780c0bad2a3a70a8c0113a33c02f4151d901eb3 Author: Mauro Carvalho Chehab Date: Thu Jan 8 12:35:06 2026 +0100 EFI/CPER: don't dump the entire memory region [ Upstream commit 55cc6fe5716f678f06bcb95140882dfa684464ec ] The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Acked-by: Ard Biesheuvel Reviewed-by: Hanjun Guo [ rjw: Subject tweaks ] Link: https://patch.msgid.link/1752b5ba63a3e2f148ddee813b36c996cc617e86.1767871950.git.mchehab+huawei@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0cb30030b483d1ecc70a78494dbcb19df4b3e23f Author: Hou Wenlong Date: Sat Jan 10 12:00:08 2026 +0800 x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set [ Upstream commit db9aded979b491a24871e1621cd4e8822dbca859 ] The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: Signed-off-by: Sasha Levin commit 7aac0a30dcf41cdb510526740d9a2ab1520c5d98 Author: Md Haris Iqbal Date: Fri Dec 5 13:47:33 2025 +0100 rnbd-srv: Zero the rsp buffer before using it [ Upstream commit 69d26698e4fd44935510553809007151b2fe4db5 ] Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions. Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5dbe1f14359735fa50ba0dd4a496125b5bc7f422 Author: Jinqian Yang Date: Sat Dec 27 17:24:48 2025 +0800 arm64: Add support for TSV110 Spectre-BHB mitigation [ Upstream commit e3baa5d4b361276efeb87b20d8beced451a7dbd5 ] The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation. Signed-off-by: Jinqian Yang Reviewed-by: Zenghui Yu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit fc38a1f0d55f4c7c93f48ff25eff0c932d94f53e Author: Robin Murphy Date: Mon Nov 24 16:39:54 2025 +0000 perf/arm-cmn: Support CMN-600AE [ Upstream commit 12a94953c37e834c3eabb839ce057094946fe67a ] The functional safety features of CMN-600AE have little to no impact on the PMU relative to the base CMN-600 design, so for simplicity we can reasonably just treat it as the same thing. The only obvious difference is that the revision numbers aren't aligned, so we may hide some aliases for events which do actually exist, but those can still be specified via the underlying "type,eventid" format so it's not too big a deal. Signed-off-by: Robin Murphy Reviewed-by: Ilkka Koskinen Tested-by: Michal Simek Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c0ec4299b15b74c2047e10d308c3beb1191b89d2 Author: Heiko Carstens Date: Fri Dec 12 16:47:07 2025 +0100 s390/purgatory: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS [ Upstream commit b4780fe4ddf04b51127a33d705f4a2e224df00fa ] Add -Wno-default-const-init-unsafe to purgatory KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/purgatory/purgatory.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit bcbfd4d818120bd56fa0ccb09218a4bee428daad Author: Kaushlendra Kumar Date: Mon Dec 1 17:47:45 2025 +0530 tools/power cpupower: Reset errno before strtoull() [ Upstream commit f9bd3762cf1bd0c2465f2e6121b340883471d1bf ] cpuidle_state_get_one_value() never cleared errno before calling strtoull(), so a prior ERANGE caused every cpuidle counter read to return zero. Reset errno to 0 before the conversion so each sysfs read is evaluated independently. Link: https://lore.kernel.org/r/20251201121745.3776703-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ab6564f416a6eaf1199200b6100952407b438f7d Author: Henrique Carvalho Date: Mon Jan 19 14:54:44 2026 -0300 smb: client: prevent races in ->query_interfaces() [ Upstream commit c3c06e42e1527716c54f3ad2ced6a034b5f3a489 ] It was possible for two query interface works to be concurrently trying to update the interfaces. Prevent this by checking and updating iface_last_update under iface_lock. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5d2c4f182ea8516de8682e2b60411c03df00e3ea Author: Andreas Gruenbacher Date: Thu Feb 5 15:52:57 2026 +0100 gfs2: fiemap page fault fix [ Upstream commit e411d74cc5ba290f85d0dd5e4d1df8f1d6d975d2 ] In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit a20d029585c2a45240df96ba70a85a4661bc387c Author: Henrique Carvalho Date: Mon Jan 19 14:54:45 2026 -0300 smb: client: add proper locking around ses->iface_last_update [ Upstream commit e97dcac3dc0bd37e4b56aaa6874b572a3a461102 ] There is a missing ses->iface_lock in cifs_setup_session, around ses->iface_last_update. Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0a45c428ad19bf1b9f0e7304f02bcb195870c865 Author: jinbaohong Date: Wed Jan 28 07:06:40 2026 +0000 btrfs: handle user interrupt properly in btrfs_trim_fs() [ Upstream commit bfb670b9183b0e4ba660aff2e396ec1cc01d0761 ] When a fatal signal is pending or the process is freezing, btrfs_trim_block_group() and btrfs_trim_free_extents() return -ERESTARTSYS. Currently this is treated as a regular error: the loops continue to the next iteration and count it as a block group or device failure. Instead, break out of the loops immediately and return -ERESTARTSYS to userspace without counting it as a failure. Also skip the device loop entirely if the block group loop was interrupted. Reviewed-by: Qu Wenruo Signed-off-by: Robbie Ko Signed-off-by: jinbaohong Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b034e842e326a52700797d210f86953176da3a1f Author: Qu Wenruo Date: Sat Nov 1 10:22:16 2025 +1030 btrfs: fallback to buffered IO if the data profile has duplication [ Upstream commit 7c2830f00c3e086292c1ee9f27b61efaf8e76c9a ] [BACKGROUND] Inspired by a recent kernel bug report, which is related to direct IO buffer modification during writeback, that leads to contents mismatch of different RAID1 mirrors. [CAUSE AND PROBLEMS] The root cause is exactly the same explained in commit 968f19c5b1b7 ("btrfs: always fallback to buffered write if the inode requires checksum"), that we can not trust direct IO buffer which can be modified halfway during writeback. Unlike data checksum verification, if this happened on inodes without data checksum but has the data has extra mirrors, it will lead to stealth data mismatch on different mirrors. This will be way harder to detect without data checksum. Furthermore for RAID56, we can even have data without checksum and data with checksum mixed inside the same full stripe. In that case if the direct IO buffer got changed halfway for the nodatasum part, the data with checksum immediately lost its ability to recover, e.g.: " " = Good old data or parity calculated using good old data "X" = Data modified during writeback 0 32K 64K Data 1 | | Has csum Data 2 |XXXXXXXXXXXXXXXX | No csum Parity | | In above case, the parity is calculated using data 1 (has csum, from page cache, won't change during writeback), and old data 2 (has no csum, direct IO write). After parity is calculated, but before submission to the storage, direct IO buffer of data 2 is modified, causing the range [0, 32K) of data 2 has a different content. Now all data is submitted to the storage, and the fs got fully synced. Then the device of data 1 is lost, has to be rebuilt from data 2 and parity. But since the data 2 has some modified data, and the parity is calculated using old data, the recovered data is no the same for data 1, causing data checksum mismatch. [FIX] Fix the problem by checking the data allocation profile. If our data allocation profile is either RAID0 or SINGLE, we can allow true zero-copy direct IO and the end user is fully responsible for any race. However this is not going to fix all situations, as it's still possible to race with balance where the fs got a new data profile after the data allocation profile check. But this fix should still greatly reduce the window of the original bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=99171 Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 67288113c5e6cf9e659b4065c0ed6f16100e0c71 Author: Ezrak1e Date: Tue Jan 20 10:35:06 2026 -0500 dlm: validate length in dlm_search_rsb_tree [ Upstream commit 080e5563f878c64e697b89e7439d730d0daad882 ] The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow. Signed-off-by: Ezrak1e Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit f57ccd4657c7f082dc47e5b9e18a883bb5f9118f Author: Jori Koolstra Date: Mon Dec 8 16:39:47 2025 +0100 minix: Add required sanity checking to minix_check_superblock() [ Upstream commit 8c97a6ddc95690a938ded44b4e3202f03f15078c ] The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report. Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20251208153947.108343-1-jkoolstra@xs4all.nl Reviewed-by: Jan Kara Reported-by: syzbot+5ad0824204c7bf9b67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5ad0824204c7bf9b67f2 Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 91705db6642c6c9495491d74e0e2fd1e03ad33fe Author: Adrian Hunter Date: Tue Jan 13 09:26:42 2026 +0200 i3c: mipi-i3c-hci: Reset RING_OPERATION1 fields during init [ Upstream commit 78f63ae4a82db173f93adca462e63d11ba06b126 ] The MIPI I3C HCI specification does not define reset values for RING_OPERATION1 fields, and some controllers (e.g., Intel) do not clear them during a software reset. Ensure the ring pointers are explicitly set to zero during bus initialization to avoid inconsistent state. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 689d85945cbdc6e5f90f93b8c0e2076d592a1397 Author: Frank Li Date: Mon Dec 15 15:08:51 2025 -0500 i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr() [ Upstream commit 3c9ffb4db787428a5851d5865823ab23842d5103 ] Initialize the 'dev' pointer to NULL in svc_i3c_master_ibi_isr() and add a NULL check in the error path. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202512131016.YCKIsDXM-lkp@intel.com/ Signed-off-by: Frank Li Link: https://patch.msgid.link/20251215200852.3079073-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit d209ebaee93fc5089101d34d1b38a91d7abb03fd Author: Tetsuo Handa Date: Tue Jan 6 18:39:33 2026 +0900 hfsplus: pretend special inodes as regular files [ Upstream commit ed8889ca21b6ab37bc1435c4009ce37a79acb9e6 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/d0a07b1b-8b73-4002-8e29-e2bd56871262@I-love.SAKURA.ne.jp Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 5632d14b2f2a0ade2d0068e12676ebed67e3bb2a Author: Jeffrey Bencteux Date: Sat Dec 27 09:39:24 2025 +0100 audit: add missing syscalls to read class [ Upstream commit bcb90a2834c7393c26df9609b889a3097b7700cd ] The "at" variant of getxattr() and listxattr() are missing from the audit read class. Calling getxattrat() or listxattrat() on a file to read its extended attributes will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds missing syscalls to the audit read class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 727e5140e0cf83b4ce6a11b89bb73bff5d96f8f3 Author: Deepakkumar Karn Date: Thu Dec 11 18:42:11 2025 +0530 fs/buffer: add alert in try_to_free_buffers() for folios without buffers [ Upstream commit b68f91ef3b3fe82ad78c417de71b675699a8467c ] try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn Link: https://patch.msgid.link/20251211131211.308021-1-dkarn@redhat.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 773855c2ef5fcd8dae99c74e6906858e24bad44d Author: Viacheslav Dubeyko Date: Sat Dec 6 19:58:22 2025 -0800 hfsplus: fix volume corruption issue for generic/498 [ Upstream commit 9a8c4ad44721da4c48e1ff240ac76286c82837fe ] The xfstests' test-case generic/498 leaves HFS+ volume in corrupted state: sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #18 SMP PREEMPT_DYNAMIC Thu Dec 4 12:24:45 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see XFSTESTS-2/xfstests-dev/results//generic/498.full for details) Ran: generic/498 Failures: generic/498 Failed 1 of 1 tests sudo fsck.hfsplus -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Invalid leaf record count (It should be 16 instead of 2) ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x8000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. CheckHardLinks: found 1 pre-Leopard file inodes. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The generic/498 test executes such steps on final phase: mkdir $SCRATCH_MNT/A mkdir $SCRATCH_MNT/B mkdir $SCRATCH_MNT/A/C touch $SCRATCH_MNT/B/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/B/foo ln $SCRATCH_MNT/B/foo $SCRATCH_MNT/A/C/foo $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/A "Simulate a power failure and mount the filesystem to check that what we explicitly fsync'ed exists." _flakey_drop_and_remount The FSCK tool complains about "Invalid leaf record count". HFS+ b-tree header contains leaf_count field is updated by hfs_brec_insert() and hfs_brec_remove(). The hfs_brec_insert() is involved into hard link creation process. However, modified in-core leaf_count field is stored into HFS+ b-tree header by hfs_btree_write() method. But, unfortunately, hfs_btree_write() hasn't been called by hfsplus_cat_write_inode() and hfsplus_file_fsync() stores not fully consistent state of the Catalog File's b-tree. This patch adds calling hfs_btree_write() method in the hfsplus_cat_write_inode() with the goal of storing consistent state of Catalog File's b-tree. Finally, it makes FSCK tool happy. sudo ./check generic/498 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc1+ #22 SMP PREEMPT_DYNAMIC Sat Dec 6 17:01:31 PST 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/498 33s ... 31s Ran: generic/498 Passed all 1 tests Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251207035821.3863657-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 3e762a03713e8c25ca0108c075d662c897fc0623 Author: Jeffrey Bencteux Date: Mon Nov 24 20:49:30 2025 +0100 audit: add fchmodat2() to change attributes class [ Upstream commit 4f493a6079b588cf1f04ce5ed6cdad45ab0d53dc ] fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as: -w /tmp/test -p rwa -k test_rwa The current patch adds fchmodat2() to the change attributes class. Signed-off-by: Jeffrey Bencteux Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 9c1c09c3d1343c75890a02a43630be22cfc8188e Author: Bhavik Sachdev Date: Sat Nov 29 14:41:20 2025 +0530 statmount: permission check should return EPERM [ Upstream commit fccbe38a5d06dbe44bcd89196fe1d2c2272a1f4a ] Currently, statmount() returns ENOENT when caller is not CAP_SYS_ADMIN in the user namespace owner of target mount namespace. This should be EPERM instead. Suggested-by: Miklos Szeredi Signed-off-by: Bhavik Sachdev Link: https://patch.msgid.link/20251129091455.757724-2-b.sachdev1904@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 0fd52d901b696c771d562806d0b42014ee8e0266 Author: Anthony Pighin (Nokia) Date: Tue Nov 25 17:35:19 2025 +0000 rtc: interface: Alarm race handling should not discard preceding error [ Upstream commit 81be22cd4ace020045cc6d31255c6f7c071eb7c0 ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") should not discard any errors from the preceding validations. Prior to that commit, if the alarm feature was disabled, or the set_alarm failed, a meaningful error code would be returned to the caller for further action. After, more often than not, the __rtc_read_time will cause a success return code instead, misleading the caller. An example of this is when timer_enqueue is called for a rtc-abx080x device. Since that driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid, the discard of the return code causes very different behaviour; i.e. hwclock: select() to /dev/rtc0 to wait for clock tick timed out Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") Signed-off-by: Anthony Pighin (Nokia) Reviewed-by: Esben Haabendal Tested-by: Nick Bowler Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 70a69f675b9f6ec3f1de472ac68bd393f0b5b580 Author: Ian Rogers Date: Mon Feb 2 22:09:18 2026 -0800 libperf build: Always place libperf includes first [ Upstream commit 8c5b40678c63be6b85f1c2dc8c8b89d632faf988 ] When building tools/perf the CFLAGS can contain a directory for the installed headers. As the headers may be being installed while building libperf.a this can cause headers to be partially installed and found in the include path while building an object file for libperf.a. The installed header may reference other installed headers that are missing given the partial nature of the install and then the build fails with a missing header file. Avoid this by ensuring the libperf source headers are always first in the CFLAGS. Fixes: 3143504918105156 ("libperf: Make libperf.a part of the perf build") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5f15fa06dccb6034777aaefd8ccfb2993fb9d9bf Author: James Clark Date: Wed Mar 19 11:40:09 2025 +0000 libperf: Don't remove -g when EXTRA_CFLAGS are used [ Upstream commit f5b07010c13c77541e8ade167d05bef3b8a63739 ] When using EXTRA_CFLAGS, for example "EXTRA_CFLAGS=-DREFCNT_CHECKING=1", this construct stops setting -g which you'd expect would not be affected by adding extra flags. Additionally, EXTRA_CFLAGS should be the last thing to be appended so that it can be used to undo any defaults. And no condition is required, just += appends to any existing CFLAGS and also appends or doesn't append EXTRA_CFLAGS if they are or aren't set. It's not clear why DEBUG=1 is required for -g in Perf when in libperf it's always on, but I don't think we need to change that behavior now because someone may be depending on it. Signed-off-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250319114009.417865-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Stable-dep-of: 8c5b40678c63 ("libperf build: Always place libperf includes first") Signed-off-by: Sasha Levin commit 73e1f48e51496b237bb2b40b2ff3feb830bb3670 Author: Sandipan Das Date: Thu Jan 22 13:39:46 2026 +0530 perf vendor events amd: Fix Zen 5 MAB allocation events [ Upstream commit 76b2cf07a6d2a836108f9c2486d76599f7adf6e8 ] The unit masks for PMCx041 vary across different generations of Zen processors. Fix the Zen 5 events based on PMCx041 as they incorrectly use the same unit masks as that of Zen 4. Fixes: 45c072f2537ab07b ("perf vendor events amd: Add Zen 5 core events") Reported-by: Suyash Mahar Reviewed-by: Ian Rogers Signed-off-by: Sandipan Das Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ananth Narayan Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sandipan Das Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f7ed915c96b35160a418e389f910319f725d2092 Author: Suchit Karunakaran Date: Thu Jan 22 22:47:04 2026 +0530 perf annotate: Fix memcpy size in arch__grow_instructions() [ Upstream commit f0d98c78f8bf73ce2a9b7793f66cda240fa9ab10 ] The memcpy() in arch__grow_instructions() is copying the wrong number of bytes when growing from a non-allocated table. It should copy arch->nr_instructions * sizeof(struct ins) bytes, not just arch->nr_instructions bytes. This bug causes data corruption as only a partial copy of the instruction table is made, leading to garbage data in most entries and potential crashes Fixes: 2a1ff812c40be982 ("perf annotate: Introduce alternative method of keeping instructions table") Reviewed-by: Ian Rogers Signed-off-by: Suchit Karunakaran Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 08e16d9a3cefe394620b224aaed7efd32f50005e Author: Ian Rogers Date: Thu Jan 22 13:35:07 2026 -0800 perf maps: Fix reference count leak in maps__find_ams() [ Upstream commit 6fdd2676db55b503c52dd3f1359b5c57f774ab75 ] ams and so ams->ms.map is an in argument, however, it is also overwritten. As a map is reference counted, ensure a map__put() is done before overwriting it. Fixes: 42fd623b58dbcc48 ("perf maps: Get map before returning in maps__find") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e9003b440603f80ad8a93f34278cca352d55d280 Author: Sri Jayaramappa Date: Tue Dec 2 16:36:32 2025 -0500 libsubcmd: Fix null intersection case in exclude_cmds() [ Upstream commit b6ee9b6e206b288921c14c906eebf4b32fe0c0d8 ] When there is no exclusion occurring from the cmds list - for example - cmds contains ["read-vdso32"] and excludes contains ["archive"] - the main loop completes with ci == cj == 0. In the original code the loop processing the remaining elements in the list was conditional: if (ci != cj) { ...} So we end up in the assertion loop since ci < cmds->cnt and we incorrectly try to assert the list elements to be NULL and fail with the following error help.c:104: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. Fix this by moving the if (ci != cj) check inside of a broader loop. If ci != cj, left shift the list elements, as before, and then unconditionally advance the ci and cj indicies which also covers the ci == cj case. Fixes: 1fdf938168c4d26f ("perf tools: Fix use-after-free in help_unknown_cmd()") Reviewed-by: Guilherme Amadio Signed-off-by: Sri Jayaramappa Tested-by: Guilherme Amadio Tested-by: Ian Rogers Cc: Joshua Hunt Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20251202213632.2873731-1-sjayaram@akamai.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2edbcd501c7b3c29fe75ef3c3ff0c30e41d851f7 Author: Ian Rogers Date: Sat Jan 10 20:13:36 2026 -0800 perf callchain: Fix srcline printing with inlines [ Upstream commit abec464767b5d26f0612250d511c18f420826ca1 ] sample__fprintf_callchain() was using map__fprintf_srcline() which won't report inline line numbers. Fix by using the srcline from the callchain and falling back to the map variant. Fixes: 25da4fab5f66e659 ("perf evsel: Move fprintf methods to separate source file") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ccfafeb79a91bf13c4b2e33be6bb9a52d25e53b5 Author: Ian Rogers Date: Sat Jan 10 20:13:32 2026 -0800 perf unwind-libdw: Fix invalid reference counts [ Upstream commit f815fc0c66e777c727689666cfb46b8d461c2f99 ] The addition of addr_location__exit() causes use-after put on the maps and map references in the unwind info. Add the gets and then add the map_symbol__exit() calls. Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Tony Jones Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4062fb52682c497c002ee252d395aecc9e084976 Author: Thomas Richter Date: Wed Jan 7 14:32:16 2026 +0100 perf test stat tests: Fix for virtualized machines [ Upstream commit e272628902c1c96731e2d9f62a7fc77767686eb0 ] On s390 'perf test's 'perf stat tests', subtest test_hybrid fails for z/VM systems. The root cause is this statement: $(perf stat -a -- sleep 0.1 2>&1 |\ grep -E "/cpu-cycles/[uH]*| cpu-cycles[:uH]* -c) The 'perf stat' output on a s390 z/VM system is # perf stat -a -- sleep 0.1 2>&1 Performance counter stats for 'system wide': 56 context-switches # 46.3 cs/sec cs_per_second 1,210.41 msec cpu-clock # 11.9 CPUs CPUs_utilized 12 cpu-migrations # 9.9 migrations/sec ... 81 page-faults # 66.9 faults/sec ... 0.100891009 seconds time elapsed The grep command does not match any single line and exits with error code 1. As the bash script is executed with 'set -e', it aborts with the first error code being non-zero. Fix this and use 'wc -l' to count matching lines instead of 'grep ... -c'. Output before: # perf test 102 102: perf stat tests : FAILED! # Output after: # perf test 102 102: perf stat tests : Ok # Fixes: bb6e7cb11d97ce19 ("perf tools: Add fallback for exclude_guest") Reviewed-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Thomas Richter Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Jan Polensky Cc: linux-s390@vger.kernel.org Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Vasily Gorbik Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 99dc6b1674fbf1ac22658fe1200fe45e720c9155 Author: Ian Rogers Date: Tue Nov 11 13:22:04 2025 -0800 perf test stat: Update test expectations and events [ Upstream commit a48cd551d7436be3b1bd65c63a6d00163f7e7706 ] test_stat_record_report and test_stat_record_script used default output which triggers a bug when sending metrics. As this isn't relevant to the test switch to using named software events. Update the match in test_hybrid as the cycles event is now cpu-cycles to workaround potential ARM issues. Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Stable-dep-of: e272628902c1 ("perf test stat tests: Fix for virtualized machines") Signed-off-by: Sasha Levin commit 6b3dd16740055ed688e3265c59794d3c6f33796c Author: Shengjiu Wang Date: Thu Feb 12 10:18:29 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak5558: Fix the supply names commit 80ca113671a005430207d351cb403c1637106212 upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix the yaml binding document. Fixes: 829d78e3ea32 ("ASoC: dt-bindings: ak5558: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-4-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6eb2b702dd613ac370a577db0a97d9b6259307c5 Author: Shengjiu Wang Date: Thu Feb 12 10:18:28 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: Fix the supply names commit e570a5ca307f6d7a6acd080fc219db2ce3c0737b upstream. In the original txt format binding document ak4458.txt, the supply names are 'AVDD-supply', 'DVDD-supply', and they are also used in driver. But in the commit converting to yaml format, they are changed to 'avdd-supply', 'dvdd-supply'. After search all the dts file, these names 'AVDD-supply', 'DVDD-supply', 'avdd-supply', 'dvdd-supply' are not used in any dts file. So it is safe to fix this yaml binding document. Fixes: 009e83b591dd ("ASoC: dt-bindings: ak4458: Convert to dtschema") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cbebce4ddfabb165207bee5d6851cab0c9cbcc5b Author: Shengjiu Wang Date: Thu Feb 12 10:18:27 2026 +0800 ASoC: dt-bindings: asahi-kasei,ak4458: set unevaluatedProperties:false commit 50a634f1d795721ce68583c78ba493f1d7aa8bc2 upstream. When including the dai-common.yaml, and allow '#sound-dai-cells' and "sound-name-prefix' to be used, should use unevaluatedProperties:false according to writing-bindings.rst. Fixes: 8d7de4a014f5 ("ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260212021829.3244736-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 596900f63aaf1461c228fc2d2e4a0b09bd714d25 Author: Abel Vesa Date: Wed Dec 24 12:53:27 2025 +0200 dt-bindings: phy: qcom-edp: Add missing clock for X Elite commit 6b99eeacf6abb1ff2d6463c84e490343f39cf11a upstream. On X Elite platform, the eDP PHY uses one more clock called ref. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So attach the this ref clock to the PHY. Cc: stable@vger.kernel.org # v6.10 Fixes: 5d5607861350 ("dt-bindings: phy: qcom-edp: Add X1E80100 PHY compatibles") Reviewed-by: Krzysztof Kozlowski Reviewed-by: Bjorn Andersson Signed-off-by: Abel Vesa Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-1-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e464e26b2457005c87e158570498274b9f3b90c7 Author: Daniel Hodges Date: Fri Feb 6 15:41:46 2026 -0500 SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path commit dd2fdc3504592d85e549c523b054898a036a6afe upstream. Commit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier. Fixes: 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit b4af3806846778799cd4ab0766dc18341e777264 Author: Chuck Lever Date: Fri Dec 26 10:15:32 2025 -0500 SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths commit 3e6397b056335cc56ef0e9da36c95946a19f5118 upstream. The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error. Reported-by: Xingjing Deng Closes: https://lore.kernel.org/linux-nfs/CAK+ZN9qttsFDu6h1FoqGadXjMx1QXqPMoYQ=6O9RY4SxVTvKng@mail.gmail.com/ Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 6bd22de73c12ce6d755fb132ba917534ff6086da Author: Jan Kiszka Date: Mon Feb 16 17:24:56 2026 +0100 Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT commit f8e6343b7a89c7c649db5a9e309ba7aa20401813 upstream. Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V with related guest support enabled: [ 1.127941] hv_vmbus: registering driver hyperv_drm [ 1.132518] ============================= [ 1.132519] [ BUG: Invalid wait context ] [ 1.132521] 6.19.0-rc8+ #9 Not tainted [ 1.132524] ----------------------------- [ 1.132525] swapper/0/0 is trying to lock: [ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0 [ 1.132543] other info that might help us debug this: [ 1.132544] context-{2:2} [ 1.132545] 1 lock held by swapper/0/0: [ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0 [ 1.132557] stack backtrace: [ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)} [ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025 [ 1.132567] Call Trace: [ 1.132570] [ 1.132573] dump_stack_lvl+0x6e/0xa0 [ 1.132581] __lock_acquire+0xee0/0x21b0 [ 1.132592] lock_acquire+0xd5/0x2d0 [ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132606] ? lock_acquire+0xd5/0x2d0 [ 1.132613] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132619] rt_spin_lock+0x3f/0x1f0 [ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0 [ 1.132629] ? vmbus_chan_sched+0x31/0x2b0 [ 1.132634] vmbus_chan_sched+0xc4/0x2b0 [ 1.132641] vmbus_isr+0x2c/0x150 [ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0 [ 1.132654] sysvec_hyperv_callback+0x88/0xb0 [ 1.132658] [ 1.132659] [ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20 As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT, the vmbus_isr execution needs to be moved into thread context. Open- coding this allows to skip the IPI that irq_work would additionally bring and which we do not need, being an IRQ, never an NMI. This affects both x86 and arm64, therefore hook into the common driver logic. Signed-off-by: Jan Kiszka Reviewed-by: Florian Bezdeka Tested-by: Florian Bezdeka Reviewed-by: Michael Kelley Tested-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit e77bcf83bc9052df77e6823111d3362011536395 Author: Damien Le Moal Date: Wed Dec 17 14:05:25 2025 +0900 ata: libata-scsi: refactor ata_scsi_translate() commit bb3a8154b1a1dc2c86d037482c0a2cf9186829ed upstream. Factor out of ata_scsi_translate() the code handling queued command deferral using the port qc_defer callback and issuing the queued command with ata_qc_issue() into the new function ata_scsi_qc_issue(), and simplify the goto used in ata_scsi_translate(). While at it, also add a lockdep annotation to check that the port lock is held when ata_scsi_translate() is called. No functional changes. Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Reviewed-by: Igor Pylypiv Signed-off-by: Greg Kroah-Hartman commit 17df036a24aa28b95fd6f8dee1358737a376d5e2 Author: Linus Walleij Date: Tue Feb 3 11:23:01 2026 +0100 ata: pata_ftide010: Fix some DMA timings commit ff4a46c278ac6a4b3f39be1492a4568b6dcc6105 upstream. The FTIDE010 has been missing some timing settings since its inception, since the upstream OpenWrt patch was missing these. The community has since come up with the appropriate timings. Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010") Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit f1cd271b431bd236dea85bbd4a382ce4560f37ed Author: Jan Kara Date: Wed Jan 14 19:28:19 2026 +0100 ext4: use optimized mballoc scanning regardless of inode format commit 3574c322b1d0eb32dbd76b469cb08f9a67641599 upstream. Currently we don't used mballoc optimized scanning (using max free extent order and avg free extent order group lists) for inodes with indirect block based format. This is confusing for users and I don't see a good reason for that. Even with indirect block based inode format we can spend big amount of time searching for free blocks for large filesystems with fragmented free space. To add to the confusion before commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount option work with extents") optimized scanning was applied *only* to indirect block based inodes so that commit appears as a performance regression to some users. Just use optimized scanning whenever it is enabled by mount options. Reviewed-by: Baokun Li Reviewed-by: Zhang Yi Signed-off-by: Jan Kara Cc: stable@kernel.org Link: https://patch.msgid.link/20260114182836.14120-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 61e372122b6d95aec940fdaea0a16f988f359897 Author: Brian Foster Date: Tue Jan 13 12:19:05 2026 -0500 ext4: fix dirtyclusters double decrement on fs shutdown commit 94a8cea54cd935c54fa2fba70354757c0fc245e3 upstream. fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure. Fixes: 0087d9fb3f29 ("ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc") Signed-off-by: Brian Foster Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260113171905.118284-1-bfoster@redhat.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit c05033cfc5c7699cd4df8d48cef94d01da755f24 Author: Yongjian Sun Date: Tue Jan 6 17:08:20 2026 +0800 ext4: fix e4b bitmap inconsistency reports commit bdc56a9c46b2a99c12313122b9352b619a2e719e upstream. A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. Signed-off-by: Yongjian Sun Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260106090820.836242-1-sunyongjian@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f4b1052246ca646bb17bfe0f53df2fdf9729b58 Author: Zilin Guan Date: Thu Dec 25 08:48:00 2025 +0000 ext4: fix memory leak in ext4_ext_shift_extents() commit ca81109d4a8f192dc1cbad4a1ee25246363c2833 upstream. In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly released. Fixes: a18ed359bdddc ("ext4: always check ext4_ext_find_extent result") Signed-off-by: Zilin Guan Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Link: https://patch.msgid.link/20251225084800.905701-1-zilin@seu.edu.cn Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 120c6bd7ca9d3e80a968b758cbb3fbd67570f132 Author: Zhang Yi Date: Sat Nov 29 18:32:39 2025 +0800 ext4: drop extent cache when splitting extent fails commit 79b592e8f1b435796cbc2722190368e3e8ffd7a1 upstream. When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-8-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d8ee559fccdef713f058cfe5f2c03dc9b18be3b1 Author: Zhang Yi Date: Sat Nov 29 18:32:38 2025 +0800 ext4: drop extent cache after doing PARTIAL_VALID1 zeroout commit 6d882ea3b0931b43530d44149b79fcd4ffc13030 upstream. When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Cc: stable@kernel.org Reviewed-by: Ojaswin Mujoo Message-ID: <20251129103247.686136-7-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 96007fd3c106aea773c1afae2d6f64cceb6da208 Author: Zhang Yi Date: Sat Nov 29 18:32:37 2025 +0800 ext4: don't cache extent during splitting extent commit 8b4b19a2f96348d70bfa306ef7d4a13b0bcbea79 upstream. Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-6-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d17857b4fb9ba5745b59be0ef38fd532991fccbf Author: Zhang Yi Date: Sat Nov 29 18:32:34 2025 +0800 ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 commit 1bf6974822d1dba86cf11b5f05498581cf3488a2 upstream. When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-3-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c83f083940566359df9179a8d2d2d9760ce831f2 Author: Zhang Yi Date: Sat Nov 29 18:32:33 2025 +0800 ext4: subdivide EXT4_EXT_DATA_VALID1 commit 22784ca541c0f01c5ebad14e8228298dc0a390ed upstream. When splitting an extent, if the EXT4_GET_BLOCKS_CONVERT flag is set and it is necessary to split the target extent in the middle, ext4_split_extent() first handles splitting the latter half of the extent and passes the EXT4_EXT_DATA_VALID1 flag. This flag implies that all blocks before the split point contain valid data; however, this assumption is incorrect. Therefore, subdivid EXT4_EXT_DATA_VALID1 into EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_DATA_PARTIAL_VALID1, which indicate that the first half of the extent is either entirely valid or only partially valid, respectively. These two flags cannot be set simultaneously. This patch does not use EXT4_EXT_DATA_PARTIAL_VALID1, it only replaces EXT4_EXT_DATA_VALID1 with EXT4_EXT_DATA_ENTIRE_VALID1 at the location where it is set, no logical changes. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-2-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e3a6498a63394218561065a9a7a597a204f52f6a Author: Yao Zi Date: Thu Feb 5 15:56:44 2026 +0000 MIPS: Work around LLVM bug when gp is used as global register variable commit 30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3 upstream. On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [] init_idle+0x130/0x270 [ 0.000000] [] sched_init+0x5c8/0x6c0 [ 0.000000] [] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available. Cc: stable@vger.kernel.org Link: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Global-Register-Variables.html # [1] Link: https://github.com/llvm/llvm-project/issues/176546 # [2] Signed-off-by: Yao Zi Acked-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 6038e092508f3d5608aa1ae6bdfdd15a7724b2c6 Author: Mario Kleiner Date: Fri Feb 6 23:38:28 2026 +0100 drm/amd/display: Use same max plane scaling limits for all 64 bpp formats [ Upstream commit f0157ce46cf0e5e2257e19d590c9b16036ce26d4 ] The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner Tested-by: Mario Kleiner Cc: Alex Deucher Cc: Harry Wentland Cc: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6610bc8fe92742305217dbca1f30ab508833df97 Author: Detlev Casanova Date: Wed Feb 18 15:18:34 2026 -0500 ASoC: rockchip: i2s-tdm: Use param rate if not provided by set_sysclk [ Upstream commit 0783052534f547f8f201dd4554b1df9f1f8615b5 ] Drivers will not always call set_sysclk() for all clocks, especially when default mclk-fs can be used. When that is the case, use the clock rate set in the params multiplied by the default mclk-fs. Fixes: 5323186e2e8d ("ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback") Signed-off-by: Detlev Casanova Reported-by: Luca Ceresoli Link: https://patch.msgid.link/20260218201834.924358-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b5f50519bf20ee9b94eba7d6623d67bd7e7418c3 Author: Ethan Tidmore Date: Wed Feb 18 13:09:03 2026 -0600 x86/hyperv: Fix error pointer dereference [ Upstream commit 705d01c8d78121ee1634bfc602ac4b0ad1438fab ] The function idle_thread_get() can return an error pointer and is not checked for it. Add check for error pointer. Detected by Smatch: arch/x86/hyperv/hv_vtl.c:126 hv_vtl_bringup_vcpu() error: 'idle' dereferencing possible ERR_PTR() Fixes: 2b4b90e053a29 ("x86/hyperv: Use per cpu initial stack for vtl context") Signed-off-by: Ethan Tidmore Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 0761447f6f51e1c7997960d8e6559337deed6729 Author: Filipe Manana Date: Wed Feb 4 17:15:53 2026 +0000 btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found [ Upstream commit ecb7c2484cfc83a93658907580035a8adf1e0a92 ] If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid path. Fixes: 5223cc60b40a ("btrfs: drop the path before adding qgroup items when enabling qgroups") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 74a52716ec24751ee326a67527b588f730caf35d Author: Filipe Manana Date: Tue Feb 3 18:03:35 2026 +0000 btrfs: use the correct type to initialize block reserve for delayed refs [ Upstream commit 2155d0c0a761a56ce7ede83a26eb23ea0f935260 ] When initializing the delayed refs block reserve for a transaction handle we are passing a type of BTRFS_BLOCK_RSV_DELOPS, which is meant for delayed items and not for delayed refs. The correct type for delayed refs is BTRFS_BLOCK_RSV_DELREFS. On release of any excess space reserved in a local delayed refs reserve, we also should transfer that excess space to the global block reserve (it it's full, we return to the space info for general availability). By initializing a transaction's local delayed refs block reserve with a type of BTRFS_BLOCK_RSV_DELOPS, we were also causing any excess space released from the delayed block reserve (fs_info->delayed_block_rsv, used for delayed inodes and items) to be transferred to the global block reserve instead of the global delayed refs block reserve. This was an unintentional change in commit 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction"), but it's not particularly serious as things tend to cancel out each other most of the time and it's relatively rare to be anywhere near exhaustion of the global reserve. Fix this by initializing a transaction's local delayed refs reserve with a type of BTRFS_BLOCK_RSV_DELREFS and making btrfs_block_rsv_release() attempt to transfer unused space from such a reserve into the global block reserve, just as we did before that commit for when the block reserve is a delayed refs rsv. Reported-by: Alex Lyakas Link: https://lore.kernel.org/linux-btrfs/CAOcd+r0FHG5LWzTSu=LknwSoqxfw+C00gFAW7fuX71+Z5AfEew@mail.gmail.com/ Fixes: 28270e25c69a ("btrfs: always reserve space for delayed refs when starting transaction") Reviewed-by: Alex Lyakas Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ba6b6f1502fa55621d1db23f253d54322bdbe4e0 Author: Kiryl Shutsemau (Meta) Date: Tue Feb 17 10:49:56 2026 +0000 efi: Fix reservation of unaccepted memory table [ Upstream commit 0862438c90487e79822d5647f854977d50381505 ] The reserve_unaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned. If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in accept_memory(). This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB). Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation. Fixes: 8dbe33956d96 ("efi/unaccepted: Make sure unaccepted table is mapped") Reported-by: Moritz Sanft Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Tom Lendacky Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit bc78bfd287f3bf3d66effde0ffb027c9ed19bf43 Author: Matt Roper Date: Thu Feb 5 14:05:09 2026 -0800 drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138 [ Upstream commit bc6387a2e0c1562faa56ce2a98cef50cab809e08 ] The PSS_CHICKEN register has been part of the RCS engine's LRC since it was first introduced in Xe_LP. That means that any workarounds that adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be implemented in the lrc_was[] table so that they become part of the default LRC from which all subsequent LRCs are copied. Although these workarounds were implemented correctly on most platforms, they were incorrectly placed on the engine_was[] table for Xe2_HPG. Move the workarounds to the proper lrc_was[] table and switch the 'xe_rtp_match_first_render_or_compute' rule to specifically match the RCS since that's the engine whose LRC manages the register. Bspec: 65182 Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Shekhar Chauhan Link: https://patch.msgid.link/20260205220508.51905-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit e04c609eedf4d6748ac0bcada4de1275b034fed6) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c89bde96e8dd9d0d9aa83ccd4de91ada2de7efd9 Author: Shekhar Chauhan Date: Fri Jun 6 00:38:03 2025 +0530 drm/xe/xe2_hpg: Add set of workarounds [ Upstream commit a5d221924e13a22c83b682410dcf72422d1c68db ] Add set of workarounds for xe2_hpg. -v2: Fix xe2_hpg GMD version for some workarounds. -v3: Removed extra Workaround (Matt Roper) Signed-off-by: Shekhar Chauhan Signed-off-by: Dnyaneshwar Bhadane Reviewed-by: Matt Roper Signed-off-by: Matt Roper Link: https://lore.kernel.org/r/20250605190804.1287289-3-dnyaneshwar.bhadane@intel.com Stable-dep-of: bc6387a2e0c1 ("drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138") Signed-off-by: Sasha Levin commit 9e18acc5aa0e6f25e0eceeaf5fceaf95ec1f2760 Author: Vinay Belgaumkar Date: Thu Jan 16 10:46:59 2025 -0800 drm/xe/ptl: Apply Wa_13011645652 [ Upstream commit dddc53806dd2a10e210d5ea08caec6d3f92440b2 ] Extend Wa_13011645652 to PTL. Signed-off-by: Vinay Belgaumkar Reviewed-by: Stuart Summers Signed-off-by: Daniele Ceraolo Spurio Link: https://patchwork.freedesktop.org/patch/msgid/20250116184659.384874-1-vinay.belgaumkar@intel.com Stable-dep-of: bc6387a2e0c1 ("drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138") Signed-off-by: Sasha Levin commit 8f6848b2f6eadd903d29572ba0a684eda1e2f4ef Author: Shuicheng Lin Date: Fri Jan 30 16:56:22 2026 +0000 drm/xe/mmio: Avoid double-adjust in 64-bit reads [ Upstream commit 4a9b4e1fa52a6aaa1adbb7f759048df14afed54c ] xe_mmio_read64_2x32() was adjusting register addresses and then calling xe_mmio_read32(), which applies the adjustment again. This may shift accesses twice if adj_offset < adj_limit. There is no issue currently, as for media gt, adj_offset > adj_limit, so the 2nd adjust will be a no-op. But it may not work in future. To fix it, replace the adjusted-address comparison with a direct sanity check that ensures the MMIO address adjustment cutoff never falls within the 8-byte range of a 64-bit register. And let xe_mmio_read32() handle address translation. v2: rewrite the sanity check in a more natural way. (Matt) v3: Add Fixes tag. (Jani) Fixes: 07431945d8ae ("drm/xe: Avoid 64-bit register reads") Reviewed-by: Matt Roper Cc: Jani Nikula Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260130165621.471408-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit a30f999681126b128a43137793ac84b6a5b7443f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 26a40327c25c005c1653d66e7b1d8de0fbee15a4 Author: Matt Roper Date: Tue Sep 10 16:47:29 2024 -0700 drm/xe: Switch MMIO interface to take xe_mmio instead of xe_gt [ Upstream commit a84590c5ceb354d2e9f7f6812cfb3a9709e14afa ] Since much of the MMIO register access done by the driver is to non-GT registers, use of 'xe_gt' in these interfaces has been a long-standing design flaw that's been hard to disentangle. To avoid a flag day across the whole driver, munge the function names and add temporary compatibility macros with the original function names that can accept either the new xe_mmio or the old xe_gt structure as a parameter. This will allow us to slowly convert parts of the driver over to the new interface independently. Signed-off-by: Matt Roper Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-54-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit f5508f1e656c649fcff3dc1020451d53226cde49 Author: Matt Roper Date: Tue Sep 10 16:47:28 2024 -0700 drm/xe: Adjust mmio code to pass VF substructure to SRIOV code [ Upstream commit 6fb5d1a1d376910700d054d13cefbf0812b444a9 ] Although we want to break the GT-centric nature of the MMIO code in the general driver, the SRIOV handling still relies on data in a VF substructure of the GT. So add a GT backpointer, but name it sriov_vf_gt to make it clear that it's only for this one specific special case and will not be set or usable for anything else. v2: - Store backpointer to the GT itself rather than the SRIOV-specific substructure. (Michal) Cc: Michal Wajdeczko Reviewed-by: Lucas De Marchi # v1 Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-53-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 9472d36b3de9f49665ff533375cf55ba7b8c93aa Author: Matt Roper Date: Tue Sep 10 16:47:27 2024 -0700 drm/xe: Add xe_tile backpointer to xe_mmio [ Upstream commit 1877c88fa9b9bdbce7a65d7cbd2aa4e29bb514af ] Once MMIO operations stop being (incorrectly) tied to a GT, we'll still need a backpointer for feature checks, message logging, and tracepoints. Use a tile backpointer since that may allow the most useful debugging output, while also providing access to the xe_device. v2: - Make backpointer an xe_tile instead of xe_device. (Michal) Cc: Michal Wajdeczko Reviewed-by: Lucas De Marchi # v1 Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-52-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 74bff541ec88bb984084787d12a293a98d0be9ad Author: Matt Roper Date: Tue Sep 10 16:47:26 2024 -0700 drm/xe: Switch mmio_ext to use 'struct xe_mmio' [ Upstream commit 960a83799f5bb8634755f0593c591c53ff4acee8 ] The mmio_ext stuff is completely unused right now, but it isn't providing any functionality that couldn't be treated as a regular mmio space. Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-51-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 0b433e086b9f70c2065f5f50bba47d72f8400a14 Author: Matt Roper Date: Tue Sep 10 16:47:25 2024 -0700 drm/xe: Populate GT's mmio iomap from tile during init [ Upstream commit fa599b8c95a7070430703f4908a50141f2c7088c ] Each GT should share the same register iomap as its parent tile. Future patches will switch to access the iomap through the GT's mmio substruct rather than through the tile. Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-50-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 85354b21a548f8473e4fac29321e41b1d6da586c Author: Matt Roper Date: Tue Sep 10 16:47:24 2024 -0700 drm/xe: Move GSI offset adjustment fields into 'struct xe_mmio' [ Upstream commit 9d383916a552784ec35e6d25469fc2da9bcd9948 ] By moving the GSI adjustment fields into 'struct xe_mmio' we can replace the GT's MMIO substructure with another instance of xe_mmio. At the moment this means MMIO operations wind up pulling information from two different places (the tile's xe_mmio for the iomap and the GT's xe_mmio for the adjustment), but we'll address that in future patches. The type headers change a bit with this change, meaning that various files should be including xe_device_types.h instead of (or in addition to) xe_gt_types.h. v2: - Fix pre-existing kerneldoc typo while moving the fields (Lucas) v3: - Add missing '@' in kerneldoc. (Rodrigo) Cc: Rodrigo Vivi Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-49-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit c31019bca81534d6602a95f4115110a0b93264c1 Author: Matt Roper Date: Tue Sep 10 16:47:23 2024 -0700 drm/xe: Clarify size of MMIO region [ Upstream commit d4aff99aefa2a3c8999a98f0d52a977b284b9ec9 ] xe_mmio currently has a size parameter that is assigned but never used anywhere. The current values assigned appear to be the size of the BAR region assigned for the tile (both for registers and other purposes such as the GGTT). Since the current field isn't being used for anything, change the assignments to 4MB (the size of the register region on all current platform) and rename the field to 'regs_size' to more clearly describe what it represents. We can use this value in later patches to help ensure no register accesses accidentally go past the end of the desired register space (which might not be caught easily if they still fall within the iomap). v2: - s/regs_length/regs_size/ (Lucas) - Clarify kerneldoc description (Lucas) Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-48-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 6c5894d7acdb119335e79c27309734d875d3e1a6 Author: Matt Roper Date: Tue Sep 10 16:47:22 2024 -0700 drm/xe: Create dedicated xe_mmio structure [ Upstream commit 34953ee349dde9d1733d4af75e929f7fd5fab539 ] Pull the 'mmio' substructure from xe_tile out into a dedicated type. Future patches will expand this structure and then eventually move MMIO read/write operations over to using this type. v2: - Fix kerneldoc of 'size' field. The rename/refocusing of this field got moved to the next patch of the series. (Lucas) - Correct commit message; it's the tile, not the device, mmio that's been pulled out to a separate type. (Michal) Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-47-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit 4d4e940bc00b55aeae0869c5e4e5972d619b50c0 Author: Matt Roper Date: Tue Sep 10 16:47:21 2024 -0700 drm/xe: Move forcewake to 'gt.pm' substructure [ Upstream commit 998fde0647671c82f637e299026d951f9b155b37 ] Forcewake is a general GT power management concept that isn't specific to MMIO register access. Move the forcewake information for a GT out of the 'mmio' substruct and into a 'pm' substruct. Also use the gt_to_fw() helper in a few more places where it was being open-coded. v2: - Kerneldoc tweaks. (Lucas) Reviewed-by: Lucas De Marchi Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20240910234719.3335472-46-matthew.d.roper@intel.com Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads") Signed-off-by: Sasha Levin commit acb70e2949d4b9f895eb57bed8568ff1b11515a2 Author: Alexander Egorenkov Date: Mon Feb 16 07:29:16 2026 +0100 s390/kexec: Make KEXEC_SIG available when CONFIG_MODULES=n [ Upstream commit dd3411959b57df6e05a3ccbac67b0a836871c0c4 ] The commit c8424e776b09 ("MODSIGN: Export module signature definitions") replaced the dependency of KEXEC_SIG on SYSTEM_DATA_VERIFICATION with the dependency on MODULE_SIG_FORMAT. This change disables KEXEC_SIG in s390 kernels built with MODULES=n if nothing else selects MODULE_SIG_FORMAT. Furthermore, the signature verification in s390 kexec does not require MODULE_SIG_FORMAT because it requires only the struct module_signature and, therefore, does not depend on code in kernel/module_signature.c. But making ARCH_SUPPORTS_KEXEC_SIG depend on SYSTEM_DATA_VERIFICATION is also incorrect because it makes KEXEC_SIG available on s390 only if some other arbitrary option (for instance a file system or device driver) selects it directly or indirectly. To properly make KEXEC_SIG available for s390 kernels built with MODULES=y as well as MODULES=n _and_ also not depend on arbitrary options selecting SYSTEM_DATA_VERIFICATION, set ARCH_SUPPORTS_KEXEC_SIG=y for s390 and select SYSTEM_DATA_VERIFICATION when KEXEC_SIG=y. Fixes: c8424e776b09 ("MODSIGN: Export module signature definitions") Suggested-by: Heiko Carstens Signed-off-by: Alexander Egorenkov Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 2c538a0b3472e99c892c26f4940da38b7d87f632 Author: Felix Gu Date: Thu Feb 12 20:41:40 2026 +0800 spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe() [ Upstream commit 888a0a802c467bbe34a42167bdf9d7331333440a ] platform_get_resource_byname() can return NULL, which would cause a crash when passed the pointer to resource_size(). Move the fiu->memory_size assignment after the error check for devm_ioremap_resource() to prevent the potential NULL pointer dereference. Fixes: 9838c182471e ("spi: wpcm-fiu: Add direct map support") Signed-off-by: Felix Gu Reviewed-by: J. Neuschäfer Link: https://patch.msgid.link/20260212-wpcm-v1-1-5b7c4f526aac@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29f3824b08a98d41ecbbfd33580630d7607f962e Author: Srinivasan Shanmugam Date: Fri Feb 6 20:49:23 2026 +0530 drm/amd/display: Fix out-of-bounds stream encoder index v3 [ Upstream commit abde491143e4e12eecc41337910aace4e8d59603 ] eng_id can be negative and that stream_enc_regs[] can be indexed out of bounds. eng_id is used directly as an index into stream_enc_regs[], which has only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can access memory past the end of the array. Add a bounds check using ARRAY_SIZE() before using eng_id as an index. The unsigned cast also rejects negative values. This avoids out-of-bounds access. Fixes the below smatch error: dcn*_resource.c: stream_encoder_create() may index stream_enc_regs[eng_id] out of bounds (size 5). drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c 1246 static struct stream_encoder *dcn35_stream_encoder_create( 1247 enum engine_id eng_id, 1248 struct dc_context *ctx) 1249 { ... 1255 1256 /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */ 1257 if (eng_id <= ENGINE_ID_DIGF) { ENGINE_ID_DIGF is 5. should <= be dc_bios, 1283 eng_id, vpg, afmt, --> 1284 &stream_enc_regs[eng_id], ^^^^^^^^^^^^^^^^^^^^^^^ This stream_enc_regs[] array has 5 elements so we are one element beyond the end of the array. ... 1287 return &enc1->base; 1288 } v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman) Fixes: 2728e9c7c842 ("drm/amd/display: add DC changes for DCN351") Reported-by: Dan Carpenter Cc: Harry Wentland Cc: Mario Limonciello Cc: Alex Hung Cc: Aurabindo Pillai Cc: ChiaHsuan Chung Cc: Roman Li Signed-off-by: Srinivasan Shanmugam Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c4e4df8ea6428973e14b9ea275e28de26cc639c2 Author: Timur Kristóf Date: Sun Jan 18 15:57:41 2026 +0100 drm/amd/display: Reject cursor plane on DCE when scaled differently than primary [ Upstream commit 41af6215cdbcecd12920f211239479027904abf3 ] Currently DCE doesn't support the overlay cursor, so the dm_crtc_get_cursor_mode() function returns DM_CURSOR_NATIVE_MODE unconditionally. The outcome is that it doesn't check for the conditions that would necessitate the overlay cursor, meaning that it doesn't reject cases where the native cursor mode isn't supported on DCE. Remove the early return from dm_crtc_get_cursor_mode() for DCE and instead let it perform the necessary checks and return DM_CURSOR_OVERLAY_MODE. Add a later check that rejects when DM_CURSOR_OVERLAY_MODE would be used with DCE. Fixes: 1b04dcca4fb1 ("drm/amd/display: Introduce overlay cursor mode") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4600 Suggested-by: Leo Li Signed-off-by: Timur Kristóf Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a0d367e13db63a6ed76ee0d0a8c3a58c1fa98488 Author: Srinivasan Shanmugam Date: Fri Feb 6 21:18:11 2026 +0530 drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 [ Upstream commit 5a19302cab5cec7ae7f1a60c619951e6c17d8742 ] The address watch clear code receives watch_id as an unsigned value (u32), but some helper functions were using a signed int and checked bits by shifting with watch_id. If a very large watch_id is passed from userspace, it can be converted to a negative value. This can cause invalid shifts and may access memory outside the watch_points array. drm/amdkfd: Fix watch_id bounds checking in debug address watch v2 Fix this by checking that watch_id is within MAX_WATCH_ADDRESSES before using it. Also use BIT(watch_id) to test and clear bits safely. This keeps the behavior unchanged for valid watch IDs and avoids undefined behavior for invalid ones. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c:448 kfd_dbg_trap_clear_dev_address_watch() error: buffer overflow 'pdd->watch_points' 4 <= u32max user_rl='0-3,2147483648-u32max' uncapped drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_debug.c 433 int kfd_dbg_trap_clear_dev_address_watch(struct kfd_process_device *pdd, 434 uint32_t watch_id) 435 { 436 int r; 437 438 if (!kfd_dbg_owns_dev_watch_id(pdd, watch_id)) kfd_dbg_owns_dev_watch_id() doesn't check for negative values so if watch_id is larger than INT_MAX it leads to a buffer overflow. (Negative shifts are undefined). 439 return -EINVAL; 440 441 if (!pdd->dev->kfd->shared_resources.enable_mes) { 442 r = debug_lock_and_unmap(pdd->dev->dqm); 443 if (r) 444 return r; 445 } 446 447 amdgpu_gfx_off_ctrl(pdd->dev->adev, false); --> 448 pdd->watch_points[watch_id] = pdd->dev->kfd2kgd->clear_address_watch( 449 pdd->dev->adev, 450 watch_id); v2: (as per, Jonathan Kim) - Add early watch_id >= MAX_WATCH_ADDRESSES validation in the set path to match the clear path. - Drop the redundant bounds check in kfd_dbg_owns_dev_watch_id(). Fixes: e0f85f4690d0 ("drm/amdkfd: add debug set and clear address watch points operation") Reported-by: Dan Carpenter Cc: Jonathan Kim Cc: Felix Kuehling Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Jonathan Kim Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 288311849f8e10bbbe69a4faeaba8697894ef634 Author: Alexandre Ferrieux Date: Wed Feb 11 11:27:32 2026 +0100 ASoC: codecs: aw88261: Fix erroneous bitmask logic in Awinic init [ Upstream commit b82fa9b0c26eeb2fde6017f7de2c3c544484efef ] The aw88261_dev_reg_update() function sets the Awinic registers in a rather nonuniform way: - most registers get directly overwritten from the firmware blob - but a handful of them need more delicate logic to preserve some bits from their current value, according to a register- specific mask For the latter, the logic is basically NEW = (OLD & MASK) | (VAL & ~MASK) However, the ~MASK value is hand-computed, and in the specific case of the SYSCTRL register, in a buggy way. This patch restores the proper ~MASK value. Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver") Signed-off-by: Alexandre Ferrieux Link: https://patch.msgid.link/20260211-aw88261-fwname-v1-1-e24e833a019d@fairphone.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 42dbd7cadc2c639e6b6f98090d3d30f7ec20ccfa Author: Kaushlendra Kumar Date: Fri Jan 9 08:55:49 2026 +0530 drm/i915/acpi: free _DSM package when no connectors [ Upstream commit 57b85fd53fccfdf14ce7b36d919c31aa752255f8 ] acpi_evaluate_dsm_typed() returns an ACPI package in pkg. When pkg->package.count == 0, we returned without freeing pkg, leaking memory. Free pkg before returning on the empty case. Signed-off-by: Kaushlendra Kumar Fixes: 337d7a1621c7 ("drm/i915: Fix invalid access to ACPI _DSM objects") Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260109032549.1826303-1-kaushlendra.kumar@intel.com Signed-off-by: Jani Nikula (cherry picked from commit c0a27a0ca8a34e96d08bb05a2c5d5ccf63fb8dc0) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit b0f74f5d24fe3c73ef1369a811891198b54c1e8e Author: Ziyi Guo Date: Tue Feb 10 18:57:14 2026 +0000 ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put() [ Upstream commit 9f16d96e1222391a6b996a1b676bec14fb91e3b2 ] This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()"). The original patch attempted to acquire the card->controls_rwsem lock in fsl_xcvr_mode_put(). However, this function is called from the upper ALSA core function snd_ctl_elem_write(), which already holds the write lock on controls_rwsem for the whole put operation. So there is no need to simply hold the lock for fsl_xcvr_activate_ctl() again. Acquiring the read lock while holding the write lock in the same thread results in a deadlock and a hung task, as reported by Alexander Stein. Fixes: f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()") Reported-by: Alexander Stein Closes: https://lore.kernel.org/linux-sound/5056506.GXAFRqVoOG@steina-w/ Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260210185714.556385-1-n7l8m4@u.northwestern.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c11cd77a18115d2cd3f4b6915c4a537b6042f950 Author: Zilin Guan Date: Thu Jan 29 08:35:15 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_ras_init() [ Upstream commit ee41e5b63c8210525c936ee637a2c8d185ce873c ] When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function returns directly without freeing the allocated con structure, leading to a memory leak. Fix this by jumping to the release_con label to properly clean up the allocated memory before returning the error code. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fdc94d3a8c88 ("drm/amdgpu: Rework pcie_bif ras sw_init") Reviewed-by: Tao Zhou Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 16e7e7ad8cdc6b4c4af7f31e262f1494c1b2a55e Author: Zilin Guan Date: Thu Jan 29 09:05:42 2026 +0000 drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges() [ Upstream commit 0c44d61945c4a80775292d96460aa2f22e62f86c ] amdgpu_discovery_get_nps_info() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption. Use kvfree() to safely handle both kmalloc and vmalloc allocations. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: b194d21b9bcc ("drm/amdgpu: Use NPS ranges from discovery table") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 18a7bbd11f17a7cd4c42fd5955d3675d68c692df Author: Zilin Guan Date: Thu Jan 29 09:25:32 2026 +0000 drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc() [ Upstream commit c9be63d565789b56ca7b0197e2cb78a3671f95a8 ] In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak. Fix this by ensuring that xcc_info is properly freed in the error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 4d5275ab0b18 ("drm/amdgpu: Add parsing of acpi xcc objects") Reviewed-by: Lijo Lazar Signed-off-by: Zilin Guan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3f2d2cbe8e22b5f02b542cc880833042ca435f14 Author: John Johansen Date: Mon Feb 2 04:12:02 2026 -0800 apparmor: fix aa_label to return state from compount and component match [ Upstream commit 9058798652c8bc0584ed1fb0766a1015046c06e8 ] aa-label_match is not correctly returning the state in all cases. The only reason this didn't cause a error is that all callers currently ignore the return value. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602020631.wXgZosyU-lkp@intel.com/ Fixes: a4c9efa4dbad6 ("apparmor: make label_match return a consistent value") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 19f2e4055626a58842ddec3282ad4465a80c6625 Author: Georgia Garcia Date: Thu Jan 29 15:58:45 2026 -0300 apparmor: fix invalid deref of rawdata when export_binary is unset [ Upstream commit df9ac55abd18628bd8cff687ea043660532a3654 ] If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 1180b4c757aab ("apparmor: fix dangling symlinks to policy rawdata after replacement") Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 202824a1f89a9786c20a3d646a7c88d223abb1b2 Author: Zhengmian Hu Date: Mon Jan 19 19:03:07 2026 -0500 apparmor: avoid per-cpu hold underflow in aa_get_buffer [ Upstream commit 640cf2f09575c9dc344b3f7be2498d31e3923ead ] When aa_get_buffer() pulls from the per-cpu list it unconditionally decrements cache->hold. If hold reaches 0 while count is still non-zero, the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a very long time, so aa_put_buffer() never returns buffers to the global list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max) allocations. Guard the decrement so hold never underflows. Fixes: ea9bae12d028 ("apparmor: cache buffers on percpu list if there is lock contention") Signed-off-by: Zhengmian Hu Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 6c7e329629a4ea081fbfc227ac4bdc933b634cf6 Author: John Johansen Date: Thu Nov 13 23:59:38 2025 -0800 apparmor: make label_match return a consistent value [ Upstream commit a4c9efa4dbad6dacad6e8b274e30e814c8353097 ] compound match is inconsistent in returning a state or an integer error this is problemati if the error is ever used as a state in the state machine Fixes: f1bd904175e81 ("apparmor: add the base fns() for domain labels") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit d5eb32cf3e141c42f079d70bad31bd71e5db7b57 Author: John Johansen Date: Fri Nov 14 00:14:36 2025 -0800 apparmor: remove apply_modes_to_perms from label_match [ Upstream commit b2e27be2948f2f8c38421cd554b5fc9383215648 ] The modes shouldn't be applied at the point of label match, it just results in them being applied multiple times. Instead they should be applied after which is already being done by all callers so it can just be dropped from label_match. Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Stable-dep-of: a4c9efa4dbad ("apparmor: make label_match return a consistent value") Signed-off-by: Sasha Levin commit e43818b16815c0c2bf933ef28316f8e704e5e0ef Author: John Johansen Date: Sun Nov 9 14:16:54 2025 -0800 apparmor: fix rlimit for posix cpu timers [ Upstream commit 6ca56813f4a589f536adceb42882855d91fb1125 ] Posix cpu timers requires an additional step beyond setting the rlimit. Refactor the code so its clear when what code is setting the limit and conditionally update the posix cpu timers when appropriate. Fixes: baa73d9e478ff ("posix-timers: Make them configurable") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit bd7df71b91d91b0b3e7b9e4029f6ac0af589277e Author: Ryan Lee Date: Tue Jan 13 09:35:57 2026 -0800 apparmor: return -ENOMEM in unpack_perms_table upon alloc failure [ Upstream commit 74b7105e53e80a4072bd3e1a50be7aa15e3f0a01 ] In policy_unpack.c:unpack_perms_table, the perms struct is allocated via kcalloc, with the position being reset if the allocation fails. However, the error path results in -EPROTO being retured instead of -ENOMEM. Fix this to return the correct error code. Reported-by: Zygmunt Krynicki Fixes: fd1b2b95a2117 ("apparmor: add the ability for policy to specify a permission table") Reviewed-by: Tyler Hicks Signed-off-by: Ryan Lee Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 47e351dfef60ab0e3285133556e1a9c7f646a969 Author: Helge Deller Date: Wed Nov 26 21:15:04 2025 +0100 apparmor: Fix & Optimize table creation from possibly unaligned memory [ Upstream commit 6fc367bfd4c8886e6b1742aabbd1c0bdc310db3a ] Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit ec737e7fdf2f0ba7b203d4ec72cc915978b10e7e Author: Helge Deller Date: Tue Nov 25 16:11:07 2025 +0100 AppArmor: Allow apparmor to handle unaligned dfa tables [ Upstream commit 64802f731214a51dfe3c6c27636b3ddafd003eb0 ] The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 3852eb9a0392eb435c03dcb47d581bcfe6a9a95b Author: John Johansen Date: Mon Nov 24 15:07:42 2025 -0800 apparmor: fix NULL sock in aa_sock_file_perm [ Upstream commit 00b67657535dfea56e84d11492f5c0f61d0af297 ] Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered. Fixes: 56974a6fcfef6 ("apparmor: add base infastructure for socket mediation") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 77d2e4d03db670783af7dad18998a13892c4fa8d Author: Cosmin Ratiu Date: Wed Feb 18 09:29:04 2026 +0200 net/mlx5e: Use unsigned for mlx5e_get_max_num_channels [ Upstream commit 57a94d4b22b0c6cc5d601e6b6238d78fb923d991 ] The max number of channels is always an unsigned int, use the correct type to fix compilation errors done with strict type checking, e.g.: error: call to ‘__compiletime_assert_1110’ declared with attribute error: min(mlx5e_get_devlink_param_num_doorbells(mdev), mlx5e_get_max_num_channels(mdev)) signedness error Fixes: 74a8dadac17e ("net/mlx5e: Preparations for supporting larger number of channels") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 481a86e5a0e5484722d4ef01c437f3450949d951 Author: Shay Drory Date: Wed Feb 18 09:28:59 2026 +0200 net/mlx5: Fix multiport device check over light SFs [ Upstream commit 47bf2e813817159f4d195be83a9b5a640ee6baec ] Driver is using num_vhca_ports capability to distinguish between multiport master device and multiport slave device. num_vhca_ports is a capability the driver sets according to the MAX num_vhca_ports capability reported by FW. On the other hand, light SFs doesn't set the above capbility. This leads to wrong results whenever light SFs is checking whether he is a multiport master or slave. Therefore, use the MAX capability to distinguish between master and slave devices. Fixes: e71383fb9cd1 ("net/mlx5: Light probe local SFs") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260218072904.1764634-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c65cdf46ce340c9c00fbbaf84599d2daff43626e Author: Hangbin Liu Date: Wed Feb 18 06:09:19 2026 +0000 bonding: alb: fix UAF in rlb_arp_recv during bond up/down [ Upstream commit e6834a4c474697df23ab9948fd3577b26bf48656 ] The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ff788b84fa5f6f447289bea76563de2ea045922 Author: Hariprasad Kelam Date: Mon Feb 16 14:33:38 2026 +0530 octeontx2-af: Fix default entries mcam entry action [ Upstream commit 45be47bf5d7db0f762a93e9c0ede6cb3c91edf3b ] As per design, AF should update the default MCAM action only when mcam_index is -1. A bug in the previous patch caused default entries to be changed even when the request was not for them. Fixes: 570ba37898ec ("octeontx2-af: Update RSS algorithm index") Signed-off-by: Hariprasad Kelam Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260216090338.1318976-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c480680be3776263198f3ae117e6a1c68a7d60de Author: Eric Dumazet Date: Mon Feb 16 14:28:29 2026 +0000 inet: move icmp_global_{credit,stamp} to a separate cache line [ Upstream commit 87b08913a9ae82082e276d237ece08fc8ee24380 ] icmp_global_credit was meant to be changed ~1000 times per second, but if an admin sets net.ipv4.icmp_msgs_per_sec to a very high value, icmp_global_credit changes can inflict false sharing to surrounding fields that are read mostly. Move icmp_global_credit and icmp_global_stamp to a separate cacheline aligned group. Fixes: b056b4cd9178 ("icmp: move icmp_global.credit and icmp_global.stamp to per netns storage") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5aea79b91084d4ebdf0b0bb36c41b7b7ef0ae91e Author: Eric Dumazet Date: Mon Feb 16 14:28:28 2026 +0000 icmp: prevent possible overflow in icmp_global_allow() [ Upstream commit 034bbd806298e9ba4197dd1587b0348ee30996ea ] Following expression can overflow if sysctl_icmp_msgs_per_sec is big enough. sysctl_icmp_msgs_per_sec * delta / HZ; Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216142832.3834174-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a1f686d273d129b45712d95f4095843b864466bd Author: Eric Dumazet Date: Fri Feb 13 14:25:57 2026 +0000 macvlan: observe an RCU grace period in macvlan_common_newlink() error path [ Upstream commit e3f000f0dee1bfab52e2e61ca6a3835d9e187e35 ] valis reported that a race condition still happens after my prior patch. macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev). We must respect an RCU period, either in macvlan or the core networking stack. After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source (ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? tasklet_init (kernel/softirq.c:983) macvlan_handle_frame (drivers/net/macvlan.c:501) Allocated by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) alloc_netdev_mqs (net/core/dev.c:12012) rtnl_create_link (net/core/rtnetlink.c:3648) rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Freed by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Fixes: f8db6475a836 ("macvlan: fix error recovery in macvlan_common_newlink()") Signed-off-by: Eric Dumazet Reported-by: valis Link: https://patch.msgid.link/20260213142557.3059043-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ec0d56a84673bad2502905461ad57e6ef3e746f Author: Eric Dumazet Date: Mon Feb 16 10:01:49 2026 +0000 ping: annotate data-races in ping_lookup() [ Upstream commit ad5dfde2a5733aaf652ea3e40c8c5e071e935901 ] isk->inet_num, isk->inet_rcv_saddr and sk->sk_bound_dev_if are read locklessly in ping_lookup(). Add READ_ONCE()/WRITE_ONCE() annotations. The race on isk->inet_rcv_saddr is probably coming from IPv6 support, but does not deserve a specific backport. Fixes: dbca1596bbb0 ("ping: convert to RCU lookups, get rid of rwlock") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260216100149.3319315-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6ed7864a5c1af874482734d969e7e1a567b71e32 Author: Jakub Kicinski Date: Tue Feb 17 11:41:50 2026 -0800 bpftool: Fix truncated netlink dumps [ Upstream commit 3b39d73cc3379360a33eb583b17f21fe55e1288e ] Netlink requires that the recv buffer used during dumps is at least min(PAGE_SIZE, 8k) (see the man page). Otherwise the messages will get truncated. Make sure bpftool follows this requirement, avoid missing information on systems with large pages. Acked-by: Quentin Monnet Fixes: 7084566a236f ("tools/bpftool: Remove libbpf_internal.h usage in bpftool") Signed-off-by: Jakub Kicinski Link: https://lore.kernel.org/r/20260217194150.734701-1-kuba@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f26af58f794de0dc4f31cc91abec4080843e8d6b Author: Eric Dumazet Date: Mon Feb 16 10:22:02 2026 +0000 ipv6: fix a race in ip6_sock_set_v6only() [ Upstream commit 452a3eee22c57a5786ae6db5c97f3b0ec13bb3b7 ] It is unlikely that this function will be ever called with isk->inet_num being not zero. Perform the check on isk->inet_num inside the locked section for complete safety. Fixes: 9b115749acb24 ("ipv6: add ip6_sock_set_v6only") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260216102202.3343588-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3fe58ce37926a10115ede527d59b91bcc05400a Author: Inseo An Date: Tue Feb 17 21:14:40 2026 +0900 netfilter: nf_tables: fix use-after-free in nf_tables_addchain() [ Upstream commit 71e99ee20fc3f662555118cf1159443250647533 ] nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain") Signed-off-by: Inseo An Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 959ea349c7e2d4edf07b6838ca7e59345fe61a08 Author: Pablo Neira Ayuso Date: Tue Feb 17 12:56:39 2026 +0100 net: remove WARN_ON_ONCE when accessing forward path array [ Upstream commit 008e7a7c293b30bc43e4368dac6ea3808b75a572 ] Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARN_ON_ONCE if userspace manages to build a sufficiently long forward path. Remove it. Fixes: ddb94eafab8b ("net: resolve forwarding path from virtual netdevice and HW destination address") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 64af43033503458c46023e56d6ae7bb0f824b55f Author: Julian Anastasov Date: Sat Feb 14 16:58:50 2026 +0200 ipvs: do not keep dest_dst if dev is going down [ Upstream commit 8fde939b0206afc1d5846217a01a16b9bc8c7896 ] There is race between the netdev notifier ip_vs_dst_event() and the code that caches dst with dev that is going down. As the FIB can be notified for the closed device after our handler finishes, it is possible valid route to be returned and cached resuling in a leaked dev reference until the dest is not removed. To prevent new dest_dst to be attached to dest just after the handler dropped the old one, add a netif_running() check to make sure the notifier handler is not currently running for device that is closing. Fixes: 7a4f0761fce3 ("IPVS: init and cleanup restructuring") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 06676b8ea98fc12675a16d1b0d15b7bae83492c0 Author: Florian Westphal Date: Wed Feb 11 12:53:09 2026 +0100 netfilter: nf_conntrack_h323: don't pass uninitialised l3num value [ Upstream commit a6d28eb8efe96b3e35c92efdf1bfacb0cccf541f ] Mihail Milev reports: Error: UNINIT (CWE-457): net/netfilter/nf_conntrack_h323_main.c:1189:2: var_decl: Declaring variable "tuple" without initializer. net/netfilter/nf_conntrack_h323_main.c:1197:2: uninit_use_in_call: Using uninitialized value "tuple.src.l3num" when calling "__nf_ct_expect_find". net/netfilter/nf_conntrack_expect.c:142:2: read_value: Reading value "tuple->src.l3num" when calling "nf_ct_expect_dst_hash". 1195| tuple.dst.protonum = IPPROTO_TCP; 1196| 1197|-> exp = __nf_ct_expect_find(net, nf_ct_zone(ct), &tuple); 1198| if (exp && exp->master == ct) 1199| return exp; Switch this to a C99 initialiser and set the l3num value. Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bb7ce39f8864446cf2f53f47399ab326ac39fffc Author: Aleksei Oladko Date: Fri Feb 13 13:19:06 2026 +0000 selftests: forwarding: vxlan_bridge_1d_ipv6: fix test failure with br_netfilter enabled [ Upstream commit ce9f6aec0fb780dafc1dfc5f47c688422aff464a ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv6 packet has an incorrect payload length set in the IPv6 header. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by setting the correct IPv6 payload length for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. tools/testing/selftests/net/forwarding/vxlan_bridge_1d_ipv6.sh lines 698-706 )"00:03:"$( : Payload length )"3a:"$( : Next header )"04:"$( : Hop limit )"$saddr:"$( : IP saddr )"$daddr:"$( : IP daddr )"80:"$( : ICMPv6.type )"00:"$( : ICMPv6.code )"00:"$( : ICMPv6.checksum ) Data after IPv6 header: • 80: — 1 byte (ICMPv6 type) • 00: — 1 byte (ICMPv6 code) • 00: — 1 byte (ICMPv6 checksum, truncated) Total: 3 bytes → 00:03 is correct. The old value 00:08 did not match the actual payload size. Fixes: b07e9957f220 ("selftests: forwarding: Add VxLAN tests with a VLAN-unaware bridge for IPv6") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-3-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 48f3c88a8eaae8e881e426cdae05e976ff06e715 Author: Aleksei Oladko Date: Fri Feb 13 13:19:05 2026 +0000 selftests: forwarding: vxlan_bridge_1d: fix test failure with br_netfilter enabled [ Upstream commit 02cb2e6bacbb08ebf6acb61be816efd11e1f4a21 ] The test generates VXLAN traffic using mausezahn, where the encapsulated inner IPv4 packet contains a zero IP header checksum. After VXLAN decapsulation, such packets do not pass sanity checks in br_netfilter and are dropped, which causes the test to fail. Fix this by calculating and setting a valid IPv4 header checksum for the encapsulated packet generated by mausezahn, so that the packet is accepted by br_netfilter. Fixed by using the payload_template_calc_checksum() / payload_template_expand_checksum() helpers that are only available in v6.3 and newer kernels. Fixes: a0b61f3d8ebf ("selftests: forwarding: vxlan_bridge_1d: Add an ECN decap test") Signed-off-by: Aleksei Oladko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260213131907.43351-2-aleksey.oladko@virtuozzo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 724a405ce0309676f1e993c173382b4c4a022beb Author: Nikolay Aleksandrov Date: Fri Feb 13 09:00:30 2026 +0200 net: bridge: mcast: always update mdb_n_entries for vlan contexts [ Upstream commit 8b769e311a86bb9d15c5658ad283b86fc8f080a2 ] syzbot triggered a warning[1] about the number of mdb entries in a context. It turned out that there are multiple ways to trigger that warning today (some got added during the years), the root cause of the problem is that the increase is done conditionally, and over the years these different conditions increased so there were new ways to trigger the warning, that is to do a decrease which wasn't paired with a previous increase. For example one way to trigger it is with flush: $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1 $ ip l add dumdum up master br0 type dummy $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1 $ ip link set dev br0 down $ ip link set dev br0 type bridge mcast_vlan_snooping 1 ^^^^ this will enable snooping, but will not update mdb_n_entries because in __br_multicast_enable_port_ctx() we check !netif_running $ bridge mdb flush dev br0 ^^^ this will trigger the warning because it will delete the pg which we added above, which will try to decrease mdb_n_entries Fix the problem by removing the conditional increase and always keep the count up-to-date while the vlan exists. In order to do that we have to first initialize it on port-vlan context creation, and then always increase or decrease the value regardless of mcast options. To keep the current behaviour we have to enforce the mdb limit only if the context is port's or if the port-vlan's mcast snooping is enabled. [1] ------------[ cut here ]------------ n == 0 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043 WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043 Modules linked in: CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline] RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline] RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825 Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 <0f> 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b RSP: 0018:ffffc9000c207220 EFLAGS: 00010293 RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800 R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238 FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0 Call Trace: br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline] br_mdb_flush net/bridge/br_mdb.c:1544 [inline] br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561 rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1 rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa45839aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa45921b028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fa458615fa0 RCX: 00007fa45839aeb9 RDX: 0000000000000000 RSI: 00002000000000c0 RDI: 0000000000000004 RBP: 00007fa458408c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa458616038 R14: 00007fa458615fa0 R15: 00007fff0b59fae8 Fixes: b57e8d870d52 ("net: bridge: Maintain number of MDB entries in net_bridge_mcast_port") Reported-by: syzbot+d5d1b7343531d17bd3c5@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/aYrWbRp83MQR1ife@debil/T/#t Reviewed-by: Ido Schimmel Signed-off-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260213070031.1400003-2-nikolay@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ac30e78dd8de73395be34b3514d8e195961a5cd3 Author: Allison Henderson Date: Thu Feb 12 20:54:09 2026 -0700 net/rds: rds_sendmsg should not discard payload_len [ Upstream commit da29e453dcb3aa7cabead7915f5f945d0add3a52 ] Commit 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") modifies rds_sendmsg to avoid enqueueing work while a tear down is in progress. However, it also changed the return value of rds_sendmsg to that of rds_send_xmit instead of the payload_len. This means the user may incorrectly receive errno values when it should have simply received a payload of 0 while the peer attempts a reconnections. So this patch corrects the teardown handling code to only use the out error path in that case, thus restoring the original payload_len return value. Fixes: 3db6e0d172c9 ("rds: use RCU to synchronize work-enqueue with connection teardown") Reviewed-by: Simon Horman Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260213035409.1963391-1-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ec4859ac5c933e3315543a61adc1ca4358006a41 Author: Ziyi Guo Date: Thu Feb 12 22:40:40 2026 +0000 xen-netback: reject zero-queue configuration from guest [ Upstream commit 6d1dc8014334c7fb25719999bca84d811e60a559 ] A malicious or buggy Xen guest can write "0" to the xenbus key "multi-queue-num-queues". The connect() function in the backend only validates the upper bound (requested_num_queues > xenvif_max_queues) but not zero, allowing requested_num_queues=0 to reach vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers WARN_ON_ONCE(!size) in __vmalloc_node_range(). On systems with panic_on_warn=1, this allows a guest-to-host denial of service. The Xen network interface specification requires the queue count to be "greater than zero". Add a zero check to match the validation already present in xen-blkback, which has included this guard since its multi-queue support was added. Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues") Signed-off-by: Ziyi Guo Reviewed-by: Juergen Gross Link: https://patch.msgid.link/20260212224040.86674-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a488001a8197da4f9c413eec8f6acbff71c60145 Author: Ziyi Guo Date: Thu Feb 12 21:41:54 2026 +0000 net: usb: catc: enable basic endpoint checking [ Upstream commit 9e7021d2aeae57c323a6f722ed7915686cdcc123 ] catc_probe() fills three URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX - usb_rcvintpipe(usbdev, 2) for interrupt status A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a catc_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls after usb_set_interface() to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time. Similar to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") which fixed the issue in rtl8150. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Simon Horman Signed-off-by: Ziyi Guo Link: https://patch.msgid.link/20260212214154.3609844-1-n7l8m4@u.northwestern.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ae3cfa51471c49074357e06f0c514e8e7c04b17d Author: Daniel Machon Date: Thu Feb 12 12:02:30 2026 +0100 net: sparx5/lan969x: fix PTP clock max_adj value [ Upstream commit a49d2a2c37a6252c41cbdd505f9d1c58d5a3817a ] The max_adj field in ptp_clock_info tells userspace how much the PHC clock frequency can be adjusted. ptp4l reads this and will never request a correction larger than max_adj. On both sparx5 and lan969x the clock offset may never converge because the servo needs a frequency correction larger than the current max_adj of 200000 (200 ppm) allows. The servo rails at the max and the offset stays in the tens of microseconds. The hardware has no inherent max adjustment limit; frequency correction is done by writing a 64-bit clock period increment to CLK_PER_CFG, and the register has plenty of range. The 200000 value was just an overly conservative software limit. The max_adj is shared between sparx5 and lan969x, and the increased value is safe for both. Fix this by increasing max_adj to 10000000 (10000 ppm), giving the servo sufficient headroom. Fixes: 0933bd04047c ("net: sparx5: Add support for ptp clocks") Signed-off-by: Daniel Machon Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260212-sparx5-ptp-max-adj-v2-v1-1-06b200e50ce3@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf5009a06e03ee9a51052bb59f2228a5e4e66260 Author: Kuniyuki Iwashima Date: Wed Feb 11 17:50:21 2026 +0000 ipv6: Fix out-of-bound access in fib6_add_rt2node(). [ Upstream commit 8244f959e2c125c849e569f5b23ed49804cce695 ] syzbot reported out-of-bound read in fib6_add_rt2node(). [0] When IPv6 route is created with RTA_NH_ID, struct fib6_info does not have the trailing struct fib6_nh. The cited commit started to check !iter->fib6_nh->fib_nh_gw_family to ensure that rt6_qualify_for_ecmp() will return false for iter. If iter->nh is not NULL, rt6_qualify_for_ecmp() returns false anyway. Let's check iter->nh before reading iter->fib6_nh and avoid OOB read. [0]: BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 Read of size 1 at addr ffff8880384ba6de by task syz.0.18/5500 CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142 fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline] fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f9316b9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9 RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003 RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0 Allocated by task 5499: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820 ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949 inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: bbf4a17ad9ff ("ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF") Reported-by: syzbot+707d6a5da1ab9e0c6f9d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/698cbfba.050a0220.2eeac1.009d.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Shigeru Yoshida Link: https://patch.msgid.link/20260211175133.3657034-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ac58d8832802ec89baa7539e13e6d58a88cce04 Author: Ziyi Guo Date: Sun Feb 8 22:56:02 2026 +0000 net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj() [ Upstream commit 026f6513c5880c2c89e38ad66bbec2868f978605 ] ocelot_port_xmit_inj() calls ocelot_can_inject() and ocelot_port_inject_frame() without holding the injection group lock. Both functions contain lockdep_assert_held() for the injection lock, and the correct caller felix_port_deferred_xmit() properly acquires the lock using ocelot_lock_inj_grp() before calling these functions. Add ocelot_lock_inj_grp()/ocelot_unlock_inj_grp() around the register injection path to fix the missing lock protection. The FDMA path is not affected as it uses its own locking mechanism. Fixes: c5e12ac3beb0 ("net: mscc: ocelot: serialize access to the injection/extraction groups") Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-4-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6702700ad94c13f788872dc45262ef64d50f777f Author: Ziyi Guo Date: Sun Feb 8 22:56:01 2026 +0000 net: mscc: ocelot: split xmit into FDMA and register injection paths [ Upstream commit 47f79b20e7fb885aa1623b759a68e8e27401ec4d ] Split ocelot_port_xmit() into two separate functions: - ocelot_port_xmit_fdma(): handles the FDMA injection path - ocelot_port_xmit_inj(): handles the register-based injection path The top-level ocelot_port_xmit() now dispatches to the appropriate function based on the ocelot_fdma_enabled static key. This is a pure refactor with no behavioral change. Separating the two code paths makes each one simpler and prepares for adding proper locking to the register injection path without affecting the FDMA path. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-3-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit 1bbcb4e9c02c46214135775792fed546a76e5c7b Author: Ziyi Guo Date: Sun Feb 8 22:56:00 2026 +0000 net: mscc: ocelot: extract ocelot_xmit_timestamp() helper [ Upstream commit 29372f07f7969a2f0490793226ecf6c8c6bde0fa ] Extract the PTP timestamp handling logic from ocelot_port_xmit() into a separate ocelot_xmit_timestamp() helper function. This is a pure refactor with no behavioral change. The helper returns false if the skb was consumed (freed) due to a timestamp request failure, and true if the caller should continue with frame injection. The rew_op value is returned via pointer. This prepares for splitting ocelot_port_xmit() into separate FDMA and register injection paths in a subsequent patch. Signed-off-by: Ziyi Guo Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260208225602.1339325-2-n7l8m4@u.northwestern.edu Signed-off-by: Jakub Kicinski Stable-dep-of: 026f6513c588 ("net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()") Signed-off-by: Sasha Levin commit 9e1815472ae451cab1544589f7b4c5e534d9be78 Author: Daniel Machon Date: Tue Feb 10 14:44:01 2026 +0100 net: sparx5/lan969x: fix DWRR cost max to match hardware register width [ Upstream commit 6c28aa8dfdf24f554d4c5d4ff7d723a95360d94a ] DWRR (Deficit Weighted Round Robin) scheduling distributes bandwidth across traffic classes based on per-queue cost values, where lower cost means higher bandwidth share. The SPX5_DWRR_COST_MAX constant is 63 (6 bits) but the hardware register field HSCH_DWRR_ENTRY_DWRR_COST is GENMASK(24, 20), only 5 bits wide (max 31). This causes sparx5_weight_to_hw_cost() to compute cost values that silently overflow via FIELD_PREP, resulting in incorrect scheduling weights. Set SPX5_DWRR_COST_MAX to 31 to match the hardware register width. Fixes: 211225428d65 ("net: microchip: sparx5: add support for offloading ets qdisc") Signed-off-by: Daniel Machon Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260210-sparx5-fix-dwrr-cost-max-v1-1-58fbdbc25652@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 569a833031d7037ed26fa62dfb2951d994d9410e Author: Ido Schimmel Date: Mon Feb 9 14:53:53 2026 +0100 selftests: mlxsw: tc_restrictions: Fix test failure with new iproute2 [ Upstream commit a2646773a005b59fd1dc7ff3ba15df84889ca5d2 ] As explained in [1], iproute2 started rejecting tc-police burst sizes that result in an overflow. This can happen when the burst size is high enough and the rate is low enough. A couple of test cases specify such configurations, resulting in iproute2 errors and test failure. Fix by reducing the burst size so that the test will pass with both new and old iproute2 versions. [1] https://lore.kernel.org/netdev/20250916215731.3431465-1-jay.vosburgh@canonical.com/ Fixes: cb12d1763267 ("selftests: mlxsw: tc_restrictions: Test tc-police restrictions") Signed-off-by: Ido Schimmel Signed-off-by: Petr Machata Reviewed-by: Simon Horman Link: https://patch.msgid.link/88b00c6e85188aa6a065dc240206119b328c46e1.1770643998.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f6833d919bae915ead6c599a53e81e19b32da52 Author: Aboorva Devarajan Date: Tue Feb 17 00:20:02 2026 +0530 cpuidle: Skip governor when only one idle state is available [ Upstream commit e5c9ffc6ae1bcdb1062527d611043681ac301aca ] On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running. Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol") Signed-off-by: Aboorva Devarajan Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260216185005.1131593-2-aboorvad@linux.ibm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d08fb559b4557bdcbf94357b1d682da2d43f8474 Author: Zhai Can Date: Sun Feb 15 00:14:52 2026 +0800 ACPI: PM: Add unused power resource quirk for THUNDEROBOT ZERO [ Upstream commit cd7ef20ba8c6e936dba133b4136537a8ada22976 ] On the THUNDEROBOT ZERO laptop, the second NVMe slot and the discrete NVIDIA GPU are both controlled by power-resource PXP. Due to the SSDT table bug (lack of reference), PXP will be shut dow as an "unused" power resource during initialization, making the NVMe slot #2 + NVIDIA both inaccessible. This issue was introduced by commit a1224f34d72a ("ACPI: PM: Check states of power resources during initialization"). Here are test results on the three consecutive commits: (bad again!) a1224f34d72a ACPI: PM: Check states of power resources during initialization (good) bc2836859643 ACPI: PM: Do not turn off power resources in unknown state (bad) 519d81956ee2 Linux 5.15-rc6 On commit bc2836859643 ("ACPI: PM: Do not turn off power resources in unknown state") this was not an issue because the power resource state left UNKNOWN thus being ignored. See also commit 9b04d99788cf ("ACPI: PM: Do not turn of unused power resources on the Toshiba Click Mini") which is another almost identical case to this one. Fixes: a1224f34d72a ("ACPI: PM: Check states of power resources during initialization") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221087 Signed-off-by: Zhai Can Link: https://patch.msgid.link/20260214161452.2849346-1-bczhc0@126.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f712f72563245a7429e66884c804ffcb8626d624 Author: zhouwenhao Date: Mon Feb 2 21:28:46 2026 +0800 objpool: fix the overestimation of object pooling metadata size [ Upstream commit 5ed4b6b37c647d168ae31035b3f61b705997e043 ] objpool uses struct objpool_head to store metadata information, and its cpu_slots member points to an array of pointers that store the addresses of the percpu ring arrays. However, the memory size allocated during the initialization of cpu_slots is nr_cpu_ids * sizeof(struct objpool_slot). On a 64-bit machine, the size of struct objpool_slot is 16 bytes, which is twice the size of the actual pointer required, and the extra memory is never be used, resulting in a waste of memory. Therefore, the memory size required for cpu_slots needs to be corrected. Link: https://lkml.kernel.org/r/20260202132846.68257-1-zhouwenhao7600@gmail.com Fixes: b4edb8d2d464 ("lib: objpool added: ring-array based lockless MPMC") Signed-off-by: zhouwenhao Reviewed-by: Andrew Morton Cc: "Masami Hiramatsu (Google)" Cc: Matt Wu Cc: wuqiang.matt Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cf27a5efbbfb75fa98b261dd44a4616f480fd57b Author: Aristeu Rozanski Date: Mon Feb 2 09:38:05 2026 -0500 selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT [ Upstream commit b24335521de92fd2ee22460072b75367ca8860b0 ] selftests/memfd: use IPC semaphore instead of SIGSTOP/SIGCONT In order to synchronize new processes to test inheritance of memfd_noexec sysctl, memfd_test sets up the sysctl with a value before creating the new process. The new process then sends itself a SIGSTOP in order to wait for the parent to flip the sysctl value and send a SIGCONT signal. This would work as intended if it wasn't the fact that the new process is being created with CLONE_NEWPID, which creates a new PID namespace and the new process has PID 1 in this namespace. There're restrictions on sending signals to PID 1 and, although it's relaxed for other than root PID namespace, it's biting us here. In this specific case the SIGSTOP sent by the new process is ignored (no error to kill() is returned) and it never stops its execution. This is usually not noticiable as the parent usually manages to set the new sysctl value before the child has a chance to run and the test succeeds. But if you run the test in a loop, it eventually reproduces: while [ 1 ]; do ./memfd_test >log 2>&1 || break; done; cat log So this patch replaces the SIGSTOP/SIGCONT synchronization with IPC semaphore. Link: https://lkml.kernel.org/r/a7776389-b3d6-4b18-b438-0b0e3ed1fd3b@work Fixes: 6469b66e3f5a ("selftests: improve vm.memfd_noexec sysctl tests") Signed-off-by: Aristeu Rozanski Cc: Aleksa Sarai Cc: Shuah Khan Cc: liuye Cc: Lorenzo Stoakes Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 42c7b5d002619efcd72eb9dac3ab7f5ac4eb4732 Author: Josh Poimboeuf Date: Tue Feb 10 13:45:22 2026 -0800 kbuild: Add objtool to top-level clean target [ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf Tested-by: Jens Remus Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 5c32bfbcefc016cc3fe37e0442faa4ba5c695f84 Author: Kuppuswamy Sathyanarayanan Date: Wed Feb 11 14:34:01 2026 -0800 powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check [ Upstream commit c7d54dafa042cf379859dba265fe5afef6fa8770 ] On partitioned systems, multiple TPMI instances may exist per package, but RAPL registers are only valid on one instance since RAPL has package-scope control. Other instances return invalid versions during domain parsing, which is expected behavior on such systems. Currently this generates a firmware bug warning: intel_rapl_tpmi: [Firmware Bug]: Invalid version Remove the FW_BUG tag, downgrade to pr_debug(), and update the message to clarify that invalid versions are expected on partitioned systems where only one instance can be valid. Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver") Reported-by: Zhang Rui Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260211223401.1575776-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ff0641957bce132c86c8fa6e6bd0dc9a0b5dee38 Author: Sean V Kelley Date: Wed Feb 11 21:22:54 2026 +0000 ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs [ Upstream commit 56eb0c0ed345da7815274aa821a8546a073d7e97 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However, send_pcc_cmd() and acpi_get_psd_map() still iterate over all possible CPUs. In acpi_get_psd_map(), encountering an offline CPU returns -EFAULT, causing cppc_cpufreq initialization to fail. This breaks systems booted with "nosmt" or "nosmt=force". Fix by using for_each_online_cpu() in both functions. Fixes: 80b8286aeec0 ("ACPI / CPPC: support for batching CPPC requests") Signed-off-by: Sean V Kelley Link: https://patch.msgid.link/20260211212254.30190-1-skelley@nvidia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c065541b71b79874c83d418a9acd18ad5826339b Author: Jiasheng Jiang Date: Sat Jan 17 16:50:24 2026 +0000 fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot [ Upstream commit b2bc7c44ed1779fc9eaab9a186db0f0d01439622 ] In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking. Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize); It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow. This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Jiasheng Jiang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit b97e371e5d1c13d722335d46eb8bc1a22b272a0e Author: Edward Adam Davis Date: Sun Dec 28 11:53:25 2025 +0800 fs/ntfs3: prevent infinite loops caused by the next valid being the same [ Upstream commit 27b75ca4e51e3e4554dc85dbf1a0246c66106fd3 ] When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit dd6c81527d097b3b0bf5a15c2fdc9657d045144c Author: Bartlomiej Kubik Date: Wed Nov 26 23:02:51 2025 +0100 fs/ntfs3: Initialize new folios before use [ Upstream commit f223ebffa185cc8da934333c5a31ff2d4f992dc9 ] KMSAN reports an uninitialized value in longest_match_std(), invoked from ntfs_compress_write(). When new folios are allocated without being marked uptodate and ni_read_frame() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized. Fixes: 584f60ba22f7 ("ntfs3: Convert ntfs_get_frame_pages() to use a folio") Tested-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Reported-by: syzbot+08d8956768c96a2c52cf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=08d8956768c96a2c52cf Signed-off-by: Bartlomiej Kubik Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 65521ecb8640285c281c1d939219ae604ecbe5fb Author: Jens Axboe Date: Mon Feb 16 14:16:27 2026 -0700 io_uring/cancel: de-unionize file and user_data in struct io_cancel_data [ Upstream commit 22dbb0987bd1e0ec3b1e4ad20756a98f99aa4a08 ] By having them share the same space in struct io_cancel_data, it ends up disallowing IORING_ASYNC_CANCEL_FD|IORING_ASYNC_CANCEL_USERDATA from working. Eg you cannot match on both a file and user_data for cancelation purposes. This obviously isn't a common use case as nobody has reported this, but it does result in -ENOENT potentially being returned when trying to match on both, rather than actually doing what the API says it would. Fixes: 4bf94615b888 ("io_uring: allow IORING_OP_ASYNC_CANCEL with 'fd' key") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d1f212202613d1367813d31363615e03fab9194 Author: Christoph Böhmwalder Date: Thu Feb 5 18:39:29 2026 +0100 drbd: always set BLK_FEAT_STABLE_WRITES [ Upstream commit 2ebc8d600fb907fa6b1e7095c0b6d84fc47e91ea ] DRBD requires stable pages because it may read the same bio data multiple times for local disk I/O and network transmission, and in some cases for calculating checksums. The BLK_FEAT_STABLE_WRITES flag is set when the device is first created, but blk_set_stacking_limits() clears it whenever a backing device is attached. In some cases the flag may be inherited from the backing device, but we want it to be enabled at all times. Unconditionally re-enable BLK_FEAT_STABLE_WRITES in drbd_reconsider_queue_parameters() after the queue parameter negotiations. Also, document why we want this flag enabled in the first place. Fixes: 1a02f3a73f8c ("block: move the stable_writes flag to queue_limits") Signed-off-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 68feac21bd4de7ae4faba05704c404861d991fcf Author: Jared Kangas Date: Tue Jan 13 11:46:50 2026 -0800 dmaengine: fsl-edma: don't explicitly disable clocks in .remove() [ Upstream commit 666c53e94c1d0bf0bdf14c49505ece9ddbe725bc ] The clocks in fsl_edma_engine::muxclk are allocated and enabled with devm_clk_get_enabled(), which automatically cleans these resources up, but these clocks are also manually disabled in fsl_edma_remove(). This causes warnings on driver removal for each clock: edma_module already disabled WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8 [...] Call trace: clk_core_disable+0x198/0x1c8 (P) clk_disable+0x34/0x58 fsl_edma_remove+0x74/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- edma_module already unprepared WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220 [...] Call trace: clk_core_unprepare+0x1f8/0x220 (P) clk_unprepare+0x34/0x58 fsl_edma_remove+0x7c/0xe8 [fsl_edma] [...] ---[ end trace 0000000000000000 ]--- Fix these warnings by removing the unnecessary fsl_disable_clocks() call in fsl_edma_remove(). Fixes: a9903de3aa16 ("dmaengine: fsl-edma: refactor using devm_clk_get_enabled") Signed-off-by: Jared Kangas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113-fsl-edma-clock-removal-v1-1-2025b49e7bcc@redhat.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f076d69aae8148fde2ae4ec76165d71449bea249 Author: Barnabás Czémán Date: Fri Jan 16 08:07:36 2026 +0100 backlight: qcom-wled: Change PM8950 WLED configurations [ Upstream commit 83333aa97441ba7ce32b91e8a007c72d316a1c67 ] PMI8950 WLED needs same configurations as PMI8994 WLED. Fixes: 10258bf4534b ("backlight: qcom-wled: Add PMI8950 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-4-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 92de557d5de4d9c7727da3a68a5caa534b0534a3 Author: Barnabás Czémán Date: Fri Jan 16 08:07:34 2026 +0100 backlight: qcom-wled: Support ovp values for PMI8994 [ Upstream commit f29f972a6e7e3f187ea4d89b98a76c1981ca4d53 ] WLED4 found in PMI8994 supports different ovp values. Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-2-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 37fa7dd1378670ba2ca2a1df68861050c57430e0 Author: Haotian Zhang Date: Fri Jan 9 01:51:33 2026 +0800 leds: qcom-lpg: Check the return value of regmap_bulk_write() [ Upstream commit f42033b5ce8c79c5db645916c9a72ee3e10cecfa ] The lpg_lut_store() function currently ignores the return value of regmap_bulk_write() and always returns 0. This can cause hardware write failures to go undetected, leading the caller to believe LUT programming succeeded when it may have failed. Check the return value of regmap_bulk_write() in lpg_lut_store and return the error to the caller on failure. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20260108175133.638-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7814b1431848854b56717086e2b61bea3c59753d Author: Wei Li Date: Tue Jan 20 08:07:35 2026 +0000 pinctrl: single: fix refcount leak in pcs_add_gpio_func() [ Upstream commit 353353309b0f7afa407df29e455f9d15b5acc296 ] of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review. Fixes: a1a277eb76b3 ("pinctrl: single: create new gpio function range") Signed-off-by: Wei Li Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 50a55756c90e6934e68210b68d4051396c2eb1b5 Author: Luca Weiss Date: Wed Jan 28 12:22:28 2026 +0100 pinctrl: qcom: sm8250-lpass-lpi: Fix i2s2_data_groups definition [ Upstream commit eabf273c8466af3f033473c2d2267a6ea7946d57 ] The i2s2_data function is available on both gpio12 and gpio13. Fix the groups definition. Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Luca Weiss Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 103ac8e3a7f345a0966ef582b8a874ac31a92c7c Author: Harshit Mogalapalli Date: Tue Jan 27 22:49:49 2026 -0800 iio: sca3000: Fix a resource leak in sca3000_probe() [ Upstream commit 62b44ebc1f2c71db3ca2d4737c52e433f6f03038 ] spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails. Fixes: 9a4936dc89a3 ("staging:iio:accel:sca3000 Tidy up probe order to avoid a race.") Signed-off-by: Harshit Mogalapalli Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 721f679d4eb2b243cf72f775197f0a185a98eb0a Author: Qing Wang Date: Wed Jan 28 14:24:04 2026 +0100 ovl: Fix uninit-value in ovl_fill_real [ Upstream commit 1992330d90dd766fcf1730fd7bf2d6af65370ac4 ] Syzbot reported a KMSAN uninit-value issue in ovl_fill_real. This iusse's call chain is: __do_sys_getdents64() -> iterate_dir() ... -> ext4_readdir() -> fscrypt_fname_alloc_buffer() // alloc -> fscrypt_fname_disk_to_usr // write without tail '\0' -> dir_emit() -> ovl_fill_real() // read by strcmp() The string is used to store the decrypted directory entry name for an encrypted inode. As shown in the call chain, fscrypt_fname_disk_to_usr() write it without null-terminate. However, ovl_fill_real() uses strcmp() to compare the name against "..", which assumes a null-terminated string and may trigger a KMSAN uninit-value warning when the buffer tail contains uninit data. Reported-by: syzbot+d130f98b2c265fae5297@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297 Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs") Signed-off-by: Qing Wang Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260128132406.23768-2-amir73il@gmail.com Acked-by: Miklos Szeredi Reviewed-by: Eric Biggers Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a7a7196185c341d0bb51bfd27d8808d21b4a2b91 Author: Felix Gu Date: Tue Jan 27 01:30:07 2026 +0800 pinctrl: equilibrium: Fix device node reference leak in pinbank_init() [ Upstream commit c0b4a4feeb43305a754893d8d9c6b2b5a52d45ac ] When calling of_parse_phandle_with_fixed_args(), the caller is responsible to call of_node_put() to release the reference of device node. In pinbank_init(), the reference of the node obtained from the "gpio-ranges" property is never released, resulting in a reference count leak. Add the missing of_node_put() call to fix the leak. Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC") Signed-off-by: Felix Gu Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8991b4e55f85b74fe6b053d692dfacbd8aaa664e Author: Justin Chen Date: Tue Jan 20 12:07:54 2026 -0800 usb: bdc: fix sleep during atomic [ Upstream commit f1195ca3b4bbd001d3f1264dce91f83dec7777f5 ] bdc_run() can be ran during atomic context leading to a sleep during atomic warning. Fix this by replacing read_poll_timeout() with read_poll_timeout_atomic(). Fixes: 75ae051efc9b ("usb: gadget: bdc: use readl_poll_timeout() to simplify code") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260120200754.2488765-1-justin.chen@broadcom.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 024ea0d2ff897e5ba0394de10e34d1975099ef29 Author: Svyatoslav Ryhel Date: Thu Jan 22 17:34:25 2026 +0200 drivers: iio: mpu3050: use dev_err_probe for regulator request [ Upstream commit b010880b9936da14f8035585ab57577aa05be23a ] Regulator requesting may result in deferred probing error which will abort driver probing. To avoid this just use dev_err_probe which handles deferred probing. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2b81db8a7f4475e141a8ffd7cc745ed9f15962df Author: Robert Marko Date: Mon Jan 12 17:14:52 2026 +0100 mfd: simple-mfd-i2c: Add Delta TN48M CPLD support [ Upstream commit 8f34c1a64c5394d2b51d3fba197947dc4b0b48a0 ] Delta TN48M switches have a Lattice CPLD that serves multiple purposes including being a GPIO expander. So, lets use the simple I2C MFD driver to provide the MFD core. Also add a virtual symbol which pulls in the simple-mfd-i2c driver and provide a common symbol on which the subdevice drivers can depend on. Fixes: b3dcb5de6209 ("gpio: Add Delta TN48M CPLD GPIO driver") Signed-off-by: Robert Marko Link: https://lore.kernel.org/20220131133049.77780-2-robert.marko@sartura.hr Link: https://lore.kernel.org/linux-gpio/20260112064950.3837737-1-rdunlap@infradead.org/ Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260112-mfd-tn48m-v11-1-00c798d8cd2a@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 02302482205ad0139bf9fadf28d5094ce1ecffbd Author: Ioana Ciornei Date: Mon Sep 22 17:24:19 2025 +0300 mfd: simple-mfd-i2c: Keep compatible strings in alphabetical order [ Upstream commit 3ed50d77924ff2e35918739df145dd429cee0ce4 ] Reorder the of_device_id structures so that they are in alphabetical order. Signed-off-by: Ioana Ciornei Signed-off-by: Lee Jones Stable-dep-of: 8f34c1a64c53 ("mfd: simple-mfd-i2c: Add Delta TN48M CPLD support") Signed-off-by: Sasha Levin commit 8993ca8904db8a95f914a8caf6ff8c87d2e98303 Author: Alex Elder Date: Mon Aug 25 12:20:51 2025 -0500 mfd: simple-mfd-i2c: Add SpacemiT P1 support [ Upstream commit 6fc5d415c10e98ac1b31dd1d5653443e691cdcff ] Enable support for the RTC and regulators found in the SpacemiT P1 PMIC. Support is implemented by the simple I2C MFD driver. The P1 PMIC is normally implemented with the SpacemiT K1 SoC. This PMIC provides 6 buck converters and 12 LDO regulators. It also implements a switch, watchdog timer, real-time clock, and more. Initially its RTC and regulators are supported. Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20250825172057.163883-3-elder@riscstar.com Signed-off-by: Lee Jones Stable-dep-of: 8f34c1a64c53 ("mfd: simple-mfd-i2c: Add Delta TN48M CPLD support") Signed-off-by: Sasha Levin commit 5614db619980054d08f972ef85eaae9ed5f8916d Author: Ioana Ciornei Date: Mon Jul 7 18:31:20 2025 +0300 mfd: simple-mfd-i2c: Add compatible strings for Layerscape QIXIS FPGA [ Upstream commit 81a2c31257411296862487aaade98b7d9e25dc72 ] The QIXIS FPGA found on Layerscape boards such as LX2160AQDS, LS1028AQDS etc deals with power-on-reset timing, muxing etc. Use the simple-mfd-i2c as its core driver by adding its compatible string (already found in some dt files). By using the simple-mfd-i2c driver, any child device will have access to the i2c regmap created by it. Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20250707153120.1371719-1-ioana.ciornei@nxp.com Signed-off-by: Lee Jones Stable-dep-of: 8f34c1a64c53 ("mfd: simple-mfd-i2c: Add Delta TN48M CPLD support") Signed-off-by: Sasha Levin commit 0ecce3512344084615ab314b697d6f65e99558a9 Author: Dzmitry Sankouski Date: Thu Jan 23 18:04:29 2025 +0300 mfd: simple-mfd-i2c: Add MAX77705 support [ Upstream commit 7b591ef98b3fc1ce20c3ccb86715429b72e2e6f0 ] Add MAX77705 support - fuel gauge and hwmon devices. Hwmon provides charger input and system bus measurements. Signed-off-by: Dzmitry Sankouski Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250123-starqltechn_integration_upstream-v17-4-8b06685b6612@gmail.com Signed-off-by: Lee Jones Stable-dep-of: 8f34c1a64c53 ("mfd: simple-mfd-i2c: Add Delta TN48M CPLD support") Signed-off-by: Sasha Levin commit e0527c09bcf1e6beeb685a7f4177683866b8609c Author: Haotian Zhang Date: Sun Dec 14 22:58:03 2025 +0800 mfd: arizona: Fix regulator resource leak on wm5102_clear_write_sequencer() failure [ Upstream commit 4feb753ba6e5e5bbaba868b841a2db41c21e56fa ] The wm5102_clear_write_sequencer() helper may return an error and just return, bypassing the cleanup sequence and causing regulators to remain enabled, leading to a resource leak. Change the direct return to jump to the err_reset label to properly free the resources. Fixes: 1c1c6bba57f5 ("mfd: wm5102: Ensure we always boot the device fully") Signed-off-by: Haotian Zhang Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20251214145804.2037-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d225e23c07a4c8c5b46b97eb115d345e7c6b820a Author: Greg Kroah-Hartman Date: Wed Jan 21 15:49:31 2026 +0100 Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms" [ Upstream commit ff112f1ecd10b72004eac05bae395e1c65f0c63c ] This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Cc: Matthew Schwartz Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a771b386cb6c6e582e7b50f8eeff3347ff887f71 Author: Thomas Richard Date: Wed Jan 14 17:50:23 2026 +0100 phy: freescale: imx8qm-hsio: fix NULL pointer dereference [ Upstream commit 4dd5d4c0361af0a3fd24f45c815996abf4429770 ] During the probe the refclk_pad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imx_hsio_configure_clk_pad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it. Fixes: 82c56b6dd24f ("phy: freescale: imx8qm-hsio: Add i.MX8QM HSIO PHY driver support") Signed-off-by: Thomas Richard Reviewed-by: Richard Zhu Link: https://patch.msgid.link/20260114-phy-fsl-imx8qm-hsio-fix-null-pointer-dereference-v1-1-730e941be464@bootlin.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3fa4fdfe68836f8e4b9579ab06bb60d47cee6cc2 Author: Antonio Borneo Date: Thu Jan 8 16:24:27 2026 +0100 coresight: etm3x: Fix cpulocked warning on cpuhp [ Upstream commit 1feb0377b9b816f89a04fc381eb19fc6bac9f4a4 ] When changes [1] and [2] have been applied to the driver etm4x, the same modifications have been also collapsed in [3] and applied in one shot to the driver etm3x. While doing this, the driver etm3x has not been aligned to etm4x on the use of non cpuslocked version of cpuhp callback setup APIs. The current code triggers two run-time warnings when the kernel is compiled with CONFIG_PROVE_LOCKING=y. Use non cpuslocked version of cpuhp callback setup APIs in driver etm3x, aligning it to the driver etm4x. [1] commit 2d1a8bfb61ec ("coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init") [2] commit 22a550a306ad ("coresight: etm4x: Allow etm4x to be built as a module") [3] commit 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Fixes: 97fe626ce64c ("coresight: etm3x: Allow etm3x to be built as a module") Signed-off-by: Antonio Borneo Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260108152427.357379-1-antonio.borneo@foss.st.com Signed-off-by: Sasha Levin commit 151becfbe1fddfda5c0ae507731b73ab60502977 Author: Kery Qi Date: Mon Jan 12 01:29:15 2026 +0800 watchdog: starfive-wdt: Fix PM reference leak in probe error path [ Upstream commit 3f2d8d79cceb05a8b8dd200fa81c0dffc59ec46f ] The PM reference count is not expected to be incremented on return in functions starfive_wdt_probe. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver") Signed-off-by: Kery Qi Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 91557f3459e538865ca719b0ca6de578bfb5fc69 Author: Petre Rodan Date: Wed Jan 14 18:55:34 2026 +0200 iio: pressure: mprls0025pa: fix pressure calculation [ Upstream commit d63403d4e31ae537fefc5c0ee9d90f29b4fc532b ] A sign change is needed for proper calculation of the pressure. This is a minor fix since it only affects users that might have custom silicon from Honeywell that has honeywell,pmin-pascal != 0. Also due to the fact that raw pressure values can not be lower than output_min (400k-3.3M) there is no need to calculate a decimal for the offset. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b843b1f47868ebc93270b27351c2d17d640491eb Author: Petre Rodan Date: Wed Jan 14 18:55:33 2026 +0200 iio: pressure: mprls0025pa: fix scan_type struct [ Upstream commit 8a228e036926f7e57421d750c3724e63f11b808a ] Fix the scan_type sign and realbits assignment. The pressure is a 24bit unsigned int between output_min and output_max. transfer function A: 10% to 90% of 2^24 transfer function B: 2.5% to 22.5% of 2^24 transfer function C: 20% to 80% of 2^24 [MPR_FUNCTION_A] = { .output_min = 1677722, .output_max = 15099494 } [MPR_FUNCTION_B] = { .output_min = 419430, .output_max = 3774874 } [MPR_FUNCTION_C] = { .output_min = 3355443, .output_max = 13421773 } Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 188273fcb3c59d818cf898ff24e085f00940af5c Author: Petre Rodan Date: Wed Jan 14 18:55:32 2026 +0200 iio: pressure: mprls0025pa: fix interrupt flag [ Upstream commit fff3f1a7d805684e4701a70bfaeba39622b59dbc ] Interrupt falling/rising flags should only be defined in the device tree. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 14207e94fe3649d4e6cd0f520a0130ab2de453a3 Author: Petre Rodan Date: Wed Jan 14 18:55:31 2026 +0200 iio: pressure: mprls0025pa: fix SPI CS delay violation [ Upstream commit 583fa86ca581595b1f534a8de6d49ba8b3bf7196 ] Based on the sensor datasheet in chapter 7.6 SPI timing, Table 20, during the SPI transfer there is a minimum time interval requirement between the CS being asserted and the first clock edge (tHDSS). This minimum interval of 2.5us is being violated if two consecutive SPI transfers are queued up. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/micropressure-mpr-series/documents/sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf?download=false Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 72158f9ae29a9e56d0f9704ce461a866feaf9925 Author: Petre Rodan Date: Wed Jan 14 18:55:30 2026 +0200 iio: pressure: mprls0025pa: fix spi_transfer struct initialisation [ Upstream commit 1e0ac56c92e26115cbc8cfc639843725cb3a7d6a ] Make sure that the spi_transfer struct is zeroed out before use. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Signed-off-by: Petre Rodan Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b58f107f359dcacf799aa55903ea2c8cc88efd0b Author: Matthew Schwartz Date: Sun Jan 4 22:02:36 2026 -0800 mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms [ Upstream commit aced969e9bf3701dc75cfca57c78c031b7875b9d ] The existing 1ms delay in sd_power_on is insufficient and causes resume errors around 4% of the time. Increasing the delay to 5ms resolves this issue after testing 300 s2idle cycles. Fixes: 1f311c94aabd ("mmc: rtsx: add 74 Clocks in power on flow") Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260105060236.400366-3-matthew.schwartz@linux.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1ec1a893ee2a913a73437cbeab19be532f2943ae Author: Randy Dunlap Date: Sat Jan 10 15:26:43 2026 -0800 serial: SH_SCI: improve "DMA support" prompt [ Upstream commit 93bb95a11238d66a4c9aa6eabf9774b073a5895c ] Having a prompt of "DMA support" suddenly appear during a "make oldconfig" can be confusing. Add a little helpful text to the prompt message. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Signed-off-by: Randy Dunlap Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260110232643.3533351-5-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5449736d2a8441e662668d835335204c1442ebba Author: Randy Dunlap Date: Sat Jan 10 15:26:40 2026 -0800 serial: imx: change SERIAL_IMX_CONSOLE to bool [ Upstream commit 79527d86ba91c2d9354832d19fd12b3baa66bd10 ] SERIAL_IMX_CONSOLE is a build option for the imx driver (SERIAL_IMX). It does not build a separate console driver file, so it can't be built as a module since it isn't built at all. Change the Kconfig symbol from tristate to bool and update the help text accordingly. Fixes: 0db4f9b91c86 ("tty: serial: imx: enable imx serial console port as module") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260110232643.3533351-2-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 01b91cb3e748032fd96bbe0043812b426a52f091 Author: Chaitanya Mishra Date: Thu Jan 8 20:42:54 2026 +0530 staging: greybus: lights: avoid NULL deref [ Upstream commit efcffd9a6ad8d190651498d5eda53bfc7cf683a7 ] gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer. Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Link: https://lore.kernel.org/all/20260108103700.15384-1-chaitanyamishra.ai@gmail.com/ Reviewed-by: Rui Miguel Silva Signed-off-by: Chaitanya Mishra Link: https://patch.msgid.link/20260108151254.81553-1-chaitanyamishra.ai@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b1e288645d69b4ab7fc8ca447006e471b7a0fd08 Author: Randy Dunlap Date: Sat Dec 27 23:10:29 2025 -0800 iio: test: drop dangling symbol in gain-time-scale helpers [ Upstream commit d63d868b312478523670b76007dcc5eaedc3ee07 ] The code for this never went upstream. It was replaced by other code, so this should be dropped. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216748 Fixes: cf996f039679 ("iio: test: test gain-time-scale helpers") Signed-off-by: Randy Dunlap Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9d00bf5ca6d5732d97efe37111f68b8394f581c9 Author: Arnd Bergmann Date: Tue Dec 23 22:50:01 2025 +0100 soundwire: intel_ace2x: add SND_HDA_CORE dependency [ Upstream commit dc3a6a942e9ee3f18560bfcb16c06bb94f37fabf ] The ace2x driver can optionally use the HDA infrastructure, but can still build without that. However, with SND_HDA_CORE=m and SND_HDA_ALIGNED_MMIO=y, it fails to link as built-in: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_shim_wake': intel_ace2x.c:(.text+0x2518): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x25d4): undefined reference to `snd_hdac_aligned_read' aarch64-linux-ld: intel_ace2x.c:(.text+0x268c): undefined reference to `snd_hdac_aligned_write' Add a Kconfig dependency that forces the soundwire driver to be a loadable module if necessary. Fixes: 79e7123c078d ("soundwire: intel_ace2x: fix wakeup handling") Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20251223215014.534756-1-arnd@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 055273d82544ac2ab34595a22d3abdbf0a39efbc Author: Nuno Sá Date: Tue Nov 4 16:22:26 2025 +0000 dma: dma-axi-dmac: fix HW scatter-gather not looking at the queue [ Upstream commit bbcbafb99df41a1d81403eb4f5bb443b38228b57 ] For HW scatter gather transfers we still need to look for the queue. The HW is capable of queueing 3 concurrent transfers and if we try more than that we'll get the submit queue full and should return. Otherwise, if we go ahead and program the new transfer, we end up discarding it. Fixes: e97dc7435972 ("dmaengine: axi-dmac: Add support for scatter-gather transfers") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-2-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2813261626d485497ddcb396a7c3e6f680914431 Author: Nuno Sá Date: Tue Nov 4 16:22:25 2025 +0000 dma: dma-axi-dmac: fix SW cyclic transfers [ Upstream commit 9bd257181fd5c996d922e9991500ad27987cfbf4 ] If 'hw_cyclic' is false we should still be able to do cyclic transfers in "software". That was not working for the case where 'desc->num_sgs' is 1 because 'chan->next_desc' is never set with the current desc which means that the cyclic transfer only runs once and in the next SOT interrupt we do nothing since vchan_next_desc() will return NULL. Fix it by setting 'chan->next_desc' as soon as we get a new desc via vchan_next_desc(). Fixes: 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller") Signed-off-by: Nuno Sá base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-1-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 25da519fb5e9230e724491d48767946c1c61e16d Author: AngeloGioacchino Del Regno Date: Thu Nov 13 13:22:26 2025 +0100 dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX [ Upstream commit 58ab9d7b6651d21e1cff1777529f2d3dd0b4e851 ] The VFF_4G_SUPPORT register is named differently in datasheets, and its name is "VFF_ADDR2"; was this named correctly from the beginning it would've been clearer that there was a mistake in the programming sequence. This register is supposed to hold the high bits to support the DMA addressing above 4G (so, more than 32 bits) and not a bit to "enable" the support for VFF 4G. Fix the name of this register, and also fix its usage by writing the upper 32 bits of the dma_addr_t on it when the SoC supports such feature. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251113122229.23998-6-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 525858eb00fb26c59201a4010688f968cc720caa Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:02 2025 +0100 interconnect: mediatek: Aggregate bandwidth with saturating add [ Upstream commit 6ffd02b82243d9907b5f5d2c7a2fc6a62669eece ] By using a regular non-overflow-checking add, the MediaTek icc-emi driver will happy wrap at U32_MAX + 1 to 0. As it's common for the interconnect core to fill in INT_MAX values, this is not a hypothetical situation, but something that actually happens in regular use. This would be pretty disasterous if anything used this driver. Replace the addition with an overflow-checked addition from overflow.h, and saturate to U32_MAX if an overflow is detected. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-13-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 5d7c7c54b6a5c9de740742cf5cc731abca97b671 Author: Nicolas Frattaroli Date: Mon Nov 24 12:07:01 2025 +0100 interconnect: mediatek: Don't hijack parent device [ Upstream commit 510f8214440c553e81774c5822437ccf154e9e38 ] If the intention is that users of the interconnect declare their relationship to the child icc_emi node of the dvfsrc controller, then this code never worked. That's because it uses the parent dvfsrc device as the device it passes to the interconnect core framework, which means all the OF parsing is broken. Use the actual device instead, and pass the dvfsrc parent into the dvfsrc calls. Fixes: b45293799f75 ("interconnect: mediatek: Add MediaTek MT8183/8195 EMI Interconnect driver") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-12-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit c5fa94489fe84dbfd2d48b642363c6fdfadd145d Author: Haotian Zhang Date: Sun Nov 23 23:43:15 2025 +0800 clk: mediatek: Fix error handling in runtime PM setup [ Upstream commit aa2ad19210a6a444111bce55e8b69579f29318fb ] devm_pm_runtime_enable() can fail due to memory allocation. The current code ignores its return value, and when pm_runtime_resume_and_get() fails, it returns directly without unmapping the shared_io region. Add error handling for devm_pm_runtime_enable(). Reorder cleanup labels to properly unmap shared_io on pm_runtime_resume_and_get() failure. Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") Signed-off-by: Haotian Zhang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 56360aa4ddd736fc19e6d0b0206c5e437e0d6ff8 Author: Dmitry Baryshkov Date: Sat Jan 17 05:54:47 2026 +0200 clk: qcom: gfx3d: add parent to parent request map [ Upstream commit 2583cb925ca1ce450aa5d74a05a67448db970193 ] After commit d228ece36345 ("clk: divider: remove round_rate() in favor of determine_rate()") determining GFX3D clock rate crashes, because the passed parent map doesn't provide the expected best_parent_hw clock (with the roundd_rate path before the offending commit the best_parent_hw was ignored). Set the field in parent_req in addition to setting it in the req, fixing the crash. clk_hw_round_rate (drivers/clk/clk.c:1764) (P) clk_divider_bestdiv (drivers/clk/clk-divider.c:336) divider_determine_rate (drivers/clk/clk-divider.c:358) clk_alpha_pll_postdiv_determine_rate (drivers/clk/qcom/clk-alpha-pll.c:1275) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) __clk_determine_rate (drivers/clk/clk.c:1741) clk_gfx3d_determine_rate (drivers/clk/qcom/clk-rcg2.c:1268) clk_core_determine_round_nolock (drivers/clk/clk.c:1606) clk_core_round_rate_nolock (drivers/clk/clk.c:1701) clk_core_round_rate_nolock (drivers/clk/clk.c:1710) clk_round_rate (drivers/clk/clk.c:1804) dev_pm_opp_set_rate (drivers/opp/core.c:1440 (discriminator 1)) msm_devfreq_target (drivers/gpu/drm/msm/msm_gpu_devfreq.c:51) devfreq_set_target (drivers/devfreq/devfreq.c:360) devfreq_update_target (drivers/devfreq/devfreq.c:426) devfreq_monitor (drivers/devfreq/devfreq.c:458) process_one_work (arch/arm64/include/asm/jump_label.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284) worker_thread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2)) kthread (kernel/kthread.c:467) ret_from_fork (arch/arm64/kernel/entry.S:861) Fixes: 55213e1acec9 ("clk: qcom: Add gfx3d ping-pong PLL frequency switching") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Brian Masney Link: https://lore.kernel.org/r/20260117-db820-fix-gfx3d-v1-1-0f8894d71d63@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cb7b741e350fd53f44acc5912968feaa23bf9e68 Author: David Heidelberg Date: Sat Jan 17 19:18:28 2026 +0100 clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk1_clk_src [ Upstream commit fab13d738c9bd645965464b881335f580d38a54e ] Set CLK_OPS_PARENT_ENABLE to ensure the parent gets prepared and enabled when switching to it. Fixes: e3c13e0caa8c ("clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk0_clk_src") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20260117-sm7150-dispcc-fix-v1-1-2f39966bcad2@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f9c45fb866d92f081a4910324c0ad572ee035352 Author: Petr Hodina Date: Wed Jan 7 12:44:43 2026 +0100 clk: qcom: dispcc-sdm845: Enable parents for pixel clocks [ Upstream commit a1d63493634e98360140027fef49d82b1ff0a267 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 81351776c9fb ("clk: qcom: Add display clock controller driver for SDM845") Signed-off-by: Petr Hodina Reviewed-by: Dmitry Baryshkov Reviewed-by: David Heidelberg Link: https://lore.kernel.org/r/20260107-stability-discussion-v2-1-ef7717b435ff@protonmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c4a00b99dc6d71c5e97dfcee9d349593e1ca4d0f Author: Geert Uytterhoeven Date: Mon Dec 1 10:42:26 2025 +0100 clk: Move clk_{save,restore}_context() to COMMON_CLK section [ Upstream commit f47c1b77d0a2a9c0d49ec14302e74f933398d1a3 ] The clk_save_context() and clk_restore_context() helpers are only implemented by the Common Clock Framework. They are not available when using legacy clock frameworks. Dummy implementations are provided, but only if no clock support is available at all. Hence when CONFIG_HAVE_CLK=y, but CONFIG_COMMON_CLK is not enabled: m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_resume': air_en8811h.c:(.text+0x83e): undefined reference to `clk_restore_context' m68k-linux-gnu-ld: drivers/net/phy/air_en8811h.o: in function `en8811h_suspend': air_en8811h.c:(.text+0x856): undefined reference to `clk_save_context' Fix this by moving forward declarations and dummy implementions from the HAVE_CLK to the COMMON_CLK section. Fixes: 8b95d1ce3300c411 ("clk: Add functions to save/restore clock context en-masse") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511301553.eaEz1nEW-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b109dd4970a0fc89d54b1198b163f86125dd2977 Author: George Moussalem Date: Fri Nov 28 15:03:19 2025 +0400 clk: qcom: gcc-ipq5018: flag sleep clock as critical [ Upstream commit 04c4dc1f541135708d90a9b4632af51136f93ac3 ] The sleep clock never be disabled. To avoid the kernel trying to disable it and keep it always on, flag it as critical. Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: George Moussalem Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251128-ipq5018-sleep-clk-fix-v1-1-6f4b75ec336c@outlook.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 596048c0d7eca212000b182f05fc629d7a10efa9 Author: Barnabás Czémán Date: Mon Nov 17 18:58:48 2025 +0100 clk: qcom: gcc-msm8917: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit e4eb42f290aecac0ba355b1f8d7243be6de11f32 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 33cc27a47d3a ("clk: qcom: Add global clock controller driver for MSM8917") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-2-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6b3b27031c5bf871ca38ec7fed125317b876b483 Author: Barnabás Czémán Date: Mon Nov 17 18:58:47 2025 +0100 clk: qcom: gcc-msm8953: Remove ALWAYS_ON flag from cpp_gdsc [ Upstream commit 5f613e7034187179a9d088ff5fd02b1089d0cf20 ] cpp_gdsc should not be always on, ALWAYS_ON flag was set accidentally. Fixes: 9bb6cfc3c77e ("clk: qcom: Add Global Clock Controller driver for MSM8953") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251117-fix-gdsc-cpp-msm8917-msm8953-v1-1-db33adcff28a@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a4fb5a9dc6227498cdc0dd6a31eea4e8db3d9596 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:42 2025 +0530 clk: qcom: gcc-qdu1000: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 947c4b326c1f4dc64aed42170b39c2cf551ba8ca ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: baa316580013 ("clk: qcom: gcc-qdu1000: Update the SDCC clock RCG ops") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Taniya Das Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-7-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0c74a63b797ca495e8d48645103bc2b1eb634adf Author: Jagadeesh Kona Date: Thu Nov 27 23:27:41 2025 +0530 clk: qcom: gcc-x1e80100: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit a468047c4e1c56783204a3ac551b843b4277c8fc ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Jagadeesh Kona Reviewed-by: Imran Shaik Reviewed-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-6-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1936fe74af4ab041fe343ef8de0898991a9f9fe6 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:39 2025 +0530 clk: qcom: gcc-sdx75: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 4b057462bb61a6571608ba393e6e018c9da9c9c3 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: 108cdc09b2de ("clk: qcom: Add GCC driver support for SDX75") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-4-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit daa1b65f23cdae0c8c97b67c2e8eb867db034518 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:38 2025 +0530 clk: qcom: gcc-sm4450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 458e8a082186335380a9ab83003a385aec9bb254 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: c32c4ef98bac ("clk: qcom: Add GCC driver support for SM4450") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-3-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 99db18b34fd69d24774d49123c0474e144d3d3c6 Author: Jagadeesh Kona Date: Thu Nov 27 23:27:36 2025 +0530 clk: qcom: gcc-sm8450: Update the SDCC RCGs to use shared_floor_ops [ Upstream commit 89428516f99572a9c37ebbb7859595881e7025a0 ] Use shared_floor_ops for the SDCC RCGs so the RCG is safely parked during disable and the new parent configuration is programmed in hardware only when the new parent is enabled, avoiding cases where the RCG configuration fails to update. Fixes: a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") Reviewed-by: Taniya Das Reviewed-by: Imran Shaik Reviewed-by: Dmitry Baryshkov Reviewed-by: Vladimir Zapolskiy Signed-off-by: Jagadeesh Kona Link: https://lore.kernel.org/r/20251127-sdcc_shared_floor_ops-v2-1-473afc86589c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 762c69e6ed2a51108d60634ace33c72fdd3f5938 Author: Martin Blumenstingl Date: Mon Jan 5 21:47:08 2026 +0100 clk: meson: gxbb: Limit the HDMI PLL OD to /4 on GXL/GXM SoCs [ Upstream commit 5b1a43950fd3162af0ce52b13c14a2d29b179d4f ] GXBB has the HDMI PLL OD in the HHI_HDMI_PLL_CNTL2 register while for GXL/GXM the OD has moved to HHI_HDMI_PLL_CNTL3. At first glance the rest of the OD setup seems identical. However, looking at the downstream kernel sources as well as testing shows that GXL only supports three OD values: - register value 0 means: divide by 1 - register value 1 means: divide by 2 - register value 2 means: divide by 4 Using register value 3 (which on GXBB means: divide by 8) still divides by 4 as verified using meson-clk-measure. Downstream sources are also only using OD register values 0, 1 and 2 for GXL (while for GXBB the downstream kernel sources are also using value 3). Add clk_div_table and have it replace the CLK_DIVIDER_POWER_OF_TWO flag to make the kernel's view of this register match with how the hardware actually works. Fixes: 69d92293274b ("clk: meson: add the gxl hdmi pll") Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20260105204710.447779-2-martin.blumenstingl@googlemail.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 909b48a3b3b47dbe267105625d13ac505c6fb48b Author: Taniya Das Date: Mon Jan 5 16:09:50 2026 +0530 clk: qcom: rcg2: compute 2d using duty fraction directly [ Upstream commit d6205a1878dd4cc9664c4b4829b68a29c0426efc ] The duty-cycle calculation in clk_rcg2_set_duty_cycle() currently derives an intermediate percentage `duty_per = (num * 100) / den` and then computes: d = DIV_ROUND_CLOSEST(n * duty_per * 2, 100); This introduces integer truncation at the percentage step (division by `den`) and a redundant scaling by 100, which can reduce precision for large `den` and skew the final rounding. Compute `2d` directly from the duty fraction to preserve precision and avoid the unnecessary scaling: d = DIV_ROUND_CLOSEST(n * duty->num * 2, duty->den); This keeps the intended formula `d ≈ n * 2 * (num/den)` while performing a single, final rounded division, improving accuracy especially for small duty cycles or large denominators. It also removes the unused `duty_per` variable, simplifying the code. There is no functional changes beyond improved numerical accuracy. Fixes: 7f891faf596ed ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20260105-duty_cycle_precision-v2-1-d1d466a6330a@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 662676d6e735295a7b07670c1bd8f7a30c6e5d63 Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:12 2025 +0200 clk: qcom: gcc-sm8650: Use floor ops for SDCC RCGs [ Upstream commit 8c4415fd17cd5979c31a4bf303acc702e9726033 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8650. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: c58225b7e3d7 ("clk: qcom: add the SM8650 Global Clock Controller driver, part 1") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b1b6935689b8f88f7f6832cf952e4538ba8fa2aa Author: Vladimir Zapolskiy Date: Mon Nov 24 23:20:11 2025 +0200 clk: qcom: gcc-sm8550: Use floor ops for SDCC RCGs [ Upstream commit 1c06e3956054fb5a0930f07b02726b1774b6c700 ] In line with commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs") done to fix issues with overclocked SD cards on SM8450 powered boards set floor clock operations for SDCC RCGs on SM8550. This change fixes initialization of some SD cards, where the problem is manifested by the SDHC driver: mmc0: Card appears overclocked; req 50000000 Hz, actual 100000000 Hz mmc0: error -110 whilst initialising SD card Fixes: 955f2ea3b9e9 ("clk: qcom: Add GCC driver for SM8550") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20251124212012.3660189-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 762a26818934241b8b0172a229d2cf5d87260e40 Author: Felix Gu Date: Tue Feb 3 20:14:58 2026 +0800 fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() [ Upstream commit ce4e25198a6aaaaf36248edf8daf3d744ec8e309 ] In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup. Fixes: 4e88761f5f8c ("fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit f620398f0db11c9b1cd3e3e6e9328b587c7b90b4 Author: Felix Gu Date: Sat Jan 31 20:48:33 2026 +0800 fbdev: of_display_timing: Fix device node reference leak in of_get_display_timings() [ Upstream commit c39ee2d264f98efa14aa46c9942114cb03c7baa6 ] Use for_each_child_of_node_scoped instead of for_each_child_of_node to ensure automatic of_node_put on early exit paths, preventing device node reference leak. Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode") Signed-off-by: Felix Gu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit bcd1aea42610a5f057ca31b86aa5f50859b0ff74 Author: Steven Rostedt Date: Mon Jan 26 13:00:37 2026 -0500 tracing: Remove duplicate ENABLE_EVENT_STR and DISABLE_EVENT_STR macros [ Upstream commit 9df0e49c5b9b8d051529be9994e4f92f2d20be6f ] The macros ENABLE_EVENT_STR and DISABLE_EVENT_STR were added to trace.h so that more than one file can have access to them, but was never removed from their original location. Remove the duplicates. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20260126130037.4ba201f9@gandalf.local.home Fixes: d0bad49bb0a09 ("tracing: Add enable_hist/disable_hist triggers") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 9b0513905e0598b9f8cfccab8e47497aed5d935d Author: Miaoqian Lin Date: Thu Dec 11 14:00:58 2025 +0400 tracing: Properly process error handling in event_hist_trigger_parse() [ Upstream commit 0550069cc25f513ce1f109c88f7c1f01d63297db ] Memory allocated with trigger_data_alloc() requires trigger_data_free() for proper cleanup. Replace kfree() with trigger_data_free() to fix this. Found via static analysis and code review. This isn't a real bug due to the current code basically being an open coded version of trigger_data_free() without the synchronization. The synchronization isn't needed as this is the error path of creation and there's nothing to synchronize against yet. Replace the kfree() to be consistent with the allocation. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Tom Zanussi Link: https://patch.msgid.link/20251211100058.2381268-1-linmq006@gmail.com Fixes: e1f187d09e11 ("tracing: Have existing event_command.parse() implementations use helpers") Signed-off-by: Miaoqian Lin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 596c8b168cfd3fedc4d8583f48446ced1d8fc82b Author: Sagi Grimberg Date: Sat Dec 27 12:46:29 2025 +0200 fs/nfs: Fix readdir slow-start regression [ Upstream commit 42e7c876b182da65723700f6bc507a8aecb10d3b ] Commit 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") reduces the amount of readahead names caching done by the client. The downside of this approach is READDIR now may suffer from a slow-start issue, where initially it will fetch names that fit in a single page, then in 2, 4, 8 until the maximum supported transfer size (usually 1M). This patch tries to take a balanced approach between mitigating the slow-start issue still maintaining some efficiency gains. Fixes: 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir") Signed-off-by: Sagi Grimberg Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2eff9d3537b8bcf7cf3d07a3176ec070c19d1643 Author: Li Chen Date: Tue Feb 3 10:13:51 2026 +0800 nvdimm: virtio_pmem: serialize flush requests [ Upstream commit a9ba6733c7f1096c4506bf4e34a546e07242df74 ] Under heavy concurrent flush traffic, virtio-pmem can overflow its request virtqueue (req_vq): virtqueue_add_sgs() starts returning -ENOSPC and the driver logs "no free slots in the virtqueue". Shortly after that the device enters VIRTIO_CONFIG_S_NEEDS_RESET and flush requests fail with "virtio pmem device needs a reset". Serialize virtio_pmem_flush() with a per-device mutex so only one flush request is in-flight at a time. This prevents req_vq descriptor overflow under high concurrency. Reproducer (guest with virtio-pmem): - mkfs.ext4 -F /dev/pmem0 - mount -t ext4 -o dax,noatime /dev/pmem0 /mnt/bench - fio: ioengine=io_uring rw=randwrite bs=4k iodepth=64 numjobs=64 direct=1 fsync=1 runtime=30s time_based=1 - dmesg: "no free slots in the virtqueue" "virtio pmem device needs a reset" Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Signed-off-by: Li Chen Acked-by: Pankaj Gupta Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260203021353.121091-1-me@linux.beauty Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 6037124dbf675fbd0a6248aaf04cf07387b8c323 Author: Colin Ian King Date: Thu Jan 29 15:53:32 2026 +0000 scsi: csiostor: Fix dereference of null pointer rn [ Upstream commit 1982257570b84dc33753d536dd969fd357a014e9 ] The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference. Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by: Colin Ian King Link: https://patch.msgid.link/20260129155332.196338-1-colin.i.king@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eb10468cef22191db937dd43377851b34e253ee7 Author: Arnd Bergmann Date: Mon Feb 2 10:50:18 2026 +0100 scsi: ufs: host: mediatek: Require CONFIG_PM [ Upstream commit bbb8d98fb4536594cb104fd630ea0f7dce3771d6 ] The added print statement from a recent fix causes the driver to fail building when CONFIG_PM is disabled: drivers/ufs/host/ufs-mediatek.c: In function 'ufs_mtk_resume': drivers/ufs/host/ufs-mediatek.c:1890:40: error: 'struct dev_pm_info' has no member named 'request' 1890 | hba->dev->power.request, It seems unlikely that the driver can work at all without CONFIG_PM, so just add a dependency and remove the existing ifdef checks, rather than adding another ifdef. Fixes: 15ef3f5aa822 ("scsi: ufs: host: mediatek: Enhance recovery on resume failure") Signed-off-by: Arnd Bergmann Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260202095052.1232703-1-arnd@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d52e13122d3771f753dd73ae6512fa01f58015cb Author: Zilin Guan Date: Sat Jan 31 09:36:41 2026 +0000 scsi: smartpqi: Fix memory leak in pqi_report_phys_luns() [ Upstream commit 41b37312bd9722af77ec7817ccf22d7a4880c289 ] pqi_report_phys_luns() fails to release the rpl_list buffer when encountering an unsupported data format or when the allocation for rpl_16byte_wwid_list fails. These early returns bypass the cleanup logic, leading to memory leaks. Consolidate the error handling by adding an out_free_rpl_list label and use goto statements to ensure rpl_list is consistently freed on failure. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 28ca6d876c5a ("scsi: smartpqi: Add extended report physical LUNs") Signed-off-by: Zilin Guan Tested-by: Don Brace Acked-by: Don Brace Link: https://patch.msgid.link/20260131093641.1008117-1-zilin@seu.edu.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b3a8b2bbc48e099f3c4d5e953b6c1d8f38c578f1 Author: Olga Kornievskaia Date: Mon Jan 26 14:15:39 2026 -0500 pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN [ Upstream commit 5248d8474e594d156bee1ed10339cc16e207a28b ] It is possible to have a task get stuck on waiting on the NFS_LAYOUT_DRAIN in the following scenario 1. cpu a: waiter test NFS_LAYOUT_DRAIN (1) and plh_outstanding (1) 2. cpu b: atomic_dec_and_test() -> clear bit -> wake up 3. cpu c: sets NFS_LAYOUT_DRAIN again 4. cpu a: calls wait_on_bit() sleeps forever. To expand on this we have say 2 outstanding pnfs write IO that get ESTALE which causes both to call pnfs_destroy_layout() and set the NFS_LAYOUT_DRAIN bit but the 1st one doesn't call the pnfs_put_layout_hdr() yet (as that would prevent the 2nd ESTALE write from trying to call pnfs_destroy_layout()). If the 1st ESTALE write is the one that initially sets the NFS_LAYOUT_DRAIN so that new IO on this file initiates new LAYOUTGET. Another new write would find NFS_LAYOUT_DRAIN set and phl_outstanding>0 (step 1) and would wait_on_bit(). LAYOUTGET completes doing step 2. Now, the 2nd of ESTALE writes is calling pnfs_destory_layout() and set the NFS_LAYOUT_DRAIN bit (step 3). Finally, the waiting write wakes up to check the bit and goes back to sleep. The problem revolves around the fact that if NFS_LAYOUT_INVALID_STID was already set, it should not do the work of pnfs_mark_layout_stateid_invalid(), thus NFS_LAYOUT_DRAIN will not be set more than once for an invalid layout. Suggested-by: Trond Myklebust Fixes: 880265c77ac4 ("pNFS: Avoid a live lock condition in pnfs_update_layout()") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 84667e99a8bc763d997492077f8b06ce099d97b0 Author: Yi Liu Date: Thu Jan 29 17:49:00 2026 +0800 RDMA/uverbs: Add __GFP_NOWARN to ib_uverbs_unmarshall_recv() kmalloc [ Upstream commit 58b604dfc7bb753f91bc0ccd3fa705e14e6edfb4 ] Since wqe_size in ib_uverbs_unmarshall_recv() is user-provided and already validated, but can still be large, add __GFP_NOWARN to suppress memory allocation warnings for large sizes, consistent with the similar fix in ib_uverbs_post_send(). Fixes: 67cdb40ca444 ("[IB] uverbs: Implement more commands") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260129094900.3517706-1-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2b3b3e0d8abf5bd266d8152350da82c3aec2968e Author: Val Packett Date: Tue Jan 20 20:57:58 2026 -0300 power: supply: qcom_battmgr: Recognize "LiP" as lithium-polymer [ Upstream commit c655f45480637aee326b5bd96488d35ab90db2b0 ] On the Dell Latitude 7455, the firmware uses "LiP" with a lowercase 'i' for the battery chemistry type, but only all-uppercase "LIP" was being recognized. Add the CamelCase variant to the check to fix the "Unknown battery technology" warning. Fixes: 202ac22b8e2e ("power: supply: qcom_battmgr: Add lithium-polymer entry") Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260120235831.479038-1-val@packett.cool Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9fab0120907e6965168e55b1e17cb9dfaf262b86 Author: Waqar Hameed Date: Fri Jan 23 11:24:20 2026 +0100 power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler [ Upstream commit 23067259919663580c6f81801847cfc7bd54fd1f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/e2a4cd2fcd42b6cd97d856c17c097289a2aed393.1769163273.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 896a54984905c438844a038b6c04fb6c08b21852 Author: Miquel Raynal Date: Fri Jan 9 18:18:02 2026 +0100 mtd: spinand: Fix kernel doc [ Upstream commit a57b1f07d2d35843a7ada30c8cf9a215c0931868 ] The @data buffer is 5 bytes, not 4, it has been extended for the need of devices with an extra ID bytes. Fixes: 34a956739d29 ("mtd: spinand: Add support for 5-byte IDs") Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fbd5b014a966b45e18c5d2fa263af48ea30aa076 Author: Weigang He Date: Fri Jan 23 05:26:08 2026 +0000 mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions() [ Upstream commit 7cce81df7d26d44123bd7620715c8349d96793d7 ] of_get_child_by_name() returns a node pointer with refcount incremented, which must be released with of_node_put() when done. However, in parse_fixed_partitions(), when dedicated is true (i.e., a "partitions" subnode was found), the ofpart_node obtained from of_get_child_by_name() is never released on any code path. Add of_node_put(ofpart_node) calls on all exit paths when dedicated is true to fix the reference count leak. This bug was detected by our static analysis tool. Fixes: 562b4e91d3b2 ("mtd: parsers: ofpart: fix parsing subpartitions") Signed-off-by: Weigang He Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 130381dd82e733a78f17f3f0482770c1756d11d9 Author: Yuxiong Wang Date: Thu Jan 29 14:45:52 2026 +0800 cxl: Fix premature commit_end increment on decoder commit failure [ Upstream commit 7b6f9d9b1ea05c9c22570126547c780e8c6c3f62 ] In cxl_decoder_commit(), commit_end is incremented before verifying whether the commit succeeded, and the CXL_DECODER_F_ENABLE bit in cxld->flags is only set after a successful commit. As a result, if the commit fails, commit_end has been incremented and cxld->reset() has no effect since the flag is not set, so commit_end remains incorrectly incremented. The inconsistency between commit_end and CXL_DECODER_F_ENABLE causes failure during subsequent either commit or reset operations. Fix this by incrementing commit_end only after confirming the commit succeeded. Also, remove the ineffective cxld->reset() call. According to CXL Spec r4.0 8.2.4.20.12 Committing Decoder Programming, since cxld_await_commit() has cleared the decoder commit bit on failure, no additional reset is required. [dj: Fixed commit log 80 char wrapping. ] [dj: Fix "Fixes" tag to correct hash length. ] [dj: Change spec to r4.0. ] Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware") Signed-off-by: Yuxiong Wang Acked-by: Huang Ying Reviewed-by: Dave Jiang Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260129064552.31180-1-yuxiong.wang@linux.alibaba.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 5c32cabddc4ef774d099583f0bb86cf5823cc8f9 Author: Chuck Lever Date: Tue Jan 27 19:53:59 2026 -0500 RDMA/core: add rdma_rw_max_sge() helper for SQ sizing [ Upstream commit afcae7d7b8a278a6c29e064f99e5bafd4ac1fb37 ] svc_rdma_accept() computes sc_sq_depth as the sum of rq_depth and the number of rdma_rw contexts (ctxts). This value is used to allocate the Send CQ and to initialize the sc_sq_avail credit pool. However, when the device uses memory registration for RDMA operations, rdma_rw_init_qp() inflates the QP's max_send_wr by a factor of three per context to account for REG and INV work requests. The Send CQ and credit pool remain sized for only one work request per context, causing Send Queue exhaustion under heavy NFS WRITE workloads. Introduce rdma_rw_max_sge() to compute the actual number of Send Queue entries required for a given number of rdma_rw contexts. Upper layer protocols call this helper before creating a Queue Pair so that their Send CQs and credit accounting match the QP's true capacity. Update svc_rdma_accept() to use rdma_rw_max_sge() when computing sc_sq_depth, ensuring the credit pool reflects the work requests that rdma_rw_init_qp() will reserve. Reviewed-by: Christoph Hellwig Fixes: 00bd1439f464 ("RDMA/rw: Support threshold for registration vs scattering to local pages") Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260128005400.25147-5-cel@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3c2ae79fb19dfd67341c14f1e78a5f1744eacfe2 Author: Li Zhijian Date: Tue Jan 20 15:44:37 2026 +0800 RDMA/rxe: Fix race condition in QP timer handlers [ Upstream commit 87bf646921430e303176edc4eb07c30160361b73 ] I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. Signed-off-by: Li Zhijian Fixes: d94671632572 ("RDMA/rxe: Rewrite rxe_task.c") Link: https://patch.msgid.link/20260120074437.623018-1-lizhijian@fujitsu.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ee998cdbff6680891b0efd9d6ce53a388e5342c3 Author: Zilin Guan Date: Mon Jan 26 07:48:01 2026 +0000 RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler [ Upstream commit 9b9d253908478f504297ac283c514e5953ddafa6 ] The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function allocates memory for the device path using kobject_get_path(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak. Add a kfree() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: ec7ad6530909 ("RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl") Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260126074801.627898-1-zilin@seu.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d533425ac1f2925b4fc3e4ed9b9d72362cb23475 Author: Yi Liu Date: Thu Jan 22 22:29:00 2026 +0800 RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send [ Upstream commit 1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0 ] ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr). Fixes: c3bea3d2dc53 ("RDMA/uverbs: Use the iterator for ib_uverbs_unmarshall_recv()") Signed-off-by: Yi Liu Link: https://patch.msgid.link/20260122142900.2356276-2-liuy22@mails.tsinghua.edu.cn Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8d9798d6ff412116bc12159eb903c9597ac2f334 Author: Mike Snitzer Date: Wed Jan 7 11:08:56 2026 -0500 NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit [ Upstream commit 9bb0060f7860aa4561c5b21163dd45ceb66946a9 ] nfslocaliod_workqueue is a non-memreclaim workqueue (it isn't initialized with WQ_MEM_RECLAIM), see commit b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write"). Use nfslocaliod_workqueue for LOCALIO's SYNC work. Also, set PF_LOCAL_THROTTLE | PF_MEMALLOC_NOIO in nfs_local_fsync_work. Fixes: b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write") Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit af87ebd343187901b5565e8ffbfe803d2b4c6a42 Author: Mike Snitzer Date: Thu Oct 3 15:35:02 2024 -0400 nfs/localio: eliminate unnecessary kref in nfs_local_fsync_ctx [ Upstream commit 894f5c5593cdb57841318597a800ad1d3cb45a52 ] nfs_local_commit() doesn't need async cleanup of nfs_local_fsync_ctx, so there is no need to use a kref. Signed-off-by: Mike Snitzer Signed-off-by: Trond Myklebust Stable-dep-of: 9bb0060f7860 ("NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit") Signed-off-by: Sasha Levin commit e97f5fac8ce9a6b9ec724c97d86b0985e915fdca Author: Zilin Guan Date: Thu Jan 22 13:09:50 2026 +0000 mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse() [ Upstream commit 980ce2b02dd06a4fdf5fee38b2e14becf9cf7b8b ] The function mtd_parser_tplink_safeloader_parse() allocates buf via mtd_parser_tplink_safeloader_read_table(). If the allocation for parts[idx].name fails inside the loop, the code jumps to the err_free label without freeing buf, leading to a memory leak. Fix this by freeing the temporary buffer buf in the err_free label. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 00a3588084be ("mtd: parsers: add TP-Link SafeLoader partitions table parser") Signed-off-by: Zilin Guan Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit d473b0677310425bdfb18dadfe061cf597c0fb6a Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:32 2026 -0600 crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails [ Upstream commit 7b85137caf110a09a4a18f00f730de4709f9afc8 ] The hibernate resume sequence involves loading a resume kernel that is just used for loading the hibernate image before shifting back to the existing kernel. During that hibernate resume sequence the resume kernel may have loaded the ccp driver. If this happens the resume kernel will also have called PSP_CMD_TEE_RING_INIT but it will never have called PSP_CMD_TEE_RING_DESTROY. This is problematic because the existing kernel needs to re-initialize the ring. One could argue that the existing kernel should call destroy as part of restore() but there is no guarantee that the resume kernel did or didn't load the ccp driver. There is also no callback opportunity for the resume kernel to destroy before handing back control to the existing kernel. Similar problems could potentially exist with the use of kdump and crash handling. I actually reproduced this issue like this: 1) rmmod ccp 2) hibernate the system 3) resume the system 4) modprobe ccp The resume kernel will have loaded ccp but never destroyed and then when I try to modprobe it fails. Because of these possible cases add a flow that checks the error code from the PSP_CMD_TEE_RING_INIT call and tries to call PSP_CMD_TEE_RING_DESTROY if it failed. If this succeeds then call PSP_CMD_TEE_RING_INIT again. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Acked-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-6-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 90c1858d4e65a89ed175eb063fefa14f9515edd7 Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:31 2026 -0600 crypto: ccp - Factor out ring destroy handling to a helper [ Upstream commit d95f87a65bce5f2f2a02ca6094ca4841d4073df3 ] The ring destroy command needs to be used in multiple places. Split out the code to a helper. Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-5-superm1@kernel.org Signed-off-by: Ilpo Järvinen Stable-dep-of: 7b85137caf11 ("crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails") Signed-off-by: Sasha Levin commit 809fd697dab07b04c43401ea3d26a4b2cbf21789 Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:30 2026 -0600 crypto: ccp - Add an S4 restore flow [ Upstream commit 0ba2035026d0ab6c7c7e65ad8b418dc73d5700d9 ] The system will have lost power during S4. The ring used for TEE communications needs to be initialized before use. Fixes: f892a21f51162 ("crypto: ccp - use generic power management") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Shyam Sundar S K Reviewed-by: Tom Lendacky Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 122c3cb563bd7cd1d5d66d1879db47ae3869ecec Author: Mario Limonciello (AMD) Date: Thu Jan 15 22:11:29 2026 -0600 crypto: ccp - Declare PSP dead if PSP_CMD_TEE_RING_INIT fails [ Upstream commit 5e599d7871bf852e94e8aa08b99724635f2cbf96 ] tee_init_ring() only declares PSP dead if the command times out. If there is any other failure it is still considered fatal though. Set psp_dead for other failures as well. Fixes: 949a0c8dd3c2 ("crypto: ccp - Move direct access to some PSP registers out of TEE") Tested-by: Yijun Shen Signed-off-by: Mario Limonciello (AMD) Acked-by: Tom Lendacky Reviewed-by: Shyam Sundar S K Link: https://patch.msgid.link/20260116041132.153674-3-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 38c30ee6a6263306b01f35d9fa19998f68530fc6 Author: Shyam Sundar S K Date: Thu Jan 15 22:11:28 2026 -0600 platform/x86/amd/pmf: Prevent TEE errors after hibernate [ Upstream commit 48d229c7047128dd52eaf863881bb3e62b5896e5 ] After resuming from hibernate, TEE commands can time out and cause PSP disables. Fix this by reinitializing the Trusted Application (TA) and cancelling the pb workqueue in the hibernate callbacks to avoid these errors. ccp 0000:c4:00.2: tee: command 0x5 timed out, disabling PSP amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 amd-pmf AMDI0107:00: TEE enact cmd failed. err: ffff000e, ret:0 Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Reported-by: Lars Francke Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen Co-developed-by: Patil Rajesh Reddy Signed-off-by: Patil Rajesh Reddy Signed-off-by: Shyam Sundar S K [ML: Add more tags] Signed-off-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260116041132.153674-2-superm1@kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 3d2b60a8d68249ed6e07b3821083b48562eb791d Author: Anthony Pighin (Nokia) Date: Fri Jan 16 15:31:26 2026 +0000 vfio/pci: Lock upstream bridge for vfio_pci_core_disable() [ Upstream commit 962ae6892d8bd208b2d1e2b358f07551ddc8d32f ] The commit 7e89efc6e9e4 ("Lock upstream bridge for pci_reset_function()") added locking of the upstream bridge to the reset function. To catch paths that are not properly locked, the commit 920f6468924f ("Warn on missing cfg_access_lock during secondary bus reset") added a warning if the PCI configuration space was not locked during a secondary bus reset request. When a VFIO PCI device is released from userspace ownership, an attempt to reset the PCI device function may be made. If so, and the upstream bridge is not locked, the release request results in a warning: pcieport 0000:00:00.0: unlocked secondary bus reset via: pci_reset_bus_function+0x188/0x1b8 Add missing upstream bridge locking to vfio_pci_core_disable(). Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()") Signed-off-by: Anthony Pighin Link: https://lore.kernel.org/r/BN0PR08MB695171D3AB759C65B6438B5D838DA@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 12e07451ef98173ebd935e975cca2196b59e64fb Author: Alok Tiwari Date: Fri Dec 19 03:09:30 2025 -0800 mtd: rawnand: cadence: Fix return type of CDMA send-and-wait helper [ Upstream commit 6d8226cbbf124bb5613b532216b74c886a4361b7 ] cadence_nand_cdma_send_and_wait() propagates negative errno values from cadence_nand_cdma_send(), returns -ETIMEDOUT on failure and -EIO when the CDMA engine reports a command failure. However, it is declared as u32, causing error codes to wrap. Change the return type to int to correctly propagate errors. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Alok Tiwari Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 9b67c7fd5bff634e7cdd10ef34b3f2e9f6e15d63 Author: Or Har-Toov Date: Thu Jan 15 14:26:45 2026 +0200 IB/mlx5: Fix port speed query for representors [ Upstream commit 18ea78e2ae83d1d86a72d21d9511927e57e2c0e1 ] When querying speed information for a representor in switchdev mode, the code previously used the first device in the eswitch, which may not match the device that actually owns the representor. In setups such as multi-port eswitch or LAG, this led to incorrect port attributes being reported. Fix this by retrieving the correct core device from the representor's eswitch before querying its port attributes. Fixes: 27f9e0ccb6da ("net/mlx5: Lag, Add single RDMA device in multiport mode") Signed-off-by: Or Har-Toov Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260115-port-speed-query-fix-v2-1-3bde6a3c78e7@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c8fb5c965ac7d0104872a8e4f6451f3bc6328199 Author: Chiara Meiohas Date: Tue Jan 13 15:37:10 2026 +0200 RDMA/mlx5: Fix UMR hang in LAG error state unload [ Upstream commit ebc2164a4cd4314503f1a0c8e7aaf76d7e5fa211 ] During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1]. In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive. Fix this by adding a sys_error notifier that gets registered before MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device(). This ensures error events reach the bond device throughout teardown. [1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40 Fixes: ede132a5cf55 ("RDMA/mlx5: Move events notifier registration to be after device registration") Signed-off-by: Chiara Meiohas Signed-off-by: Maher Sanalla Reviewed-by: Mark Bloch Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260113-umr-hand-lag-fix-v1-1-3dc476e00cd9@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f143ea1ff6bd08bf140dd2d995ef07bb283e26f8 Author: Malaya Kumar Rout Date: Thu Jan 15 15:33:33 2026 +0530 tools/power/x86/intel-speed-select: Fix file descriptor leak in isolate_cpus() [ Upstream commit 56c17ee151c6e1a73d77e15b82a8e2130cd8dd16 ] The file descriptor opened in isolate_cpus() when (!level) is true was not being closed before returning, causing a file descriptor leak in both the error path and the success path. When write() fails at line 950, the function returns at line 953 without closing the file descriptor. Similarly, on success, the function returns at line 956 without closing the file descriptor. Add close(fd) calls before both return statements to fix the resource leak. This follows the same pattern used elsewhere in the same function where file descriptors are properly closed before returning (see lines 1005 and 1027). Fixes: 997074df658e ("tools/power/x86/intel-speed-select: Use cgroup v2 isolation") Signed-off-by: Malaya Kumar Rout Signed-off-by: Srinivas Pandruvada Signed-off-by: Sasha Levin commit 38c5b49fffa1b760959af74f11806eeb3ef4706d Author: Jacob Moroni Date: Mon Jan 12 02:00:06 2026 +0000 RDMA/iwcm: Fix workqueue list corruption by removing work_list [ Upstream commit 7874eeacfa42177565c01d5198726671acf7adf2 ] The commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] Fixes: e1168f09b331 ("RDMA/iwcm: Simplify cm_event_handler()") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260112020006.1352438-1-jmoroni@google.com Reviewed-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ce6f8e007682f378279d4cf83b240f12d52c723b Author: Jiasheng Jiang Date: Mon Jan 12 01:54:12 2026 +0000 RDMA/rxe: Fix double free in rxe_srq_from_init [ Upstream commit 0beefd0e15d962f497aad750b2d5e9c3570b66d1 ] In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. Fixes: aae0484e15f0 ("IB/rxe: avoid srq memory leak") Signed-off-by: Jiasheng Jiang Link: https://patch.msgid.link/20260112015412.29458-1-jiashengjiangcool@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6b644871d4e4610d57ec936ffaa041a141114a3e Author: Roman Penyaev Date: Wed Jan 7 17:15:08 2026 +0100 RDMA/rtrs-srv: fix SG mapping [ Upstream commit 83835f7c07b523c7ca2a5ad0a511670b5810539e ] This fixes the following error on the server side: RTRS server session allocation failed: -EINVAL caused by the caller of the `ib_dma_map_sg()`, which does not expect less mapped entries, than requested, which is in the order of things and can be easily reproduced on the machine with enabled IOMMU. The fix is to treat any positive number of mapped sg entries as a successful mapping and cache DMA addresses by traversing modified SG table. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Roman Penyaev Signed-off-by: Jack Wang Signed-off-by: Grzegorz Prajsner Link: https://patch.msgid.link/20260107161517.56357-2-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 93bdf715d33cf5ee01c58e8546c2469c71ce082a Author: Waqar Hameed Date: Sat Dec 20 23:46:24 2025 +0100 power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed() [ Upstream commit 39fe0eac6d755ef215026518985fcf8de9360e9e ] In `probe()`, `request_irq()` is called before allocating/registering a `power_supply` handle. If an interrupt is fired between the call to `request_irq()` and `power_supply_register()`, the `power_supply` handle will be used uninitialized in `power_supply_changed()` in `wm97xx_bat_update()` (triggered from the interrupt handler). This will lead to a `NULL` pointer dereference since Fix this racy `NULL` pointer dereference by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Since the IRQ is the last thing requests in the `probe()` now, remove the error path for freeing it. Instead add one for unregistering the `power_supply` handle when IRQ request fails. Fixes: 7c87942aef52 ("wm97xx_battery: Use irq to detect charger state") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/97b55f0479a932eea7213844bf66f28a974e27a2.1766270196.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 352e364a56cc4627af429a7579529c3295c6aa76 Author: Haotian Zhang Date: Thu Dec 4 16:34:36 2025 +0800 power: supply: bq27xxx: fix wrong errno when bus ops are unsupported [ Upstream commit 688364a11647dc09ba1e4429313e0008066ec790 ] bq27xxx_write(), bq27xxx_read_block(), and bq27xxx_write_block() return -EPERM when the bus callback pointer is NULL. A NULL callback indicates the operation is not supported by the bus/driver, not that permission is denied. Return -EOPNOTSUPP instead of -EPERM when di->bus.write/ read_bulk/write_bulk is NULL. Fixes: 14073f6614f6 ("power: supply: bq27xxx: Add bulk transfer bus methods") Signed-off-by: Haotian Zhang Reviewed-by: Matt Ranostay Link: https://patch.msgid.link/20251204083436.1367-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e9667db8b17e1fba8974bef6d1f46fbe35c9dbf0 Author: Alexander Koskovich Date: Sun Dec 14 19:16:18 2025 +0000 power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write [ Upstream commit 36b05629226413836cfbb3fbe6689cd188bca156 ] Some platforms expose reboot mode cells that are smaller than an unsigned int, in which cases lead to write failures. Read the cell first to determine actual size and only write the number of bytes the cell can hold. Fixes: 7a78a7f7695b ("power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface") Signed-off-by: Alexander Koskovich Link: https://patch.msgid.link/20251214191529.2470580-1-akoskovich@pm.me Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 82d3eb97a976c9d56bb92b241397610e57a9c629 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: sbs-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 8d59cf3887fbabacef53bfba473e33e8a8d9d07b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Keep the old behavior of just printing a warning in case of any failures during the IRQ request and finishing the probe successfully. Fixes: d2cec82c2880 ("power: sbs-battery: Request threaded irq and fix dev callback cookie") Signed-off-by: Waqar Hameed Reviewed-by: Phil Reid Link: https://patch.msgid.link/0ef896e002495e615157b482d18a437af19ddcd0.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2178dc65d45e2f7bcaa8af8d80d100419bdab251 Author: Waqar Hameed Date: Sat Dec 20 23:36:02 2025 +0100 power: supply: rt9455: Fix use-after-free in power_supply_changed() [ Upstream commit e2febe375e5ea5afed92f4cd9711bde8f24ee6d2 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/1567d831e04c3e2fcb9e18dd36b7bcba4634581a.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit dbe579e620ef0f53db490ec79a8566e4ea8918ac Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed() [ Upstream commit b7508129978ae1e2ed9b0410396abc05def9c4eb ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: f8d7a3d21160 ("power: supply: Add driver for pm8916 lbc") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/64d8dd3675a4e59fa32c3e0ef451f12d1f7ed18f.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b69bb88e20c6f8e998dff3e13a316207f49d3fa2 Author: Waqar Hameed Date: Sat Dec 20 23:36:01 2025 +0100 power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() [ Upstream commit 62914959b35e9a1e29cc0f64cb8cfc5075a5366f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 098bce1838e0 ("power: supply: Add pm8916 VM-BMS support") Signed-off-by: Waqar Hameed Reviewed-by: Nikita Travkin Link: https://patch.msgid.link/2749c09ff81fcac87ae48147e216135450d8c067.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4350505e82b4f972ddb788e1c712c557c38859d0 Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: goldfish: Fix use-after-free in power_supply_changed() [ Upstream commit b2ce982e2e0c888dc55c888ad0e20ea04daf2e6b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 84d7b7687489 ("power: Add battery driver for goldfish emulator") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/500a606bb6fb6f2bb8d797e19a00cea9dd7b03c1.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit f3fbe309c9bfe1aac1e2b26543e9dc4829f3275a Author: Waqar Hameed Date: Sat Dec 20 23:36:00 2025 +0100 power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() [ Upstream commit 642f33e34b969eedec334738fd5df95d2dc42742 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 874b2adbed12 ("power: supply: cpcap-battery: Add a battery driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/81db58d610c9a51a68184f856cd431a934cccee2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4aeaf03c17260415c2fdd55992f9ad4188d5455a Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq25980: Fix use-after-free in power_supply_changed() [ Upstream commit 5f0b1cb41906e86b64bf69f5ededb83b0d757c27 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx family") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/8763035cadb959e14787b3837f2d3db61f6e1c34.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 83c27fdd696ac13d023ef7a0345301be93209c53 Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: bq256xx: Fix use-after-free in power_supply_changed() [ Upstream commit 8005843369723d9c8975b7c4202d1b85d6125302 ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/39da6da8cc060fa0382ca859f65071e791cb6119.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 76a42ba547a9b2e2337894f67a4d9247445007d5 Author: Waqar Hameed Date: Sat Dec 20 23:35:59 2025 +0100 power: supply: act8945a: Fix use-after-free in power_supply_changed() [ Upstream commit 3291c51d4684d048dd2eb91b5b65fcfdaf72141f ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: a09209acd6a8 ("power: supply: act8945a_charger: Add status change update support") Signed-off-by: Waqar Hameed Link: https://patch.msgid.link/bcf3a23b5187df0bba54a8c8fe09f8b8a0031dee.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 847eeb6c0efcd76c7def73857cf798a4fcd8f79b Author: Waqar Hameed Date: Sat Dec 20 23:35:58 2025 +0100 power: supply: ab8500: Fix use-after-free in power_supply_changed() [ Upstream commit c4af8a98bb52825a5331ae1d0604c0ea6956ba4b ] Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") introduced this issue during a refactorization. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") Signed-off-by: Waqar Hameed Reviewed-by: Linus Walleij Link: https://patch.msgid.link/ccf83a09942cb8dda3dff70b2682f2c2e9cb97f2.1766268280.git.waqar.hameed@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7ac44096bad012562d7fa9e00e06d71eb696d0c5 Author: Chengchang Tang Date: Sun Jan 4 14:40:57 2026 +0800 RDMA/hns: Notify ULP of remaining soft-WCs during reset [ Upstream commit 0789f929900d85b80b343c5f04f8b9444e991384 ] During a reset, software-generated WCs cannot be reported via interrupts. This may cause the ULP to miss some WCs. To avoid this, add check in the CQ arm process: if a hardware reset has occurred and there are still unreported soft-WCs, notify the ULP to handle the remaining WCs, thereby preventing any loss of completions. Fixes: 626903e9355b ("RDMA/hns: Add support for reporting wc as software mode") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c3c45f367981e4f00a87b11a4ab5415e0e3cdeaa Author: Junxian Huang Date: Sun Jan 4 14:40:56 2026 +0800 RDMA/hns: Fix RoCEv1 failure due to DSCP [ Upstream commit 84bd5d60f0a2b9c763c5e6d0b3d8f4f61f6c5470 ] DSCP is not supported in RoCEv1, but get_dscp() is still called. If get_dscp() returns an error, it'll eventually cause create_ah to fail even when using RoCEv1. Correct the return value and avoid calling get_dscp() when using RoCEv1. Fixes: ee20cc17e9d8 ("RDMA/hns: Support DSCP") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 562c96b1393da2df3ea62173c84117b39da353b9 Author: Chengchang Tang Date: Sun Jan 4 14:40:54 2026 +0800 RDMA/hns: Fix WQ_MEM_RECLAIM warning [ Upstream commit c0a26bbd3f99b7b03f072e3409aff4e6ec8af6f6 ] When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma] is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle [hns_roce_hw_v2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144 Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20260104064057.1582216-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2adc6c08f960045e40e6a64ace1609533bdbc446 Author: Etienne AUJAMES Date: Wed Dec 31 14:07:45 2025 +0100 IB/cache: update gid cache on client reregister event [ Upstream commit ddd6c8c873e912cb1ead79def54de5e24ff71c80 ] Some HCAs (e.g: ConnectX4) do not trigger a IB_EVENT_GID_CHANGE on subnet prefix update from SM (PortInfo). Since the commit d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events"), the GID cache is updated exclusively on IB_EVENT_GID_CHANGE. If this event is not emitted, the subnet prefix in the IPoIB interface’s hardware address remains set to its default value (0xfe80000000000000). Then rdma_bind_addr() failed because it relies on hardware address to find the port GID (subnet_prefix + port GUID). This patch fixes this issue by updating the GID cache on IB_EVENT_CLIENT_REREGISTER event (emitted on PortInfo::ClientReregister=1). Fixes: d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events") Signed-off-by: Etienne AUJAMES Link: https://patch.msgid.link/aVUfsO58QIDn5bGX@eaujamesFR0130 Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 46ccb0a0f95069b5783420abbcd72e7101e95a82 Author: Honggang LI Date: Wed Dec 24 10:38:19 2025 +0800 RDMA/rtrs: server: remove dead code [ Upstream commit a3572bdc3a028ca47f77d7166ac95b719cf77d50 ] As rkey had been initialized to zero, the WARN_ON_ONCE should never been triggered. Remove it. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Honggang LI Link: https://patch.msgid.link/20251224023819.138846-1-honggangli@163.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6d59928f8b0ecdd4aea3c438431486ea95c138bd Author: Hariprasad Kelam Date: Fri Feb 6 23:56:45 2026 +0530 octeontx2-pf: Unregister devlink on probe failure [ Upstream commit 943f3b8bfbf297cf74392b50a7108ce1fe4cbd8c ] When probe fails after devlink registration, the missing devlink unregister call causing a memory leak. Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count") Signed-off-by: Hariprasad Kelam Link: https://patch.msgid.link/20260206182645.4032737-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 193a9e2d4d181f09a77cd3c544a04d343f527c6a Author: Eric Joyner Date: Fri Feb 6 14:46:51 2026 -0800 ionic: Rate limit unknown xcvr type messages [ Upstream commit cdb1634de3bf197c0d86487d1fb84c128a79cc7c ] Running ethtool repeatedly with a transceiver unknown to the driver or firmware will cause the driver to spam the kernel logs with "unknown xcvr type" messages which can distract from real issues; and this isn't interesting information outside of debugging. Fix this by rate limiting the output so that there are still notifications but not so many that they flood the log. Using dev_dbg_once() would reduce the number of messages further, but this would miss the case where a different unknown transceiver type is plugged in, and its status is requested. Fixes: 4d03e00a2140 ("ionic: Add initial ethtool support") Signed-off-by: Eric Joyner Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260206224651.1491-1-eric.joyner@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63692055743e8b3f65d0a165a6bbb561a06cd4ed Author: Vimlesh Kumar Date: Fri Feb 6 11:15:08 2026 +0000 octeon_ep_vf: ensure dbell BADDR updation [ Upstream commit 484e834d53cffa91c311631271f83130cf6e9e7c ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 2c0c32c72be29 ("octeon_ep_vf: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-4-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 530a79f0589ce4d2525699a8304b80ad3c45d999 Author: Vimlesh Kumar Date: Fri Feb 6 11:15:07 2026 +0000 octeon_ep: ensure dbell BADDR updation [ Upstream commit ce8fe3fc4f99efd872120301c0f72f2e90ab9769 ] Make sure the OUT DBELL base address reflects the latest values written to it. Fix: Add a wait until the OUT DBELL base address register is updated with the DMA ring descriptor address, and modify the setup_oq function to properly handle failures. Fixes: 0807dc76f3bf5 ("octeon_ep: support Octeon CN10K devices") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-3-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2286bfef336813397ce19ff7663d81680e455d96 Author: Vimlesh Kumar Date: Fri Feb 6 11:15:06 2026 +0000 octeon_ep: disable per ring interrupts [ Upstream commit 73e6ffa37cebee152c07c5f2b8bc70fd2899ea6e ] Disable the MSI-X per ring interrupt for every PF ring when PF netdev goes down. Fixes: 1f2c2d0cee023 ("octeon_ep: add hardware configuration APIs") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260206111510.1045092-2-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 52731ef4438155cea782fac74e547a327ab9e7c5 Author: Jiayuan Chen Date: Fri Feb 6 15:44:44 2026 +0800 serial: caif: fix use-after-free in caif_serial ldisc_close() [ Upstream commit 308e7e4d0a846359685f40aade023aee7b27284c ] There is a use-after-free bug in caif_serial where handle_tx() may access ser->tty after the tty has been freed. The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice() The root cause is that tty_kref_put() is called in ldisc_close() while the network device is still active and can receive packets. Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldisc_open and freed in ser_release via unregister_netdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to ser_release() where the network device is unregistered. Fix this by moving tty_kref_put() from ldisc_close() to ser_release(), after unregister_netdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF. Note: We save ser->tty before unregister_netdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needs_free_netdev = true). How to reproduce: Add mdelay(500) at the beginning of ldisc_close() to widen the race window, then run the reproducer program [1]. Note: There is a separate deadloop issue in handle_tx() when using PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uart_write_room() and uart_write() in serial core. It has been addressed in a separate patch [2]. KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7 Allocated by task 9930: Freed by task 64: Last potentially related work creation: The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800) The buggy address belongs to the physical page: page_owner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace: Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u Reported-by: syzbot+827272712bd6d12c79a4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000a4a7550611e234f5@google.com/T/ Fixes: 56e0ef527b18 ("drivers/net: caif: fix wrong rtnl_is_locked() usage") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiayuan Chen Reviewed-by: Jijie Shao Link: https://patch.msgid.link/20260206074450.154267-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b04061f89ffc6168e7ec3c71d0086ec3c3797228 Author: Jiayuan Chen Date: Fri Feb 6 13:02:19 2026 +0800 xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path [ Upstream commit 81b84de32bb27ae1ae2eb9acf0420e9d0d14bf00 ] icmp_route_lookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies. The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrm_lookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup 6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag The bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and ip_route_input() call (e.g., due to concurrent "ip addr add"), ip_route_input() returns a LOCAL route with dst.output set to ip_rt_bug. This route is then used for ICMP output, causing dst_output() to call ip_rt_bug(), triggering a WARN_ON: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ... Fix this by checking rt2->rt_type after ip_route_input(). If it's RTN_LOCAL, the route cannot be used for output, so treat it as an error. The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at: https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81 Reported-by: syzbot+e738404dcd14b620923c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000b1060905eada8881@google.com/T/ Closes: https://lore.kernel.org/r/20260128090523.356953-1-jiayuan.chen@linux.dev Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260206050220.59642-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 35e00df60f7e7655c1a850282b58490ad00fb656 Author: Stanislav Fomichev Date: Mon Aug 18 08:40:29 2025 -0700 net: Switch to skb_dstref_steal/skb_dstref_restore for ip_route_input callers [ Upstream commit e97e6a1830ddb5885ba312e56b6fa3aa39b5f47e ] Going forward skb_dst_set will assert that skb dst_entry is empty during skb_dst_set. skb_dstref_steal is added to reset existing entry without doing refcnt. skb_dstref_restore should be used to restore the previous entry. Convert icmp_route_lookup and ip_options_rcv_srr to these helpers. Add extra call to skb_dstref_reset to icmp_route_lookup to clear the ip_route_input entry. Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20250818154032.3173645-5-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 81b84de32bb2 ("xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path") Signed-off-by: Sasha Levin commit 791f028b1e42e2c5b0c7128a72cc159af557b306 Author: Stanislav Fomichev Date: Mon Aug 18 08:40:26 2025 -0700 net: Add skb_dstref_steal and skb_dstref_restore [ Upstream commit c3f0c02997c7f8489fec259e28e0e04e9811edac ] Going forward skb_dst_set will assert that skb dst_entry is empty during skb_dst_set to prevent potential leaks. There are few places that still manually manage dst_entry not using the helpers. Convert them to the following new helpers: - skb_dstref_steal that resets dst_entry and returns previous dst_entry value - skb_dstref_restore that restores dst_entry previously reset via skb_dstref_steal Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20250818154032.3173645-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 81b84de32bb2 ("xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path") Signed-off-by: Sasha Levin commit b89269bdb3bae5cdcc23203e36000e138e07df89 Author: René Rebe Date: Thu Feb 5 17:09:59 2026 +0100 net: sunhme: Fix sbus regression [ Upstream commit 8c5d17834ec104d0abd1bda52fbc04e647fab274 ] Commit cc216e4b44ce ("net: sunhme: Switch SBUS to devres") changed explicit sized of_ioremap with BMAC_REG_SIZEs to devm_platform_ioremap_resource mapping all the resource. However, this does not work on my Sun Ultra 2 with SBUS HMEs: hme f0072f38: error -EBUSY: can't request region for resource [mem 0x1ffe8c07000-0x1ffe8c0701f] hme f0072f38: Cannot map TCVR registers. hme f0072f38: probe with driver hme failed with error -16 hme f007ab44: error -EBUSY: can't request region for resource [mem 0x1ff28c07000-0x1ff28c0701f] hme f007ab44: Cannot map TCVR registers. hme f007ab44: probe with driver hme failed with error -16 Turns out the open-firmware resources overlap, at least on this machines and PROM version: hexdump /proc/device-tree/sbus@1f,0/SUNW,hme@2,8c00000/reg: 00 00 00 02 08 c0 00 00 00 00 01 08 00 00 00 02 08 c0 20 00 00 00 20 00 00 00 00 02 08 c0 40 00 00 00 20 00 00 00 00 02 08 c0 60 00 00 00 20 00 00 00 00 02 08 c0 70 00 00 00 00 20 And the driver previously explicitly mapped way smaller mmio regions: /proc/iomem: 1ff28c00000-1ff28c00107 : HME Global Regs 1ff28c02000-1ff28c02033 : HME TX Regs 1ff28c04000-1ff28c0401f : HME RX Regs 1ff28c06000-1ff28c0635f : HME BIGMAC Regs 1ff28c07000-1ff28c0701f : HME Tranceiver Regs Quirk this specific issue by truncating the previous resource to not overlap into the TCVR registers. Fixes: cc216e4b44ce ("net: sunhme: Switch SBUS to devres") Signed-off-by: René Rebe Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260205.170959.89574674688839340.rene@exactco.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 21c303fec138c002f90ed33bce60e807d53072bb Author: Jiayuan Chen Date: Thu Feb 5 17:54:51 2026 +0800 net: atm: fix crash due to unvalidated vcc pointer in sigd_send() [ Upstream commit ae88a5d2f29b69819dc7b04086734439d074a643 ] Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+1f22cb1769f249df9fa0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69039850.a70a0220.5b2ed.005d.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260205095501.131890-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e99f816a424e5941deae513f8734a9087deed6ce Author: Stefan Metzmacher Date: Thu Feb 5 17:14:14 2026 +0100 smb: client: correct value for smbd_max_fragmented_recv_size [ Upstream commit 4a93d1ee2d0206970b6eb13fbffe07938cd95948 ] When we download a file without rdma offload or get a large directly enumeration from the server, the server might want to send up to smbd_max_fragmented_recv_size bytes, but if it is too large all our recv buffers might already be moved to the recv_io.reassembly.list and we're no longer able to grant recv credits. The maximum fragmented upper-layer payload receive size supported Assume max_payload_per_credit is smbd_max_receive_size - 24 = 1340 The maximum number would be smbd_receive_credit_max * max_payload_per_credit 1340 * 255 = 341700 (0x536C4) The minimum value from the spec is 131072 (0x20000) For now we use the logic we used in ksmbd before: (1364 * 255) / 2 = 173910 (0x2A756) Fixes: 03bee01d6215 ("CIFS: SMBD: Add SMB Direct protocol initial values and constants") Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Namjae Jeon Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 73ec7c96601d61d52310c659145bb06d933a0fa6 Author: Jinliang Zheng Date: Wed Jan 28 16:30:07 2026 +0800 procfs: fix missing RCU protection when reading real_parent in do_task_stat() [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng Acked-by: Oleg Nesterov Cc: David Hildenbrand Cc: Ingo Molnar Cc: Lorenzo Stoakes Cc: Mateusz Guzik Cc: ruippan Cc: Usama Arif Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d2c785733dfb853ea0b53984c75662a1af230a94 Author: Jian Shen Date: Thu Feb 5 20:17:19 2026 +0800 net: hns3: fix double free issue for tx spare buffer [ Upstream commit 6d2f142b1e4b203387a92519d9d2e34752a79dbb ] In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers. Fixes: 907676b130711 ("net: hns3: use tx bounce buffer for small packets") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260205121719.3285730-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5cd63214b529599089532b33863461a5e0c05791 Author: Nicolas Cavallari Date: Mon Jan 19 17:08:33 2026 +0100 PCI: Add ACS quirk for Pericom PI7C9X2G404 switches [12d8:b404] [ Upstream commit 5907a90551e9f7968781f3a6ab8684458959beb3 ] 12d8:b404 is apparently another PCI ID for Pericom PI7C9X2G404 (as identified by the chip silkscreen and lspci). It is also affected by the PI7C9X2G errata (e.g. a network card attached to it fails under load when P2P Redirect Request is enabled), so apply the same quirk to this PCI ID too. PCI bridge [0604]: Pericom Semiconductor PI7C9X2G404 EV/SV PCIe2 4-Port/4-Lane Packet Switch [12d8:b404] (rev 01) Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Closes: https://lore.kernel.org/all/a1d926f0-4cb5-4877-a4df-617902648d80@green-communications.fr/ Signed-off-by: Nicolas Cavallari Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119160915.26456-1-nicolas.cavallari@green-communications.fr Signed-off-by: Sasha Levin commit 05feaf826390fd16f1deb89dd9412def3b2a280f Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:44 2026 +0100 netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets [ Upstream commit 4780ec142cbb24b794129d3080eee5cac2943ffc ] Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. Fixes: c9e6978e2725 ("netfilter: nft_set_rbtree: Switch to node list walk for overlap detection") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit afe1a28fa9de3f6c5fb2ccfc67c177f7a94caf49 Author: Pablo Neira Ayuso Date: Fri Feb 6 13:33:43 2026 +0100 netfilter: nft_set_rbtree: fix bogus EEXIST with NLM_F_CREATE with null interval [ Upstream commit 7f9203f41aae8eea74fba6a3370da41332eabcda ] Userspace adds a non-matching null element to the kernel for historical reasons. This null element is added when the set is populated with elements. Inclusion of this element is conditional, therefore, userspace needs to dump the set content to check for its presence. If the NLM_F_CREATE flag is turned on, this becomes an issue because kernel bogusly reports EEXIST. Add special case to ignore NLM_F_CREATE in this case, therefore, re-adding the nul-element never fails. Fixes: c016c7e45ddf ("netfilter: nf_tables: honor NLM_F_EXCL flag in set element insertion") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 4f899976eedc10b12947affe37475904b3ef22cf Author: Anders Grahn Date: Tue Feb 3 14:48:30 2026 +0100 netfilter: nft_counter: fix reset of counters on 32bit archs [ Upstream commit 1e13f27e0675552161ab1778be9a23a636dde8a7 ] nft_counter_reset() calls u64_stats_add() with a negative value to reset the counter. This will work on 64bit archs, hence the negative value added will wrap as a 64bit value which then can wrap the stat counter as well. On 32bit archs, the added negative value will wrap as a 32bit value and _not_ wrapping the stat counter properly. In most cases, this would just lead to a very large 32bit value being added to the stat counter. Fix by introducing u64_stats_sub(). Fixes: 4a1d3acd6ea8 ("netfilter: nft_counter: Use u64_stats_t for statistic.") Signed-off-by: Anders Grahn Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bce4581e02d53f44428c0d5af8273fd7e26d2699 Author: Florian Westphal Date: Tue Jan 27 20:13:45 2026 +0100 netfilter: nft_set_hash: fix get operation on big endian [ Upstream commit 2f635adbe2642d398a0be3ab245accd2987be0c3 ] tests/shell/testcases/packetpath/set_match_nomatch_hash_fast fails on big endian with: Error: Could not process rule: No such file or directory reset element ip test s { 244.147.90.126 } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fatal: Cannot fetch element "244.147.90.126" ... because the wrong bucket is searched, jhash() and jhash1_word are not interchangeable on big endian. Fixes: 3b02b0adc242 ("netfilter: nft_set_hash: fix lookups with fixed size hash on big endian") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 79b713ef4261a8ead96af4703f89d0b5f25532e2 Author: Florian Westphal Date: Thu Nov 20 17:17:06 2025 +0100 netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation [ Upstream commit 207b3ebacb6113acaaec0d171d5307032c690004 ] Ulrich reports a regression with nfqueue: If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment(). Move the check so that its peformed vs. the aggregated packet. Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time. For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry. While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries. This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO. Next patch adds a udpgro test case to cover this scenario. Reported-by: Ulrich Weber Fixes: 7d8dc1c7be8d ("netfilter: nf_queue: drop packets with cloned unconfirmed conntracks") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 371de2bef6582a3f58049b3d18e190924af9c9a0 Author: Scott Mitchell Date: Fri Jan 23 14:09:30 2026 -0800 netfilter: nfnetlink_queue: optimize verdict lookup with hash table [ Upstream commit e19079adcd26a25d7d3e586b1837493361fdf8b6 ] The current implementation uses a linear list to find queued packets by ID when processing verdicts from userspace. With large queue depths and out-of-order verdicting, this O(n) lookup becomes a significant bottleneck, causing userspace verdict processing to dominate CPU time. Replace the linear search with a hash table for O(1) average-case packet lookup by ID. A global rhashtable spanning all network namespaces attributes hash bucket memory to kernel but is subject to fixed upper bound. Signed-off-by: Scott Mitchell Signed-off-by: Florian Westphal Stable-dep-of: 207b3ebacb61 ("netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation") Signed-off-by: Sasha Levin commit cf70cedce327833296ebe6043364d1e44b76a2ab Author: Votokina Victoria Date: Tue Feb 3 14:31:57 2026 +0300 nfc: hci: shdlc: Stop timers and work before freeing context [ Upstream commit c9efde1e537baed7648a94022b43836a348a074f ] llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc structure while its timers and state machine work may still be active. Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state and the skb queues. If teardown happens in parallel with a queued/running work item, it can lead to UAF and other shutdown races. Stop all SHDLC timers and cancel sm_work synchronously before purging the queues and freeing the context. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4a61cd6687fc ("NFC: Add an shdlc llc module to llc core") Signed-off-by: Votokina Victoria Link: https://patch.msgid.link/20260203113158.2008723-1-Victoria.Votokina@kaspersky.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19e42490c89bac9a388f28179e66bebbef350f99 Author: Eric Dumazet Date: Tue Feb 3 19:25:09 2026 +0000 inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP [ Upstream commit c89477ad79446867394360b29bb801010fc3ff22 ] Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST") pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner "man 7 raw" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yizhou Zhao Link: https://lore.kernel.org/netdev/20251109134600.292125-1-zhaoyz24@mails.tsinghua.edu.cn/ Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260203192509.682208-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit da637d725a1169a476181bdaa26971c2b4bb1bd5 Author: Thomas Bogendoerfer Date: Tue Feb 3 15:11:52 2026 +0100 bonding: only set speed/duplex to unknown, if getting speed failed [ Upstream commit 48dec8d88af96039a4a17b8c2f148f2a4066e195 ] bond_update_speed_duplex() first set speed/duplex to unknown and then asks slave driver for current speed/duplex. Since getting speed/duplex might take longer there is a race, where this false state is visible by /proc/net/bonding. With commit 691b2bf14946 ("bonding: update port speed when getting bond speed") this race gets more visible, if user space is calling ethtool on a regular base. Fix this by only setting speed/duplex to unknown, if link speed is really unknown/unusable. Fixes: 98f41f694f46 ("bonding:update speed/duplex for NETDEV_CHANGE") Signed-off-by: Thomas Bogendoerfer Acked-by: Jay Vosburgh Reviewed-by: Nikolay Aleksandrov Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260203141153.51581-1-tbogendoerfer@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d56ba306e93d04696718963fb4cda2883ee7585 Author: Anshumali Gaur Date: Tue Feb 3 10:37:01 2026 +0530 octeontx2-af: Fix PF driver crash with kexec kernel booting [ Upstream commit 2d2d574309e3ae84ee794869a5da8b4c38753a94 ] During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec. Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver") Signed-off-by: Anshumali Gaur Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260203050701.2616685-1-agaur@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73db8a61af8b25dd0e99a8de52d545190829c690 Author: Paolo Abeni Date: Tue Feb 3 19:41:18 2026 +0100 mptcp: fix receive space timestamp initialization [ Upstream commit 70274765fef555af92a1532d5bd5450c691fca9d ] MPTCP initialize the receive buffer stamp in mptcp_rcv_space_init(), using the provided subflow stamp. Such helper is invoked in several places; for passive sockets, space init happened at clone time. In such scenario, MPTCP ends-up accesses the subflow stamp before its initialization, leading to quite randomic timing for the first receive buffer auto-tune event, as the timestamp for newly created subflow is not refreshed there. Fix the issue moving the stamp initialization out of the mentioned helper, at the data transfer start, and always using a fresh timestamp. Fixes: 013e3179dbd2 ("mptcp: fix rcv space initialization") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260203-net-next-mptcp-misc-feat-6-20-v1-2-31ec8bfc56d1@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f5433b23e2a4e4dc856c7d8c749ca47560f7494 Author: Tuo Li Date: Mon Jan 5 15:14:38 2026 +0800 of: unittest: fix possible null-pointer dereferences in of_unittest_property_copy() [ Upstream commit d289cb7fcefe41a54d8f9c6d0e0947f5f82b15c6 ] This function first duplicates p1 and p2 into new, and then checks whether the duplication succeeds. However, if the duplication fails (e.g., kzalloc() returns NULL in __of_prop_dup()), new will be NULL but is still dereferenced in __of_prop_free(). To ensure that the unit test continues to run even when duplication fails, add a NULL check before calling __of_prop_free(). Fixes: 1c5e3d9bf33b ("of: Add a helper to free property struct") Signed-off-by: Tuo Li Link: https://patch.msgid.link/20260105071438.156186-1-islituo@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 530d1ecd3639b1b4dc38aef11237d5424e50c0a5 Author: Ondrej Mosnacek Date: Thu Jan 22 15:07:45 2026 +0100 ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit() [ Upstream commit 0895a000e4fff9e950a7894210db45973e485c35 ] The user.* sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_SYS_RESOURCE capability (at most rwx if capable, at most r-- if not). The capability is being checked unconditionally, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. Given the logic in the set_permissions() function in kernel/ucount.c and the unfortunate way the permission checking is implemented, it doesn't seem viable to avoid false positive denials by deferring the capability check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never logs an audit record. Link: https://lkml.kernel.org/r/20260122140745.239428-1-omosnace@redhat.com Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Acked-by: Serge Hallyn Cc: Eric Biederman Cc: Alexey Gladkov Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d075cf169e8252c64d02e875793de06f49ce221a Author: Ondrej Mosnacek Date: Thu Jan 22 15:13:03 2026 +0100 ipc: don't audit capability check in ipc_permissions() [ Upstream commit 071588136007482d70fd2667b827036bc60b1f8f ] The IPC sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_CHECKPOINT_RESTORE capability, which is being checked regardless of whether any access is actually denied or not, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. It wouldn't be viable to restructure the sysctl permission logic to only check the capability when the access would be actually denied if it's not granted. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never emits an audit record. Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time") Signed-off-by: Ondrej Mosnacek Acked-by: Alexey Gladkov Acked-by: Serge Hallyn Signed-off-by: Serge Hallyn Stable-dep-of: 8924336531e2 ("ipc: don't audit capability check in ipc_permissions()") Signed-off-by: Sasha Levin commit a4720c30ea7726f8022a65f38312b3b3a9cb0071 Author: Siddarth G Date: Thu Apr 3 15:43:45 2025 +0530 selftests/mm: convert page_size to unsigned long [ Upstream commit 0bf19a357e0eaf03e757ac9482c45a797e40157a ] Cppcheck warning: int result is assigned to long long variable. If the variable is long long to avoid loss of information, then you have loss of information. This patch changes the type of page_size from 'unsigned int' to 'unsigned long' instead of using ULL suffixes. Changing hpage_size to 'unsigned long' was considered, but since gethugepage() expects an int, this change was avoided. Link: https://lkml.kernel.org/r/20250403101345.29226-1-siddarthsgml@gmail.com Signed-off-by: Siddarth G Reported-by: David Binderman Closes: https://lore.kernel.org/all/AS8PR02MB10217315060BBFDB21F19643E9CA62@AS8PR02MB10217.eurprd02.prod.outlook.com/ Signed-off-by: Andrew Morton Stable-dep-of: 7e938f00b003 ("selftests/mm: fix faulting-in code in pagemap_ioctl test") Signed-off-by: Sasha Levin commit 306c11e7b82e5e3063f3107304e055a7ef8d59e3 Author: Muhammad Usama Anjum Date: Mon Dec 9 23:56:22 2024 +0500 selftests/mm: pagemap_ioctl: Fix types mismatches shown by compiler options [ Upstream commit 43448e5bbbad1fb168b728b8a7c0058ab1397375 ] Fix following warnings caught by compiler: - There are several type mismatches among different variables. - Remove unused variable warnings. Link: https://lkml.kernel.org/r/20241209185624.2245158-3-usama.anjum@collabora.com Signed-off-by: Muhammad Usama Anjum Signed-off-by: Andrew Morton Stable-dep-of: 7e938f00b003 ("selftests/mm: fix faulting-in code in pagemap_ioctl test") Signed-off-by: Sasha Levin commit 3f3dc0663ca11cc353ee7c35d1cf01e072e10b98 Author: Håkon Bugge Date: Thu Jan 29 18:52:33 2026 +0100 PCI/ACPI: Restrict program_hpx_type2() to AER bits [ Upstream commit 9abf79c8d7b40db0e5a34aa8c744ea60ff9a3fcf ] Previously program_hpx_type2() applied PCIe settings unconditionally, which could incorrectly change bits like Extended Tag Field Enable and Enable Relaxed Ordering. When _HPX was added to ACPI r3.0, the intent of the PCIe Setting Record (Type 2) in sec 6.2.7.3 was to configure AER registers when the OS does not own the AER Capability: The PCI Express setting record contains ... [the AER] Uncorrectable Error Mask, Uncorrectable Error Severity, Correctable Error Mask ... to be used when configuring registers in the Advanced Error Reporting Extended Capability Structure ... OSPM [1] will only evaluate _HPX with Setting Record – Type 2 if OSPM is not controlling the PCI Express Advanced Error Reporting capability. ACPI r3.0b, sec 6.2.7.3, added more AER registers, including registers in the PCIe Capability with AER-related bits, and the restriction that the OS use this only when it owns PCIe native hotplug: ... when configuring PCI Express registers in the Advanced Error Reporting Extended Capability Structure *or PCI Express Capability Structure* ... An OS that has assumed ownership of native hot plug but does not ... have ownership of the AER register set must use ... the Type 2 record to program the AER registers ... However, since the Type 2 record also includes register bits that have functions other than AER, the OS must ignore values ... that are not applicable. Restrict program_hpx_type2() to only the intended purpose: - Apply settings only when OS owns PCIe native hotplug but not AER, - Only touch the AER-related bits (Error Reporting Enables) in Device Control - Don't touch Link Control at all, since nothing there seems AER-related, but log _HPX settings for debugging purposes Note that Read Completion Boundary is now configured elsewhere, since it is unrelated to _HPX. [1] Operating System-directed configuration and Power Management Fixes: 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-3-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit 7d168610e727453d05743479f8ac590dffe616ae Author: Ilpo Järvinen Date: Fri Aug 29 16:11:00 2025 +0300 PCI: Add defines for bridge window indexing [ Upstream commit e4934832c588f72bcc139d3ca0acc490c63a821c ] include/linux/pci.h provides PCI_BRIDGE_{IO,MEM,PREF_MEM}_WINDOW defines, however, they're based on the resource array indexing in the pci_dev struct. The struct pci_bus also has pointers to those same resources but they start from zeroth index. Add PCI_BUS_BRIDGE_{IO,MEM,PREF_MEM}_WINDOW defines to get rid of literal indexing. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-12-ilpo.jarvinen@linux.intel.com Stable-dep-of: 9abf79c8d7b4 ("PCI/ACPI: Restrict program_hpx_type2() to AER bits") Signed-off-by: Sasha Levin commit f68179cc3d88455f67de5fd3b7808f7b43394171 Author: Håkon Bugge Date: Thu Jan 29 18:52:32 2026 +0100 PCI: Initialize RCB from pci_configure_device() [ Upstream commit 1a6845aaa6de81f95959b380b45de8f10d6a8502 ] Commit e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") worked around a bogus _HPX type 2 record, which caused program_hpx_type2() to set the RCB in an endpoint even though the Root Port did not have the RCB bit set. e42010d8207f fixed that by setting the RCB in the endpoint only when it was set in the Root Port. In retrospect, program_hpx_type2() is intended for AER-related settings, and the RCB should be configured elsewhere so it doesn't depend on the presence or contents of an _HPX record. Explicitly program the RCB from pci_configure_device() so it matches the Root Port's RCB. The Root Port may not be visible to virtualized guests; in that case, leave RCB alone. Fixes: e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260129175237.727059-2-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit ef04714ef4aecf2950fca2a7a8f3754ef32d9360 Author: Ziyi Guo Date: Fri Jan 23 04:58:22 2026 +0000 wifi: ath10k: sdio: add missing lock protection in ath10k_sdio_fw_crashed_dump() [ Upstream commit e55ac348089e579fc224569c7bd90340bf2439f9 ] ath10k_sdio_fw_crashed_dump() calls ath10k_coredump_new() which requires ar->dump_mutex to be held, as indicated by lockdep_assert_held() in that function. However, the SDIO implementation does not acquire this lock, unlike the PCI and SNOC implementations which properly hold the mutex. Additionally, ar->stats.fw_crash_counter is documented as protected by ar->data_lock in core.h, but the SDIO implementation modifies it without holding this spinlock. Add the missing mutex_lock()/mutex_unlock() around the coredump operations, and add spin_lock_bh()/spin_unlock_bh() around the fw_crash_counter increment, following the pattern used in ath10k_pci_fw_dump_work() and ath10k_snoc_fw_crashed_dump(). Fixes: 3c45f21af84e ("ath10k: sdio: add firmware coredump support") Signed-off-by: Ziyi Guo Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260123045822.2221549-1-n7l8m4@u.northwestern.edu Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0f514a9bf432eaf3bac2c678529146c032a3bef4 Author: Sergey Shtylyov Date: Tue Jan 27 23:39:42 2026 +0300 PCI: Check parent for NULL in of_pci_bus_release_domain_nr() [ Upstream commit f7245901de8978d829f80b3d8e36ed9a8fd18049 ] of_pci_bus_find_domain_nr() allows its parent parameter to be NULL but of_pci_bus_release_domain_nr() (that undoes its effect) doesn't -- that means it's going to blow up while calling of_get_pci_domain_nr() if the parent parameter indeed happens to be NULL. Add the missing NULL check. Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") Signed-off-by: Sergey Shtylyov Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260127203944.28588-1-s.shtylyov@auroraos.dev Signed-off-by: Sasha Levin commit f4a681c870d10a929e266c3a24c43f91ef830440 Author: Eric Dumazet Date: Tue Jan 27 12:38:27 2026 +0000 tcp: tcp_tx_timestamp() must look at the rtx queue [ Upstream commit 838eb9687691d29915797a885b861fd09353386e ] tcp_tx_timestamp() is only called at the end of tcp_sendmsg_locked() before the final tcp_push(). By the time it is called, it is possible all the copied data has been sent already (transmit queue is empty). If this is the case, use the last skb in the rtx queue. Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue") Signed-off-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20260127123828.4098577-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 955c5d670b5ae07c78f4345e23a895638db96ce1 Author: Zhiyu Zhang Date: Thu Jan 1 19:11:48 2026 +0800 fat: avoid parent link count underflow in rmdir [ Upstream commit 8cafcb881364af5ef3a8b9fed4db254054033d8a ] Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink(). Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error. Link: https://lkml.kernel.org/r/20260101111148.1437-1-zhiyuzhang999@gmail.com Fixes: 9a53c3a783c2 ("[PATCH] r/o bind mounts: unlink: monitor i_nlink") Signed-off-by: Zhiyu Zhang Reported-by: Zhiyu Zhang Closes: https://lore.kernel.org/linux-fsdevel/aVN06OKsKxZe6-Kv@casper.infradead.org/T/#t Tested-by: Zhiyu Zhang Acked-by: OGAWA Hirofumi Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 063a6f22478ef929625000a2caf54667725c1dfd Author: Anthony Iliopoulos Date: Mon Dec 22 14:30:04 2025 -0500 nfsd: never defer requests during idmap lookup [ Upstream commit f9c206cdc4266caad6a9a7f46341420a10f03ccb ] During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred. Fixes: 2f425878b6a7 ("nfsd: don't use the deferral service, return NFS4ERR_DELAY") Signed-off-by: Anthony Iliopoulos Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e4d0e135ee38beeea98349cfb11dd87bcaaa286e Author: Chuck Lever Date: Sat Dec 20 10:41:09 2025 -0500 xdrgen: Initialize data pointer for zero-length items [ Upstream commit 27b0fcae8f535fb882b1876227a935dcfdf576aa ] The xdrgen decoders for strings and opaque data had an optimization that skipped calling xdr_inline_decode() when the item length was zero. This left the data pointer uninitialized, which could lead to unpredictable behavior when callers access it. Remove the zero-length check and always call xdr_inline_decode(). When passed a length of zero, xdr_inline_decode() returns the current buffer position, which is valid and matches the behavior of hand-coded XDR decoders throughout the kernel. Fixes: 4b132aacb076 ("tools: Add xdrgen") Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 25ad5d69139032b163cf5a2aeeb3045b8f06874c Author: Chuck Lever Date: Tue Dec 9 19:28:50 2025 -0500 NFS: NFSERR_INVAL is not defined by NFSv2 [ Upstream commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 ] A documenting comment in include/uapi/linux/nfs.h claims incorrectly that NFSv2 defines NFSERR_INVAL. There is no such definition in either RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm NFS3ERR_INVAL is introduced in RFC 1813. NFSD returns NFSERR_INVAL for PROC_GETACL, which has no specification (yet). However, nfsd_map_status() maps nfserr_symlink and nfserr_wrong_type to nfserr_inval, which does not align with RFC 1094. This logic was introduced only recently by commit 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code."). Given that we have no INVAL or SERVERFAULT status in NFSv2, probably the only choice is NFSERR_IO. Fixes: 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.") Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit a3a05e5ae1bb66c513f4b384b7a56c61eae7f8ce Author: Chuck Lever Date: Mon Dec 8 11:15:32 2025 -0500 xdrgen: Fix struct prefix for typedef types in program wrappers [ Upstream commit bf0fe9ad3d597d8e1378dc9953ca96dfc3addb2b ] The program templates for decoder/argument.j2 and encoder/result.j2 unconditionally add 'struct' prefix to all types. This is incorrect when an RPC protocol specification lists a typedef'd basic type or an enum as a procedure argument or result (e.g., NFSv2's fhandle or stat), resulting in compiler errors when building generated C code. Fixes: 4b132aacb076 ("tools: Add xdrgen") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 771ba4c6a805ae857da05e3e674c53f9de99f49a Author: Mikulas Patocka Date: Mon Jan 26 15:36:22 2026 +0100 dm: use bio_clone_blkg_association [ Upstream commit 2df8b310bcfe76827fd71092f58a2493ee6590b0 ] The origin bio carries blk-cgroup information which could be set from foreground(task_css(css) - wbc->wb->blkcg_css), so the blkcg won't control buffer io since commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone"). The synchronous io is still under control by blkcg, because 'bio->bi_blkg' is set by io submitting task which has been added into 'cgroup.procs'. Fix it by using bio_clone_blkg_association when submitting a cloned bio. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220985 Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Reported-by: Zhihao Cheng Signed-off-by: Mikulas Patocka Tested-by: Zhihao Cheng Signed-off-by: Sasha Levin commit a84d30e8d2bacd21782a6481158b7c9c552f4868 Author: Lu Baolu Date: Thu Jan 22 09:48:54 2026 +0800 iommu/vt-d: Clear Present bit before tearing down PASID entry [ Upstream commit 75ed00055c059dedc47b5daaaa2f8a7a019138ff ] The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes. Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults. Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references. 4. Only after the flushes are complete, zero out the remaining fields of the PASID entry. Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set. Fixes: 0bbeb01a4faf ("iommu/vt-d: Manage scalalble mode PASID tables") Signed-off-by: Lu Baolu Reviewed-by: Dmytro Maluka Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e148b5194ad9f6bb39f35ba5a64158f437e046e5 Author: Lu Baolu Date: Fri Dec 13 09:17:52 2024 +0800 iommu/vt-d: Avoid draining PRQ in sva mm release path [ Upstream commit dda2b8c3c6ccc50deae65cc75f246577348e2ec5 ] When a PASID is used for SVA by a device, it's possible that the PASID entry is cleared before the device flushes all ongoing DMA requests and removes the SVA domain. This can occur when an exception happens and the process terminates before the device driver stops DMA and calls the iommu driver to unbind the PASID. There's no need to drain the PRQ in the mm release path. Instead, the PRQ will be drained in the SVA unbind path. Unfortunately, commit c43e1ccdebf2 ("iommu/vt-d: Drain PRQs when domain removed from RID") changed this behavior by unconditionally draining the PRQ in intel_pasid_tear_down_entry(). This can lead to a potential sleeping-in-atomic-context issue. Smatch static checker warning: drivers/iommu/intel/prq.c:95 intel_iommu_drain_pasid_prq() warn: sleeping in atomic context To avoid this issue, prevent draining the PRQ in the SVA mm release path and restore the previous behavior. Fixes: c43e1ccdebf2 ("iommu/vt-d: Drain PRQs when domain removed from RID") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-iommu/c5187676-2fa2-4e29-94e0-4a279dc88b49@stanley.mountain/ Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20241212021529.1104745-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Stable-dep-of: 75ed00055c05 ("iommu/vt-d: Clear Present bit before tearing down PASID entry") Signed-off-by: Sasha Levin commit 19131118093556bb3753fa5fce132ab9d306e7a9 Author: Lu Baolu Date: Mon Nov 4 09:40:39 2024 +0800 iommu/vt-d: Drain PRQs when domain removed from RID [ Upstream commit c43e1ccdebf2c950545fdf12c5796ad6f7bad7ee ] As this iommu driver now supports page faults for requests without PASID, page requests should be drained when a domain is removed from the RID2PASID entry. This results in the intel_iommu_drain_pasid_prq() call being moved to intel_pasid_tear_down_entry(). This indicates that when a translation is removed from any PASID entry and the PRI has been enabled on the device, page requests are drained in the domain detachment path. The intel_iommu_drain_pasid_prq() helper has been modified to support sending device TLB invalidation requests for both PASID and non-PASID cases. Signed-off-by: Lu Baolu Reviewed-by: Yi Liu Link: https://lore.kernel.org/r/20241101045543.70086-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Stable-dep-of: 75ed00055c05 ("iommu/vt-d: Clear Present bit before tearing down PASID entry") Signed-off-by: Sasha Levin commit d5cd1db0ac938ba356752ca558e4ea98b7cf3305 Author: Joel Granados Date: Mon Nov 4 09:40:34 2024 +0800 iommu/vt-d: Separate page request queue from SVM [ Upstream commit 4d5440957641fb5652cbef8df6183baf473cab6b ] IO page faults are no longer dependent on CONFIG_INTEL_IOMMU_SVM. Move all Page Request Queue (PRQ) functions that handle prq events to a new file in drivers/iommu/intel/prq.c. The page_req_des struct is now declared in drivers/iommu/intel/prq.c. No functional changes are intended. This is a preparation patch to enable the use of IO page faults outside the SVM/PASID use cases. Signed-off-by: Joel Granados Link: https://lore.kernel.org/r/20241015-jag-iopfv8-v4-1-b696ca89ba29@kernel.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Stable-dep-of: 75ed00055c05 ("iommu/vt-d: Clear Present bit before tearing down PASID entry") Signed-off-by: Sasha Levin commit 5962c30a6f05ea1ab73f039e235bb30716243517 Author: Dmytro Maluka Date: Thu Jan 22 09:48:52 2026 +0800 iommu/vt-d: Flush cache for PASID table before using it [ Upstream commit 22d169bdd2849fe6bd18c2643742e1c02be6451c ] When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Signed-off-by: Dmytro Maluka Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20251221123508.37495-1-dmaluka@chromium.org Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 428a543c4ab1d7c4553ec6284298548250b82712 Author: Jörg Wedekind Date: Mon Jan 19 15:31:10 2026 +0100 PCI: Mark 3ware-9650SA Root Port Extended Tags as broken [ Upstream commit 959ac08a2c2811305be8c2779779e8b0932e5a99 ] Per PCIe r7.0, sec 2.2.6.2.1 and 7.5.3.4, a Requester may not use 8-bit Tags unless its Extended Tag Field Enable is set, but all Receivers/Completers must handle 8-bit Tags correctly regardless of their Extended Tag Field Enable. Some devices do not handle 8-bit Tags as Completers, so add a quirk for them. If we find such a device, we disable Extended Tags for the entire hierarchy to make peer-to-peer DMA possible. The 3ware 9650SA seems to have issues with handling 8-bit tags. Mark it as broken. This fixes PCI Parity Errors like : 3w-9xxx: scsi0: ERROR: (0x06:0x000C): PCI Parity Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000D): PCI Abort: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x000E): Controller Queue Error: clearing. 3w-9xxx: scsi0: ERROR: (0x06:0x0010): Microcontroller Error: clearing. Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202425 Signed-off-by: Jörg Wedekind Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260119143114.21948-1-joerg@wedekind.de Signed-off-by: Sasha Levin commit 19d0708a39ed99a33544c08e96c6637ab3ec0347 Author: Petr Mladek Date: Fri Nov 28 14:59:19 2025 +0100 kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup() [ Upstream commit e8a1e7eaa19d0b757b06a2f913e3eeb4b1c002c6 ] __sprint_symbol() might access an invalid pointer when kallsyms_lookup_buildid() returns a symbol found by ftrace_mod_address_lookup(). The ftrace lookup function must set both @modname and @modbuildid the same way as module_address_lookup(). Link: https://lkml.kernel.org/r/20251128135920.217303-7-pmladek@suse.com Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek Reviewed-by: Aaron Tomlin Acked-by: Steven Rostedt (Google) Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0bdc4b1ad694293390ffddbb86c0aabc6330e8ba Author: Petr Mladek Date: Fri Nov 28 14:59:16 2025 +0100 module: add helper function for reading module_buildid() [ Upstream commit acfdbb4ab2910ff6f03becb569c23ac7b2223913 ] Add a helper function for reading the optional "build_id" member of struct module. It is going to be used also in ftrace_mod_address_lookup(). Use "#ifdef" instead of "#if IS_ENABLED()" to match the declaration of the optional field in struct module. Link: https://lkml.kernel.org/r/20251128135920.217303-4-pmladek@suse.com Signed-off-by: Petr Mladek Reviewed-by: Daniel Gomez Reviewed-by: Petr Pavlu Cc: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Stable-dep-of: e8a1e7eaa19d ("kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup()") Signed-off-by: Sasha Levin commit 95d9748cc9b45f45efcff6e16cff124535841306 Author: Fernando Fernandez Mancera Date: Mon Jan 19 21:35:46 2026 +0100 netfilter: nf_conncount: fix tracking of connections from localhost [ Upstream commit de8a70cefcb26cdceaafdc5ac144712681419c29 ] Since commit be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly"), we skip the adding and trigger a GC when the ct is confirmed. For connections originated from local to local it doesn't work because the connection is confirmed on POSTROUTING, therefore tracking on the INPUT hook is always skipped. In order to fix this, we check whether skb input ifindex is set to loopback ifindex. If it is then we fallback on a GC plus track operation skipping the optimization. This fallback is necessary to avoid duplicated tracking of a packet train e.g 10 UDP datagrams sent on a burst when initiating the connection. Tested with xt_connlimit/nft_connlimit and OVS limit and with a HTTP server and iperf3 on UDP mode. Fixes: be102eb6a0e7 ("netfilter: nf_conncount: rework API to use sk_buff directly") Reported-by: Michal Slabihoudek Closes: https://lore.kernel.org/netfilter/6989BD9F-8C24-4397-9AD7-4613B28BF0DB@gooddata.com/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 63fece123bbe995b31857256c17949dd181db1ba Author: Florian Westphal Date: Fri Aug 19 16:16:07 2022 +0200 netfilter: nft_compat: add more restrictions on netlink attributes [ Upstream commit cda26c645946b08f070f20c166d4736767e4a805 ] As far as I can see nothing bad can happen when NFTA_TARGET/MATCH_NAME are too large because this calls x_tables helpers which check for the length, but it seems better to already reject it during netlink parsing. Rest of the changes avoid silent u8/u16 truncations. For _TYPE, its expected to be only 1 or 0. In x_tables world, this variable is set by kernel, for IPT_SO_GET_REVISION_TARGET its 1, for all others its set to 0. As older versions of nf_tables permitted any value except 1 to mean 'match', keep this as-is but sanitize the value for consistency. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 3d0994ed0aa1fc0a2c5e620b765e8defdd021bff Author: Fernando Fernandez Mancera Date: Wed Dec 17 15:46:41 2025 +0100 netfilter: nf_conncount: increase the connection clean up limit to 64 [ Upstream commit 21d033e472735ecec677f1ae46d6740b5e47a4f3 ] After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC") Reported-by: Aleksandra Rukomoinikova Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 4fe47671aa2927c5973f8e4e9a55faef6b81047a Author: Fernando Fernandez Mancera Date: Fri Nov 21 01:14:31 2025 +0100 netfilter: nf_conncount: make nf_conncount_gc_list() to disable BH [ Upstream commit c0362b5748282e22fa1592a8d3474f726ad964c2 ] For convenience when performing GC over the connection list, make nf_conncount_gc_list() to disable BH. This unifies the behavior with nf_conncount_add() and nf_conncount_count(). Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 21d033e47273 ("netfilter: nf_conncount: increase the connection clean up limit to 64") Signed-off-by: Sasha Levin commit 01726b9021cb8ffd7cfd7bd7d99fecff97264cd7 Author: Florian Westphal Date: Fri Nov 28 12:26:54 2025 +0100 netfilter: nf_tables: reset table validation state on abort [ Upstream commit 6f93616a7323d646d18db9c09f147e453b40fdd7 ] If a transaction fails the final validation in the commit hook, the table validation state is changed to NFT_VALIDATE_DO and a replay of the batch is performed. Every rule insert will then do a graph validation. This is much slower, but provides better error reporting to the user because we can point at the rule that introduces the validation issue. Without this reset the affected table(s) remain in full validation mode, i.e. on next transaction we start with slow-mode. This makes the next transaction after a failed incremental update very slow: # time iptables-restore < /tmp/ruleset real 0m0.496s [..] # time iptables -A CALLEE -j CALLER iptables v1.8.11 (nf_tables): RULE_APPEND failed (Too many links): rule in chain CALLEE real 0m0.022s [..] # time iptables-restore < /tmp/ruleset real 1m22.355s [..] After this patch, 2nd iptables-restore is back to ~0.5s. Fixes: 9a32e9850686 ("netfilter: nf_tables: don't write table validation state without mutex") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f6c4c7a5cf5b3c32851d2c3eb73fe1dfc94f439c Author: Miri Korenblit Date: Wed Jan 7 14:04:51 2026 +0200 wifi: cfg80211: stop NAN and P2P in cfg80211_leave [ Upstream commit e1696c8bd0056bc1a5f7766f58ac333adc203e8a ] Seems that there is an assumption that this function should be called only for netdev interfaces, but it can also be called in suspend, or from nl80211_netlink_notify (indirectly). Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly says that NAN interfaces would be destroyed as well in the nl80211_netlink_notify case. Fix this by also stopping P2P and NAN. Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands") Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fa9861e5c8af7651dddfa8d490aaada17ae33b6c Author: Matt Johnston Date: Tue Jan 13 17:01:16 2026 +0800 mctp i2c: initialise event handler read bytes [ Upstream commit 2a14e91b6d76639dac70ea170f4384c1ee3cb48d ] Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8468dd5bc1c4f21fa6b1e07b1950c6981ed30666 Author: Jian Zhang Date: Thu Jan 8 18:18:29 2026 +0800 net: mctp-i2c: fix duplicate reception of old data [ Upstream commit ae4744e173fadd092c43eda4ca92dcb74645225a ] The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED events. As a result, i2c read event will trigger repeated reception of old data, reset rx_pos when a read request is received. Signed-off-by: Jian Zhang Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2a14e91b6d76 ("mctp i2c: initialise event handler read bytes") Signed-off-by: Sasha Levin commit 414259caf81a397563fc9baca9c0ef856c4a97cf Author: Abhishek Bapat Date: Thu Jan 15 21:31:03 2026 +0000 quota: fix livelock between quotactl and freeze_super [ Upstream commit 77449e453dfc006ad738dec55374c4cbc056fd39 ] When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU: # mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" & Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete. Fixes: 576215cffdef ("fs: Drop wait_unfrozen wait queue") Signed-off-by: Abhishek Bapat Link: https://patch.msgid.link/20260115213103.1089129-1-abhishekbapat@google.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit dec62b741a39506f3893d84a7d0934fc165007d6 Author: Mikulas Patocka Date: Thu Jan 8 20:56:20 2026 +0100 dm: use READ_ONCE in dm_blk_report_zones [ Upstream commit e9f5a55b70ae6187ab64ef2d1232ae2738e31d1f ] The functon dm_blk_report_zones reads md->zone_revalidate_map, however it may change while the function is running. Use READ_ONCE. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit 175ac0a6115400278d3900f5a04a58b17b3f6cd0 Author: Mikulas Patocka Date: Thu Jan 8 20:55:08 2026 +0100 dm: fix unlocked test for dm_suspended_md [ Upstream commit 24c405fdbe215c45e57bba672cc42859038491ee ] The function dm_blk_report_zones tests if the device is suspended with the "dm_suspended_md" call. However, this function is called without holding any locks, so the device may be suspended just after it. Move the call to dm_suspended_md after dm_get_live_table, so that the device can't be suspended after the suspended state was tested. Signed-off-by: Mikulas Patocka Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski Signed-off-by: Sasha Levin commit 160913364fcc76fb3aaae955bfcf90ce0eb3bbd3 Author: Uwe Kleine-König Date: Tue Dec 2 16:13:49 2025 +0100 PCI/portdrv: Fix potential resource leak [ Upstream commit 01464a3fdf91c041a381d93a1b6fefbdb819a46f ] pcie_port_probe_service() unconditionally calls get_device() (unless it fails). So drop that reference also unconditionally as it's fine for a PCIe driver to not have a remove callback. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Uwe Kleine-König Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/e1c68c3b3f1af8427e98ca5e2c79f8bf0ebe2ce4.1764688034.git.u.kleine-koenig@baylibre.com Signed-off-by: Sasha Levin commit d773a4826195bfcd322d4d9e6dc26a9c5cdcd2f8 Author: Håkon Bugge Date: Wed Nov 12 10:54:40 2025 +0100 PCI: Do not attempt to set ExtTag for VFs [ Upstream commit 73711730a1128d91ebca1a6994ceeb18f36cb0cd ] The bit for enabling extended tags is Reserved and Preserved (RsvdP) for VFs, according to PCIe r7.0 section 7.5.3.4 table 7.21. Hence, bail out early from pci_configure_extended_tags() if the device is a VF. Otherwise, we may see incorrect log messages such as: kernel: pci 0000:af:00.2: enabling Extended Tags (af:00.2 is a VF) Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") Signed-off-by: Håkon Bugge Signed-off-by: Bjorn Helgaas Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/20251112095442.1913258-1-haakon.bugge@oracle.com Signed-off-by: Sasha Levin commit c8c6cb9fa63250485859fc455850d208ea71470c Author: Shuai Xue Date: Wed Dec 10 21:29:07 2025 +0800 Documentation: tracing: Add PCI tracepoint documentation [ Upstream commit 8236fc613d44e59f6736d6c3e9efffaf26ab7f00 ] The PCI tracing system provides tracepoints to monitor critical hardware events that can impact system performance and reliability. Add documentation about it. Signed-off-by: Shuai Xue [bhelgaas: squash fixes: https://lore.kernel.org/r/20260108013956.14351-2-bagasdotme@gmail.com https://lore.kernel.org/r/20260108013956.14351-3-bagasdotme@gmail.com] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20251210132907.58799-4-xueshuai@linux.alibaba.com Signed-off-by: Sasha Levin commit 2cacab8c7a050fa928619c9d071053fce1c78ed3 Author: Purva Yeshi Date: Wed Apr 16 09:40:50 2025 +0700 Documentation: trace: Refactor toctree [ Upstream commit f0ba72e65516d1d86f40c79a49c4ba01c9555592 ] Refactor table of contents of kernel tracing subsystem docs to improve clarity, structure, and organization: - Reformat sections and add appropriate headings - Improve section grouping and refine descriptions for each group - Add docs intro paragraph Signed-off-by: Purva Yeshi Link: https://lore.kernel.org/r/20250318113230.24950-2-purvayeshi550@gmail.com [Bagas: massage commit message and address reviews] Co-developed-by: Bagas Sanjaya Signed-off-by: Bagas Sanjaya Acked-by: Steven Rostedt (Google) Signed-off-by: Jonathan Corbet Stable-dep-of: 8236fc613d44 ("Documentation: tracing: Add PCI tracepoint documentation") Signed-off-by: Sasha Levin commit b53efc230ab2012b32b30442f5a38311f96f446b Author: SurajSonawane2415 Date: Thu Oct 3 01:28:17 2024 +0530 docs: fix WARNING document not included in any toctree [ Upstream commit 998bece1d22bf2cbc819cb3a492148932d4e12a8 ] Add debugging.rst to the relevant toctree to fix warning about missing documentation inclusion in toctree. Signed-off-by: SurajSonawane2415 Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20241002195817.22972-1-surajsonawane0215@gmail.com Stable-dep-of: 8236fc613d44 ("Documentation: tracing: Add PCI tracepoint documentation") Signed-off-by: Sasha Levin commit 51b7181cfbedf289ce794b6d97a1c596c309ec38 Author: Hou Tao Date: Sat Dec 20 12:04:34 2025 +0800 PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails [ Upstream commit 6220694c52a5a04102b48109e4f24e958b559bd3 ] When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap() doesn't invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when trying to remove the PCI device. Fix it by adding the missed percpu_ref_put(). Fixes: 7e9c7ef83d78 ("PCI/P2PDMA: Allow userspace VMA allocations through sysfs") Signed-off-by: Hou Tao Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20251220040446.274991-2-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit 33b2230edd86aceacb152ae2997e0b7a44db5931 Author: Huang Chenming Date: Tue Dec 9 08:27:33 2025 +0530 wifi: cfg80211: Fix use_for flag update on BSS refresh [ Upstream commit 4073ea516106e5f98ed0476f89cdede8baa98d37 ] Userspace may fail to connect to certain BSS that were initially marked as unusable due to regulatory restrictions (use_for = 0, e.g., 6 GHz power type mismatch). Even after these restrictions are removed and the BSS becomes usable, connection attempts still fail. The issue occurs in cfg80211_update_known_bss() where the use_for flag is updated using bitwise AND (&=) instead of direct assignment. Once a BSS is marked with use_for = 0, the AND operation masks out any subsequent non-zero values, permanently keeping the flag at 0. This causes __cfg80211_get_bss(), invoked by nl80211_assoc_bss(), to fail the check "(bss->pub.use_for & use_for) != use_for", thereby blocking association. Replace the bitwise AND operation with direct assignment so the use_for flag accurately reflects the current BSS state. Fixes: d02a12b8e4bb ("wifi: cfg80211: add BSS usage reporting") Signed-off-by: Huang Chenming Link: https://patch.msgid.link/20251209025733.2098456-1-chenming.huang@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9e2b4159289c63f9f7a5e1038107a5fabee342f2 Author: Brian Norris Date: Fri Oct 3 15:40:09 2025 -0700 PCI/PM: Avoid redundant delays on D3hot->D3cold [ Upstream commit 4d982084507d663df160546c4c48066a8887ed89 ] When transitioning to D3cold, __pci_set_power_state() first transitions to D3hot. If the device was already in D3hot, this adds excess work: (a) read/modify/write PMCSR; and (b) excess delay (pci_dev_d3_sleep()). For (b), we already performed the necessary delay on the previous D3hot entry; this was extra noticeable when evaluating runtime PM transition latency. Check whether we're already in the target state before continuing. Note that __pci_set_power_state() already does this same check for other state transitions, but D3cold is special because __pci_set_power_state() converts it to D3hot for the purposes of PMCSR. This seems to be an oversight in commit 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()"). Fixes: 0aacdc957401 ("PCI/PM: Clean up pci_set_low_power_state()") Signed-off-by: Brian Norris Signed-off-by: Brian Norris [bhelgaas: reverse test to match other "dev->current_state == state" cases] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251003154008.1.I7a21c240b30062c66471329567a96dceb6274358@changeid Signed-off-by: Sasha Levin commit 29c4f6e0ac9765db0b9f464cc9f3369092ec8712 Author: Baruch Siach Date: Mon Nov 3 09:28:30 2025 +0200 Documentation: PCI: endpoint: Fix ntb/vntb copy & paste errors [ Upstream commit ad0c6da5be901f5c181490f683d22b416059bccb ] Fix copy & paste errors by changing the references from 'ntb' to 'vntb'. Fixes: 4ac8c8e52cd9 ("Documentation: PCI: Add specification for the PCI vNTB function device") Signed-off-by: Baruch Siach [mani: squashed the patches and fixed more errors] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/b51c2a69ffdbfa2c359f5cf33f3ad2acc3db87e4.1762154911.git.baruch@tkos.co.il Signed-off-by: Sasha Levin commit e44b390e01c19478a8e99fa627c16c3d12f451c1 Author: Haotian Zhang Date: Wed Nov 19 10:33:08 2025 +0800 PCI: mediatek: Fix IRQ domain leak when MSI allocation fails [ Upstream commit 7f0cdcddf8bef1c8c18f9be6708073fd3790a20f ] In mtk_pcie_init_irq_domain(), if mtk_pcie_allocate_msi_domains() fails after port->irq_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. Add irq_domain_remove() call in the error path to properly release the INTx IRQ domain before returning the error. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Haotian Zhang Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251119023308.476-1-vulab@iscas.ac.cn Signed-off-by: Sasha Levin commit d8308dff30bd20fe09f917a89607409e9e308fed Author: Carl Lee Date: Tue Feb 10 15:26:34 2026 +0800 hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification [ Upstream commit 9e33c1dba22431bea9b2bf48adf56859e52fc7ec ] When MPQ8785 reports VOUT_MODE as VID mode, mpq8785_identify() configures the driver for direct mode. The subsequent pmbus_identify_common() check then fails due to a mismatch between the reported mode and the configured mode, causing device initialization to fail. Override the reported VOUT_MODE to direct mode to keep the driver configuration consistent with the reported mode and allow successful device initialization. This does not change how voltages are interpreted, but avoids a false identification failure caused by mismatched mode handling. Fixes: f20b4a931130c ("hwmon: Add driver for MPS MPQ8785 Synchronous Step-Down Converter") Signed-off-by: Carl Lee Link: https://lore.kernel.org/r/20260210-dt-bindings-hwmon-pmbus-mpq8785-add-mpq8786-support-v3-1-84636ccfe76f@amd.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 369d2ed2da20063549d5ec8a2c3389f9aba0f35a Author: Pawel Dembicki Date: Sun May 11 05:55:47 2025 +0200 hwmon: pmbus: mpq8785: Add support for MPM82504 [ Upstream commit c27291468eb957b11dc81cd35fad36faf0861c07 ] Add support for the Monolithic Power Systems MPM82504 digital voltage regulator. MPM82504 uses PMBus direct format for voltage output. Tested with device tree based matching. Signed-off-by: Pawel Dembicki Link: https://lore.kernel.org/r/20250511035701.2607947-5-paweldembicki@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin commit 8c311c726f1f5daf180806b32bd9c04b7643d4ba Author: Pawel Dembicki Date: Sun May 11 05:55:46 2025 +0200 hwmon: pmbus: mpq8785: Implement VOUT feedback resistor divider ratio configuration [ Upstream commit dc1a4bab48d513e426118e42b9c371d942ddb04b ] Implement support for setting the VOUT_SCALE_LOOP PMBus register based on an optional device tree property "mps,vout-fb-divider-ratio-permille". This allows the driver to provide the correct VOUT value depending on the feedback voltage divider configuration for chips where the bootloader does not configure the VOUT_SCALE_LOOP register. Signed-off-by: Pawel Dembicki Link: https://lore.kernel.org/r/20250511035701.2607947-4-paweldembicki@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin commit 7cd0bc5fe14cdc0605e9d35444cf9b742a0de858 Author: Pawel Dembicki Date: Sun May 11 05:55:45 2025 +0200 hwmon: pmbus: mpq8785: Prepare driver for multiple device support [ Upstream commit 1bc6020dc400ea8290a7b26aa4365d4568e23e27 ] Refactor the driver to support multiple Monolithic Power Systems devices. Introduce chip ID handling based on device tree matching. No functional changes intended. Signed-off-by: Pawel Dembicki Link: https://lore.kernel.org/r/20250511035701.2607947-3-paweldembicki@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin commit 914b47c9b824d3d74f31c764163edf93302100b1 Author: Guenter Roeck Date: Sat Feb 7 08:12:25 2026 -0800 Revert "hwmon: (ibmpex) fix use-after-free in high/low store" [ Upstream commit 8bde3e395a85017f12af2b0ba5c3684f5af9c006 ] This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix. Reported-by: Jean Delvare Closes: https://lore.kernel.org/linux-hwmon/20260121095342.73e723cb@endymion/ Cc: Jean Delvare Cc: Junrui Luo Fixes: 6946c726c3f4 ("hwmon: (ibmpex) fix use-after-free in high/low store") Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ee842490a6040ae5b7b939822adaf50ecc001eda Author: Francesco Lavra Date: Mon Feb 9 10:50:01 2026 +0100 spi: tools: Add include folder to .gitignore [ Upstream commit 5af56f30c4fcbade4a92f94dadfea517d1db9703 ] The Makefile for the SPI tools creates an include/linux/spi folder and some symlinks inside it. After running `make -C spi/tools`, this folder shows up as untracked in the git status. Add the above folder to the .gitignore file. Fixes: f325b73dc4db ("spi: tools: move to tools buildsystem") Signed-off-by: Francesco Lavra Link: https://patch.msgid.link/20260209095001.556495-1-flavra@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b605e8ce60698c27a26f512968a597fd620d2e8 Author: Ryan Lin Date: Fri Jan 30 13:34:56 2026 +0800 HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients [ Upstream commit 56f7db581ee73af53cd512e00a6261a025bf1d58 ] During a warm reset flow, the cl->device pointer may be NULL if the reset occurs while clients are still being enumerated. Accessing cl->device->reference_count without a NULL check leads to a kernel panic. This issue was identified during multi-unit warm reboot stress clycles. Add a defensive NULL check for cl->device to ensure stability under such intensive testing conditions. KASAN: null-ptr-deref in range [0000000000000000-0000000000000007] Workqueue: ish_fw_update_wq fw_reset_work_fn Call Trace: ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp] ishtp_reset_handler+0x85/0x1a0 [intel_ishtp] fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc] Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer") Signed-off-by: Ryan Lin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1a2482e5fcb4c3469ee2f05b83d4eff01202ad81 Author: Tzung-Bi Shih Date: Fri Jan 30 04:03:35 2026 +0000 platform/chrome: cros_ec_lightbar: Fix response size initialization [ Upstream commit ec0dd36dbf8b0b209e63d0cd795451fa2203c736 ] Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") meant to set smaller values for both request and response sizes. However, it incorrectly assigned the response size to the `result` field instead of `insize`. Fix it. Reported-by: Gwendal Grignou Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org Reviewed-by: Gwendal Grignou Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit be74863074490e584b8d09941b5147774ec72c14 Author: Shuicheng Lin Date: Fri Jan 9 21:10:42 2026 +0000 drm/xe: Unregister drm device on probe error [ Upstream commit 96c2c72b817d70e8d110e78b0162e044a0c41f9f ] Call drm_dev_unregister() when xe_device_probe() fails after successful drm_dev_register(). This ensures the DRM device is promptly unregistered before returning an error, avoiding leaving it registered on the failure path. Otherwise, there is warn message if xe_device_probe() is called again: " [ 207.322365] [drm:drm_minor_register] [ 207.322381] debugfs: '128' already exists in 'dri' [ 207.322432] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 207.322435] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.322439] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.322440] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.322441] Call Trace: [ 207.322442] [ 207.322443] dump_stack_lvl+0xa0/0xc0 [ 207.322446] dump_stack+0x10/0x20 [ 207.322448] sysfs_warn_dup+0xd5/0x110 [ 207.322451] sysfs_create_dir_ns+0x1f6/0x280 [ 207.322453] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.322455] ? lock_acquire+0x1a4/0x2e0 [ 207.322458] ? __kasan_check_read+0x11/0x20 [ 207.322461] kobject_add_internal+0x28d/0x8e0 [ 207.322464] kobject_add+0x11f/0x1f0 [ 207.322465] ? lock_acquire+0x1a4/0x2e0 [ 207.322467] ? __pfx_kobject_add+0x10/0x10 [ 207.322469] ? __kasan_check_write+0x14/0x20 [ 207.322471] ? kobject_put+0x62/0x4a0 [ 207.322473] ? get_device_parent.isra.0+0x1bb/0x4c0 [ 207.322475] ? kobject_put+0x62/0x4a0 [ 207.322477] device_add+0x2d7/0x1500 [ 207.322479] ? __pfx_device_add+0x10/0x10 [ 207.322481] ? drm_debugfs_add_file+0xfa/0x170 [ 207.322483] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322485] ? drm_debugfs_add_files+0x82/0xd0 [ 207.322487] drm_minor_register+0x10a/0x2d0 [ 207.322489] drm_dev_register+0x143/0x860 [ 207.322491] ? xe_configfs_get_psmi_enabled+0x12/0x90 [xe] [ 207.322667] xe_device_probe+0x185b/0x2c40 [xe] [ 207.322812] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.322815] ? add_dr+0x180/0x220 [ 207.322818] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.322821] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.322966] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.323136] xe_pci_probe+0x936/0x1250 [xe] [ 207.323298] ? lock_acquire+0x1a4/0x2e0 [ 207.323302] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.323464] local_pci_probe+0xe6/0x1a0 [ 207.323468] pci_device_probe+0x523/0x840 [ 207.323470] ? __pfx_pci_device_probe+0x10/0x10 [ 207.323473] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.323476] ? sysfs_create_link+0x48/0xc0 [ 207.323479] really_probe+0x1fd/0x8a0 ... " Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin Reviewed-by: Jonathan Cavitt Link: https://patch.msgid.link/20260109211041.2446012-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 60bfb8baf8f0d5b0d521744dfd01c880ce1a23f3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 450d8e18ba8bd23429f88b1a30161d69f99e32be Author: Roberto Sassu Date: Tue Jan 20 15:53:41 2026 +0100 evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac() [ Upstream commit 0496fc9cdc384f67be4413b1c6156eb64fccd5c4 ] Commit 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") introduced xattr_dupval() to simplify setting the xattrs to be provided by the SMACK LSM on inode creation, in the smack_inode_init_security(). Unfortunately, moving lsm_get_xattr_slot() caused the SMACK64TRANSMUTE xattr be added in the array of new xattrs before SMACK64. This causes the HMAC of xattrs calculated by evm_init_hmac() for new files to diverge from the one calculated by both evm_calc_hmac_or_hash() and evmctl. evm_init_hmac() calculates the HMAC of the xattrs of new files based on the order LSMs provide them, while evm_calc_hmac_or_hash() and evmctl calculate the HMAC based on an ordered xattrs list. Fix the issue by making evm_init_hmac() calculate the HMAC of new files based on the ordered xattrs list too. Fixes: 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e25b9f0712263d60cb04aefa7fd8d7c448bc97cb Author: Ricardo Ribalda Date: Wed Jan 14 10:32:13 2026 +0000 media: uvcvideo: Fix allocation for small frame sizes [ Upstream commit 40d3ac25c11310bfaa50ed7614846ef75cb69a1e ] If a frame has size of less or equal than one packet size uvc_alloc_urb_buffers() is unable to allocate memory for it due to a off-by-one error. Fix the off-by-one-error and now that we are at it, make sure that stream->urb_size has always a valid value when we return from the function, even when an error happens. Fixes: efdc8a9585ce ("V4L/DVB (10295): uvcvideo: Retry URB buffers allocation when the system is low on memory.") Reported-by: Itay Chamiel Closes: https://lore.kernel.org/linux-media/CANiDSCsSoZf2LsCCoWAUbCg6tJT-ypXR1B85aa6rAdMVYr2iBQ@mail.gmail.com/T/#t Co-developed-by: Itay Chamiel Signed-off-by: Itay Chamiel Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Tested-by: Itay Chamiel Link: https://patch.msgid.link/20260114-uvc-alloc-urb-v1-1-cedf3fb66711@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9aae11893e55023acd61c162d3b487a902744423 Author: Andy Shevchenko Date: Tue Jan 20 14:12:30 2026 +0100 platform/chrome: cros_typec_switch: Don't touch struct fwnode_handle::dev [ Upstream commit e1adf48853bc715f4deea074932aa1c44eb7abea ] The 'dev' field in struct fwnode is special and related to device links, There no driver should use it for printing messages. Fix incorrect use of private field. Fixes: affc804c44c8 ("platform/chrome: cros_typec_switch: Add switch driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20260120131413.1697891-2-andriy.shevchenko@linux.intel.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit b61deabec46b17f0212e0a3fb89bd59240e76c33 Author: Michał Grzelak Date: Mon Dec 8 11:27:14 2025 +0100 drm/buddy: release free_trees array on buddy mm teardown [ Upstream commit 7d0507772406e129329983b8b807e5b499bd74fd ] During initialization of DRM buddy memory manager at drm_buddy_init, mm->free_trees array is allocated for both clear and dirty RB trees. During cleanup happening at drm_buddy_fini it is never freed, leading to following memory leaks observed on xe module load & unload cycles: kmemleak_alloc+0x4a/0x90 __kmalloc_cache_noprof+0x488/0x800 drm_buddy_init+0xc2/0x330 [drm_buddy] __xe_ttm_vram_mgr_init+0xc3/0x190 [xe] xe_ttm_stolen_mgr_init+0xf5/0x9d0 [xe] xe_device_probe+0x326/0x9e0 [xe] xe_pci_probe+0x39a/0x610 [xe] local_pci_probe+0x47/0xb0 pci_device_probe+0xf3/0x260 really_probe+0xf1/0x3c0 __driver_probe_device+0x8c/0x180 driver_probe_device+0x24/0xd0 __driver_attach+0x10f/0x220 bus_for_each_dev+0x7f/0xe0 driver_attach+0x1e/0x30 bus_add_driver+0x151/0x290 Deallocate array for free trees when cleaning up buddy memory manager in the same way as if going through out_free_tree label. Fixes: d4cd665c98c1 ("drm/buddy: Separate clear and dirty free block trees") Signed-off-by: Michał Grzelak Reviewed-by: Lucas De Marchi Reviewed-by: Matthew Auld Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20251208102714.4008260-2-michal.grzelak@intel.com Signed-off-by: Sasha Levin commit af8294a2a51c47e3543a9faa3a3f15f0b839bd99 Author: Dmitry Baryshkov Date: Fri Nov 21 18:13:03 2025 +0200 drm/msm/a2xx: fix pixel shader start on A225 [ Upstream commit 6a7b0a670ba4d283285d76d45233cbecc5af5e40 ] A225 has a different PixelShader start address, write correct address while initializing GPU. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/689906/ Message-ID: <20251121-a225-v1-1-a1bab651d186@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9f6453e5177ad806e91cbc0aeba52593f2ec3a54 Author: David Heidelberg Date: Fri Jan 9 18:57:07 2026 +0100 media: ccs: Accommodate C-PHY into the calculation [ Upstream commit 3085977e734dab74adebb1dda195befce25addff ] We need to set correct mode for PLL to calculate correct frequency. Signalling mode is known at this point, so use it for that. Fixes: 47b6eaf36eba ("media: ccs-pll: Differentiate between CSI-2 D-PHY and C-PHY") Reviewed-by: Mehdi Djait Signed-off-by: David Heidelberg [Sakari Ailus: Drop extra newline.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 33a76dcced8c0818a29d88c9b157c3a814415650 Author: Dmitry Baryshkov Date: Sun Dec 28 06:02:28 2025 +0200 drm/msm/dpu: fix CMD panels on DPU 1.x - 3.x [ Upstream commit 59ca3d11f5311d9167015fe4f431701614ae0048 ] DPU units before 4.x don't have a separate CTL_START IRQ to mark the begin of the data transfer. In such a case, wait for the frame transfer to complete rather than trying to wait for the CTL_START interrupt (and obviously hitting the timeout). Fixes: 050770cbbd26 ("drm/msm/dpu: Fix timeout issues on command mode panels") Reported-by: Alexey Minnekhanov Closes: https://lore.kernel.org/r/8e1d33ff-d902-4ae9-9162-e00d17a5e6d1@postmarketos.org Patchwork: https://patchwork.freedesktop.org/patch/696490/ Link: https://lore.kernel.org/r/20251228-mdp5-drop-dpu3-v4-2-7497c3d39179@oss.qualcomm.com Tested-by: Alexey Minnekhanov Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9c53a12b3eb412b170e251a355982c5140ba7f3f Author: Dmitry Baryshkov Date: Fri Nov 14 05:43:28 2025 +0200 drm/msm/disp: set num_planes to 1 for interleaved YUV formats [ Upstream commit 6421e1c5075b7e1536a8fcbe6b4086db07103048 ] Interleaved YUV formats use only one plane for all pixel data. Specify num_planes = 1 for those formats. This was left unnoticed since _dpu_format_populate_plane_sizes_linear() overrides layout->num_planes. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reviewed-by: Jessica Zhang Patchwork: https://patchwork.freedesktop.org/patch/688162/ Link: https://lore.kernel.org/r/20251114-dpu-formats-v3-1-cae312379d49@oss.qualcomm.com Tested-by: Luca Weiss # qcm6490-fairphone-fp5 Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d955aeb26e1210a018492b3b32cbdfaf017aaa25 Author: Haotian Zhang Date: Mon Nov 17 16:28:08 2025 +0800 HID: playstation: Add missing check for input_ff_create_memless [ Upstream commit e6807641ac94e832988655a1c0e60ccc806b76dc ] The ps_gamepad_create() function calls input_ff_create_memless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered. Add a check for the return value of input_ff_create_memless(). Fixes: 51151098d7ab ("HID: playstation: add DualSense classic rumble support.") Signed-off-by: Haotian Zhang Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit db3cc304a9a6c98ef61a8f8753d34700ed45ad07 Author: André Draszik Date: Fri Jan 9 08:38:39 2026 +0000 regulator: core: move supply check earlier in set_machine_constraints() [ Upstream commit 86a8eeb0e913f4b6a55dabba5122098d4e805e55 ] Since commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators"), set_machine_constraints() can return -EPROBE_DEFER very late, after it has done a lot of work and configuration of the regulator. This means that configuration will happen multiple times for no benefit in that case. Furthermore, this can lead to timing-dependent voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init"). We can know that it's going to fail very early, in particular before going through the complete regulator configuration by moving some code around a little. Do so to avoid re-configuring the regulator multiple times, also avoiding the voltage glitches if we can. Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2106181066af7f5ab99d2d38bae6fd73ba4f086 Author: Dmitry Baryshkov Date: Tue Dec 30 09:17:57 2025 +0200 drm/msm/dpu: fix WD timer handling on DPU 8.x [ Upstream commit 794b0e68caba49b950b42ec32e364028c2facf57 ] Since DPU 8.x Watchdog timer settings were moved from the TOP to the INTF block. Support programming the timer in the INTF block. Fixes tag points to the commit which removed register access to those registers on DPU 8.x+ (and which also should have added proper support for WD timer on those devices). Fixes: 43e3293fc614 ("drm/msm/dpu: add support for MDP_TOP blackhole") Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696586/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-2-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit f5478534cd479012c7ed3bdd4f5dcdffa3b7b71c Author: Teguh Sobirin Date: Tue Dec 30 09:17:56 2025 +0200 drm/msm/dpu: Set vsync source irrespective of mdp top support [ Upstream commit 1ad9880f059c9b0943e53714f9a59924cb035bbb ] Since DPU 5.x the vsync source TE setup is split between MDP TOP and INTF blocks. Currently all code to setup vsync_source is only executed if MDP TOP implements the setup_vsync_source() callback. However on DPU >= 8.x this callback is not implemented, making DPU driver skip all vsync setup. Move the INTF part out of this condition, letting DPU driver to setup TE vsync selection on all new DPU devices. Signed-off-by: Teguh Sobirin Fixes: 2f69e5458447 ("drm/msm/dpu: skip watchdog timer programming through TOP on >= SM8450") [DB: restored top->ops.setup_vsync_source call] Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696584/ Link: https://lore.kernel.org/r/20251230-intf-fix-wd-v6-1-98203d150611@oss.qualcomm.com Signed-off-by: Sasha Levin commit 03306604738badd5a616f8d0db73267b8d2c0c84 Author: Mahadevan P Date: Thu Jan 1 10:34:38 2026 +0530 drm/msm/disp/dpu: add merge3d support for sc7280 [ Upstream commit 2892de3f4f985fa779c330468e2f341fdb762ccd ] On SC7280 targets, display modes with a width greater than the max_mixer_width (2400) are rejected during mode validation when merge3d is disabled. This limitation exists because, without a 3D merge block, two layer mixers cannot be combined(non-DSC interface), preventing large layers from being split across mixers. As a result, higher resolution modes cannot be supported. Enable merge3d support on SC7280 to allow combining streams from two layer mixers into a single non-DSC interface. This capability removes the width restriction and enables buffer sizes beyond the 2400-pixel limit. Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for SC7280 target") Signed-off-by: Mahadevan P Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/696713/ Link: https://lore.kernel.org/r/20260101-4k-v2-1-712ae3c1f816@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit ba4c9a09e36087ba2dcab6939434f209beb38027 Author: Srinivasan Shanmugam Date: Thu Dec 18 15:25:25 2025 +0530 drm/amdgpu: Use explicit VCN instance 0 in SR-IOV init [ Upstream commit af26fa751c2eef66916acbf0d3c3e9159da56186 ] vcn_v2_0_start_sriov() declares a local variable "i" initialized to zero and uses it only as the instance index in SOC15_REG_OFFSET(UVD, i, ...). The value is never changed and all other fields are taken from adev->vcn.inst[0], so this path only ever programs VCN instance 0. This triggered a Smatch: warn: iterator 'i' not incremented Replace the dummy iterator with an explicit instance index of 0 in SOC15_REG_OFFSET() calls. Fixes: dd26858a9cd8 ("drm/amdgpu: implement initialization part on VCN2.0 for SRIOV") Reported by: Dan Carpenter Cc: darlington Opara Cc: Jinage Zhao Cc: Monk Liu Cc: Emily Deng Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Emily Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d4c7c2cbdf93f14a8520f43ad3bdf8eb6ee1ebb Author: Srinivasan Shanmugam Date: Wed Dec 17 15:21:57 2025 +0530 drm/amdkfd: Fix signal_eviction_fence() bool return value [ Upstream commit 31dc58adda9874420ab8fa5a2f9c43377745753a ] signal_eviction_fence() is declared to return bool, but returns -EINVAL when no eviction fence is present. This makes the "no fence" or "the NULL-fence" path evaluate to true and triggers a Smatch warning. v2: Return true instead to explicitly indicate that there is no eviction fence to signal and that eviction is already complete. This matches the existing caller logic where a NULL fence means "nothing to do" and allows restore handling to proceed normally. (Christian) Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:2099 signal_eviction_fence() warn: '(-22)' is not bool drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c 2090 static bool signal_eviction_fence(struct kfd_process *p) ^^^^ 2091 { 2092 struct dma_fence *ef; 2093 bool ret; 2094 2095 rcu_read_lock(); 2096 ef = dma_fence_get_rcu_safe(&p->ef); 2097 rcu_read_unlock(); 2098 if (!ef) --> 2099 return -EINVAL; This should be either true or false. Probably true because presumably it has been tested? 2100 2101 ret = dma_fence_check_and_signal(ef); 2102 dma_fence_put(ef); 2103 2104 return ret; 2105 } Fixes: 37865e02e6cc ("drm/amdkfd: Fix eviction fence handling") Reported by: Dan Carpenter Cc: Philip Yang Cc: Gang BA Cc: Felix Kuehling Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9654ca3790b160cbdb1d1e019a64adef23c645ff Author: Mario Limonciello (AMD) Date: Sun Dec 14 19:12:19 2025 -0600 drm/amd: Drop "amdgpu kernel modesetting enabled" message [ Upstream commit 8644084a74a4573278d6f454c6638ccd5965f4e2 ] The behavior for amdgpu was changed with commit e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") to potentially allow loading even if nomodeset was set, so the message is no longer accurate. Just drop it to avoid confusion. Fixes: e00e5c223878 ("drm/amdgpu: adjust drm_firmware_drivers_only() handling") Signed-off-by: Mario Limonciello (AMD) Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 52defdd4034db1a34bb48006f889d66a3629224b Author: Zilin Guan Date: Tue Nov 11 14:57:06 2025 +0000 media: chips-media: wave5: Fix memory leak on codec_info allocation failure [ Upstream commit a519e21e32398459ba357e67b541402f7295ee1b ] In wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codec_info fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak. Fix this by calling kfree() on the instance in this error path to ensure it is properly released. Fixes: 9707a6254a8a6 ("media: chips-media: wave5: Add the v4l2 layer") Signed-off-by: Zilin Guan Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3ad42057c5b8c7fb807583554b3f51829adefddd Author: Cristian Ciocaltea Date: Wed Dec 31 22:04:15 2025 +0200 ASoC: nau8821: Fixup nau8821_enable_jack_detect() [ Upstream commit 70237853edf0a69773a7370eb74ea2a44dfe3050 ] The nau8821_enable_jack_detect() function was supposed to allow enabling or disabling jack events reporting. However, once enabled, any subsequent invocation would fail and the following splat is shown: [ 3136.996771] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 3136.996773] Workqueue: events_unbound deferred_probe_work_func [ 3136.996780] Call Trace: [ 3136.996782] [ 3136.996787] dump_stack_lvl+0x6e/0xa0 [ 3136.996796] __setup_irq.cold+0x9c/0xce [ 3136.996803] ? __pfx_irq_default_primary_handler+0x10/0x10 [ 3136.996812] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996825] request_threaded_irq+0xd9/0x160 [ 3136.996853] devm_request_threaded_irq+0x71/0xd0 [ 3136.996859] ? __pfx_nau8821_interrupt+0x10/0x10 [snd_soc_nau8821] [ 3136.996882] nau8821_enable_jack_detect+0xa5/0xc0 [snd_soc_nau8821] [ 3136.996901] acp5x_8821_init+0x8d/0xa0 [snd_soc_acp5x_mach] [ 3136.996917] snd_soc_link_init+0x25/0x50 [snd_soc_core] [ 3136.996958] snd_soc_bind_card+0x615/0xd00 [snd_soc_core] [ 3136.997026] snd_soc_register_card+0x1b2/0x1c0 [snd_soc_core] [ 3136.997064] devm_snd_soc_register_card+0x47/0x90 [snd_soc_core] [ 3136.997108] acp5x_probe+0x72/0xb0 [snd_soc_acp5x_mach] [...] [ 3136.997508] nau8821 i2c-NVTN2020:00: Cannot request irq 58 (-16) Introduce jdet_active flag to driver data structure and use it to provide one-time initialization of the jack detection work queue and related interrupt line. Note this is also a prerequisite for additional fixes around module unloading and suspend handling. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251231-nau8821-cleanup-v1-1-6b0b76cbbb64@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47e5bf04d05bca575a196f7a365c37e1ac9b98ce Author: Cristian Ciocaltea Date: Fri Oct 3 21:03:27 2025 +0300 ASoC: nau8821: Avoid unnecessary blocking in IRQ handler [ Upstream commit ee70bacef1c6050e4836409927294d744dbcfa72 ] The interrupt handler offloads the microphone detection logic to nau8821_jdet_work(), which implies a sleep operation. However, before being able to process any subsequent hotplug event, the interrupt handler needs to wait for any prior scheduled work to complete. Move the sleep out of jdet_work by converting it to a delayed work. This eliminates the undesired blocking in the interrupt handler when attempting to cancel a recently scheduled work item and should help reducing transient input reports that might confuse user-space. Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251003-nau8821-jdet-fixes-v1-5-f7b0e2543f09@collabora.com Signed-off-by: Mark Brown Stable-dep-of: 70237853edf0 ("ASoC: nau8821: Fixup nau8821_enable_jack_detect()") Signed-off-by: Sasha Levin commit bbedfab10d49230b631c6e0a3775e880b05c5910 Author: Cristian Ciocaltea Date: Fri Oct 3 21:03:25 2025 +0300 ASoC: nau8821: Consistently clear interrupts before unmasking [ Upstream commit a698679fe8b0fec41d1fb9547a53127a85c1be92 ] The interrupt handler attempts to perform some IRQ status clear operations *after* rather than *before* unmasking and enabling interrupts. This is a rather fragile approach since it may generally lead to missing IRQ requests or causing spurious interrupts. Make use of the nau8821_irq_status_clear() helper instead of manipulating the related register directly and ensure any interrupt clearing is performed *after* the target interrupts are disabled/masked and *before* proceeding with additional interrupt unmasking/enablement operations. This also implicitly drops the redundant clear operation of the ejection IRQ in the interrupt handler, since nau8821_eject_jack() has been already responsible for clearing all active interrupts. Fixes: aab1ad11d69f ("ASoC: nau8821: new driver") Fixes: 2551b6e89936 ("ASoC: nau8821: Add headset button detection") Signed-off-by: Cristian Ciocaltea Link: https://patch.msgid.link/20251003-nau8821-jdet-fixes-v1-3-f7b0e2543f09@collabora.com Signed-off-by: Mark Brown Stable-dep-of: 70237853edf0 ("ASoC: nau8821: Fixup nau8821_enable_jack_detect()") Signed-off-by: Sasha Levin commit f8071500177f38cff38892bd85ac631cc6e010b2 Author: Konstantin Andreev Date: Tue Sep 30 15:31:53 2025 +0300 smack: /smack/doi: accept previously used values [ Upstream commit 33d589ed60ae433b483761987b85e0d24e54584e ] Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: "_" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: "_" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 17da2a78bd3195995055178bc1c3dff878f03036 Author: Konstantin Andreev Date: Tue Sep 30 15:16:02 2025 +0300 smack: /smack/doi must be > 0 [ Upstream commit 19c013e1551bf51e1493da1270841d60e4fd3f15 ] /smack/doi allows writing and keeping negative doi values. Correct values are 0 < doi <= (max 32-bit positive integer) (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit b78e8a12edb3d78e9b2cd4af9cc5967cf94bb8f1 Author: Ketil Johnsen Date: Fri Dec 19 10:35:44 2025 +0100 drm/panthor: Evict groups before VM termination [ Upstream commit 565ed40b5fc1242f7538a016fce5a85f802d4fb5 ] Ensure all related groups are evicted and suspended before VM destruction takes place. This fixes an issue where panthor_vm_destroy() destroys and unmaps the heap context while there are still on slot groups using this. The FW will do a write out to the heap context when a CSG (group) is suspended, so a premature unmap of the heap context will cause a GPU page fault. This page fault is quite harmless, and do not affect the continued operation of the GPU. Fixes: 647810ec2476 ("drm/panthor: Add the MMU/VM logical block") Reviewed-by: Boris Brezillon Signed-off-by: Ketil Johnsen Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Link: https://patch.msgid.link/20251219093546.1227697-1-ketil.johnsen@arm.com Co-developed-by: Boris Brezillon Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit d12be704f7100afefc40c432e2ae410de688df5d Author: Takashi Iwai Date: Tue Dec 16 15:06:30 2025 +0100 ALSA: vmaster: Relax __free() variable declarations [ Upstream commit 3b7c7bda39e1e48f926fb3d280a5f5d20a939857 ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: fb9e197f3f27 ("ALSA: vmaster: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-9-tiwai@suse.de Signed-off-by: Sasha Levin commit 37135ec54b974bc0ab9c95a34ba1a1c6c6cdc2a0 Author: Takashi Iwai Date: Tue Dec 16 15:06:25 2025 +0100 ALSA: pcm: Relax __free() variable declarations [ Upstream commit f3d233daf011abbad2f6ebd0e545b42d2f378a4f ] We used to have a variable declaration with __free() initialized with NULL. This was to keep the old coding style rule, but recently it's relaxed and rather recommends to follow the new rule to declare in place of use for __free() -- which avoids potential deadlocks or UAFs with nested cleanups. Although the current code has no bug, per se, let's follow the new standard and move the declaration to the place of assignment (or directly assign the allocated result) instead of NULL initializations. Fixes: ae9213984864 ("ALSA: pcm: Use automatic cleanup of kfree()") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20251216140634.171890-4-tiwai@suse.de Signed-off-by: Sasha Levin commit 232cfc860a9d62dd520123fe68e756441a9f145e Author: Chenyuan Yang Date: Mon Jan 27 10:06:55 2025 -0600 ALSA: pcm: use new array-copying-wrapper [ Upstream commit 519b2b14bef70922bd64117a978ea7f2a683b75b ] This is found by our static analysis tool. pcm_native.c utilizes memdup_user() to copy an array from userspace. There is a new wrapper, specifically designed for copying arrays. Use this one instead. This is similar to the commit 3e91a38de1dc ("fbdev: viafb: use new array-copying-wrapper"). Signed-off-by: Chenyuan Yang Link: https://patch.msgid.link/20250127160655.3119470-1-cy1yang@outlook.com Signed-off-by: Takashi Iwai Stable-dep-of: f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") Signed-off-by: Sasha Levin commit a54e02cc637ba6390c95a162d34120b7cdf85042 Author: David Heidelberg Date: Sun Dec 14 15:51:21 2025 +0100 drm/panel: sw43408: Remove manual invocation of unprepare at remove [ Upstream commit cbc1e99a9e0a6c8b22ddcbb40ca37457066f9493 ] The drm_panel_remove should take care of disable/unprepare. Remove the manual call from the sw43408_remove function. Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Dmitry Baryshkov Signed-off-by: David Heidelberg Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20251214-pixel-3-v7-5-b1c0cf6f224d@ixit.cz Signed-off-by: Sasha Levin commit 00b16c7b17b494cacc68bca896fa362ebb9b4641 Author: Lai Jiangshan Date: Mon Dec 8 21:25:18 2025 +0800 workqueue: Process rescuer work items one-by-one using a cursor [ Upstream commit e5a30c303b07a4d6083e0f7f051b53add6d93c5d ] Previously, the rescuer scanned for all matching work items at once and processed them within a single rescuer thread, which could cause one blocking work item to stall all others. Make the rescuer process work items one-by-one instead of slurping all matches in a single pass. Break the rescuer loop after finding and processing the first matching work item, then restart the search to pick up the next. This gives normal worker threads a chance to process other items which gives them the opportunity to be processed instead of waiting on the rescuer's queue and prevents a blocking work item from stalling the rest once memory pressure is relieved. Introduce a dummy cursor work item to avoid potentially O(N^2) rescans of the work list. The marker records the resume position for the next scan, eliminating redundant traversals. Also introduce RESCUER_BATCH to control the maximum number of work items the rescuer processes in each turn, and move on to other PWQs when the limit is reached. Cc: ying chen Reported-by: ying chen Fixes: e22bee782b3b ("workqueue: implement concurrency managed dynamic worker pool") Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2178f0587c913fed1f5b3524be6b112eba3521b4 Author: Lai Jiangshan Date: Fri Nov 21 22:57:15 2025 +0800 workqueue: Only assign rescuer work when really needed [ Upstream commit 7b05c90b3302cf3d830dfa6f8961376bcaf43b94 ] If the pwq does not need rescue (normal workers have been created or become available), the rescuer can immediately move on to other stalled pwqs. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Stable-dep-of: e5a30c303b07 ("workqueue: Process rescuer work items one-by-one using a cursor") Signed-off-by: Sasha Levin commit fa80f288a5e408a78bdc33c47f3785974a19c73e Author: Lai Jiangshan Date: Fri Nov 21 22:57:14 2025 +0800 workqueue: Factor out assign_rescuer_work() [ Upstream commit 99ed6f62a46e91dc796b785618d646eeded1b230 ] Move the code to assign work to rescuer and assign_rescuer_work(). Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Stable-dep-of: e5a30c303b07 ("workqueue: Process rescuer work items one-by-one using a cursor") Signed-off-by: Sasha Levin commit 104504a773b3669252701f82174b9a6cf31e5517 Author: Boris Brezillon Date: Fri Nov 28 10:48:38 2025 +0100 drm/panthor: Make sure we resume the tick when new jobs are submitted [ Upstream commit 99820b4b7e50d9651f01d2d55b6b9ba92dcc5b99 ] If the group is already assigned a slot but was idle before this job submission, we need to make sure the priority rotation happens in the future. Extract the existing logic living in group_schedule_locked() and call this new sched_resume_tick() helper from the "group is assigned a slot" path. v2: - Add R-b v3: - Re-use queue_mask to clear the bit - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-8-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 47b2d73b5a0e13275afc87d3e375dfd668912abe Author: Boris Brezillon Date: Fri Nov 28 10:48:37 2025 +0100 drm/panthor: Fix the logic that decides when to stop ticking [ Upstream commit 61d9a43d70dc3e1709ecd14a34f6d5f01e21dfc9 ] When we have multiple active groups with the same priority, we need to keep ticking for the priority rotation to take place. If we don't do that, we might starve slots with lower priorities. It's annoying to deal with that in tick_ctx_update_resched_target(), so let's add a ::stop_tick field to the tick context which is initialized to true, and downgraded to false as soon as we detect something that requires to tick to happen. This way we can complement the current logic with extra conditions if needed. v2: - Add R-b v3: - Drop panthor_sched_tick_ctx::min_priority (no longer relevant) - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-7-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 4f74f3da52cb8123488ac0fbff87a0f7dc272b7b Author: Boris Brezillon Date: Fri Nov 28 10:48:36 2025 +0100 drm/panthor: Fix immediate ticking on a disabled tick [ Upstream commit 4356d21994f4ff5c87305b874939b359f16f6677 ] We have a few paths where we schedule the tick work immediately without changing the resched_target. If the tick was stopped, this would lead to a remaining_jiffies that's always > 0, and it wouldn't force a full tick in that case. Add extra checks to cover that case properly. v2: - Fix typo - Simplify the code as suggested by Steve v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-6-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit bab13dcc440473ca29bb6b60cca6bdea99f239ef Author: Boris Brezillon Date: Fri Nov 28 10:48:35 2025 +0100 drm/panthor: Fix the group priority rotation logic [ Upstream commit 55429c51d5db3db24c2ad561944c6a0ca922d476 ] When rotating group priorities, we want the group with the highest priority to go back to the end of the queue, and all other active groups to get their priority bumped, otherwise some groups will never get a chance to run with the highest priority. This implies moving the rotation itself to tick_work(), and only dealing with old group ordering in tick_ctx_insert_old_group(). v2: - Add R-b - Fix the commit message v3: - Drop the full_tick argument in tick_ctx_init() - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-5-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 202d532672b38b86d90e54a7c94c021a560e6e75 Author: Boris Brezillon Date: Fri Nov 28 10:48:34 2025 +0100 drm/panthor: Fix the full_tick check [ Upstream commit a3c2d0b40b108bd45d44f6c1dfa33c39d577adcd ] We have a full tick when the remaining time to the next tick is zero, not the other way around. Declare a full_tick variable so we don't get that test wrong in other places. v2: - Add R-b v3: - Collect R-b Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20251128094839.3856402-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 8ec4f1b14a6147db07d6e51aa1d6bcc799649847 Author: Boris Brezillon Date: Fri Nov 28 09:48:37 2025 +0100 drm/panthor: Recover from panthor_gpu_flush_caches() failures [ Upstream commit 3c0a60195b37af83bbbaf223cd3a78945bace49e ] We have seen a few cases where the whole memory subsystem is blocked and flush operations never complete. When that happens, we want to: - schedule a reset, so we can recover from this situation - in the reset path, we need to reset the pending_reqs so we can send new commands after the reset - if more panthor_gpu_flush_caches() operations are queued after the timeout, we skip them and return -EIO directly to avoid needless waits (the memory block won't miraculously work again) Note that we drop the WARN_ON()s because these hangs can be triggered with buggy GPU jobs created by the UMD, and there's no way we can prevent it. We do keep the error messages though. v2: - New patch v3: - Collect R-b - Explicitly mention the fact we dropped the WARN_ON()s in the commit message v4: - No changes Fixes: 5cd894e258c4 ("drm/panthor: Add the GPU logical block") Reviewed-by: Steven Price Link: https://patch.msgid.link/20251128084841.3804658-4-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit 50a74e38ded12c06919c417f3c77c08857558598 Author: Konrad Dybcio Date: Mon Dec 29 21:47:41 2025 +0100 arm64: dts: qcom: sm6115: Add CX_MEM/DBGC GPU regions [ Upstream commit 78c13dac18cf0e6f6cbc6ea85d4f967e6cca9562 ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 11750af256f8 ("arm64: dts: qcom: sm6115: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-3-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b5dc5990ee32265aca6373b24f2dfe4e893dac32 Author: Konrad Dybcio Date: Mon Dec 29 21:47:40 2025 +0100 arm64: dts: qcom: agatti: Add CX_MEM/DBGC GPU regions [ Upstream commit 0fdcc948929a6d673bd0f90631dd6e42090c3dbd ] Describe the GPU register regions, with the former existing but not being used much if at all on this silicon, and the latter containing various debugging levers generally related to dumping the state of the IP upon a crash. Fixes: 4faeef52c8e6 ("arm64: dts: qcom: qcm2290: Add GPU nodes") Reported-by: Krzysztof Kozlowski Closes: https://lore.kernel.org/linux-arm-msm/8a64f70b-8034-45e7-86a3-0015cf357132@oss.qualcomm.com/T/#m404f1425c36b61467760f058b696b8910340a063 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20251229-topic-6115_2290_gpu_dbgc-v1-2-4a24d196389c@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5d31ca77c7430225f3d3f143048ed6f1ab04b850 Author: Jonathan Marek Date: Thu Nov 27 16:29:42 2025 -0500 arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models) [ Upstream commit b38dd256e11a4c8bd5a893e11fc42d493939c907 ] Unlike the phone SoCs this was copied from, x1e has a 40-bit physical bus. The upper address space is used to support more than 32GB of memory. This fixes issues when DMA buffers are allocated outside the 36-bit range. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Jonathan Marek Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251127212943.24480-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 466400375386f0b2376459b497375d9f664c822f Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:18 2026 +0200 arm64: dts: qcom: sdm845-db845c: specify power for WiFi CH1 [ Upstream commit c303e89f7f17c29981d09f8beaaf60937ae8b1f2 ] Specify power supply for the second chain / antenna output of the onboard WiFi chip. Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-8-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e3e856e399edc96946dccd7ebb81bcb271382f92 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:17 2026 +0200 arm64: dts: qcom: sdm845-db845c: drop CS from SPIO0 [ Upstream commit 8bfb696ccdc5bcfad7a45b84c2c8a36757070e19 ] On SDM845 SPI uses hardware-provided chip select, while specifying cs-gpio makes the driver request GPIO pin, which on DB845c conflicts with the normal host controllers pinctrl entry. Drop the cs-gpios property to restore SPI functionality. Fixes: cb29e7106d4e ("arm64: dts: qcom: db845c: Add support for MCP2517FD") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-7-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 982a23d5d35b99128509ff01eefc9dbdde949fc0 Author: Dmitry Baryshkov Date: Tue Jan 6 03:01:16 2026 +0200 arm64: dts: qcom: qrb4210-rb2: Fix UART3 wakeup IRQ storm [ Upstream commit c5dc4812f6bf397b82290c540085e9ec98b47b30 ] Follow commit 9c92d36b0b1e ("arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm") and apply the similar fix to the RB2 platform. Having RX / TX pins as pull up and wakup interrupt as high-level triggered generates an interrupt storm when trying to suspend the device. Avoid the storm by using the falling edge trigger (as all other platforms do). Fixes: cab60b166575 ("arm64: dts: qcom: qrb4210-rb2: Enable bluetooth") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260106-wcn3990-pwrctl-v2-6-0386204328be@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8f15df824262196b3b2fdeaf4b38d8fb76c63917 Author: Jerome Brunet Date: Wed Jan 14 18:08:53 2026 +0100 arm64: dts: amlogic: g12: assign the MMC A signal clock [ Upstream commit 3c941feaa363f1573a501452391ddf513394c84b ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clock to make sure it is properly configured Fixes: 8a6b3ca2d361 ("arm64: dts: meson: g12a: add SDIO controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-6-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 041037a24fbed1b87f61917c5e81705acb3fd84d Author: Jerome Brunet Date: Wed Jan 14 18:08:52 2026 +0100 arm64: dts: amlogic: g12: assign the MMC B and C signal clocks [ Upstream commit be2ff5fdb0e83e32d4ec4e68a69875cec0d14621 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 4759fd87b928 ("arm64: dts: meson: g12a: add mmc nodes") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-5-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 8f5196fc8d17f65097688ed3e99e30042d306e95 Author: Jerome Brunet Date: Wed Jan 14 18:08:51 2026 +0100 arm64: dts: amlogic: gx: assign the MMC signal clocks [ Upstream commit 406706559046eebc09a31e8ae5e78620bfd746fe ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 50662499f911 ("ARM64: dts: meson-gx: Use correct mmc clock source 0") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-4-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0378739bc8ce8795aed700cfcbb180d916717f0b Author: Jerome Brunet Date: Wed Jan 14 18:08:50 2026 +0100 arm64: dts: amlogic: axg: assign the MMC signal clocks [ Upstream commit 13d3fe2318ef6e46d6fcfe13bc373827fdf2aeac ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 221cf34bac54 ("ARM64: dts: meson-axg: enable the eMMC controller") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-3-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit ddf288f21d7a49a2f189854eda84ae9cccb3e494 Author: Jerome Brunet Date: Wed Jan 14 18:08:48 2026 +0100 arm64: dts: amlogic: c3: assign the MMC signal clocks [ Upstream commit 69330fd2368371c4eb47d60ace6bca09763d24a0 ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. Assign the clocks to make sure they are properly configured Fixes: 520b792e8317 ("arm64: dts: amlogic: add some device nodes for C3") Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-mmc-clocks-followup-v1-1-a999fafbe0aa@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit d1ffd3c633a99e9411fb99aabe768a0a8815a119 Author: Haotian Zhang Date: Mon Nov 24 18:48:05 2025 +0800 hwspinlock: omap: Handle devm_pm_runtime_enable() errors [ Upstream commit 3bd4edd67b034f8e1f61c86e0eb098de6179e3f2 ] Although unlikely, devm_pm_runtime_enable() can fail due to memory allocations. Without proper error handling, the subsequent pm_runtime_resume_and_get() call may operate on incorrectly initialized runtime PM state. Add error handling to check the return value of devm_pm_runtime_enable() and return on failure. Fixes: 25f7d74d4514 ("hwspinlock: omap: Use devm_pm_runtime_enable() helper") Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251124104805.135-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 03af8c0d468edba28be3499cf44173dffb76d6be Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:13 2026 +0530 arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4 [ Upstream commit 61acc4428a7f52e0a13e226ba76f2ce2ca66c065 ] Each A72 core has one watchdog instance associated with it. Since j742s2 has 4 A72 cores, the common file should not define 8 watchdog instances. Refactor the last 4 extra watchdogs from the common file to j784s4 specific file, as j784s4 has 8 A72 cores and thus hardware description requires 8 watchdog instances. Fixes: 9cc161a4509c ("arm64: dts: ti: Refactor J784s4 SoC files to a common file") Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-3-a-kumar2@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 3f1cb740e890950574c9d698a6c58b915a562684 Author: Abhash Kumar Jha Date: Mon Jan 12 14:21:12 2026 +0530 arm64: dts: ti: k3-j784s4-main.dtsi: Move c71_3 node to appropriate order [ Upstream commit 24c9d5fb8bbf5e8c9e6fc2beffeb80ac2da83de4 ] The device tree nodes should be ordered by unit addresses in ascending order. Correct the order by moving the c71_3 DSP node at the end as it has a higher unit address. Signed-off-by: Abhash Kumar Jha Reviewed-by: Udit Kumar Link: https://patch.msgid.link/20260112085113.3476193-2-a-kumar2@ti.com Signed-off-by: Nishanth Menon Stable-dep-of: 61acc4428a7f ("arm64: dts: ti: k3-j784s4-j742s2-main-common.dtsi: Refactor watchdog instances for j784s4") Signed-off-by: Sasha Levin commit 448d14117381c28e8226698699c7ad5a17a99943 Author: Jerome Brunet Date: Wed Jan 14 11:43:12 2026 +0100 arm64: dts: amlogic: s4: fix mmc clock assignment [ Upstream commit 3a115d42922cffc91b303992eadf220111d66c31 ] MMC A and C are mis-represented as having their "clkin0" input connected to xtal while it is actually connected to the MMC clock, probably in an attempt to provide 24MHz to the device on this input. Fix this and assign the clock to 24MHz to actually provide the required rate. Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-2-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 6cdbd53e08676b5285e189eafa1ce19c542a817a Author: Jerome Brunet Date: Wed Jan 14 11:43:11 2026 +0100 arm64: dts: amlogic: s4: assign mmc b clock to 24MHz [ Upstream commit 86124a8becb43eed3103f2459399daee8af2c99d ] The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. This assumption did hold true until but it now, but it is apparently not the case with s4. The clock has been reported to provide 1GHz instead. This is most likely due to how the bootloader is using the MMC clock on this platform. Regardless of why the MMC clock rate is 1GHz, if the MMC driver expects 24MHz, the clock should be properly assigned, so assign it. Reported-by: Nick Xie Closes: https://lore.kernel.org/linux-amlogic/20260113011931.40424-1-nick@khadas.com/ Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie Signed-off-by: Jerome Brunet Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-1-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 3d9d76bfaf28ae225dc02fbb71b116dc9844c40a Author: AngeloGioacchino Del Regno Date: Fri Jan 9 12:47:41 2026 +0100 arm64: dts: mediatek: mt8183-jacuzzi-pico6: Fix typo in pinmux node [ Upstream commit b1fc81a986c9b8089db31e21a372cc8b6514e900 ] Rename "piins-bt-wakeup" to "pins-bt-wakeup" to fix a dtbs_check warning happening due to this typo. Fixes: 055ef10ccdd4 ("arm64: dts: mt8183: Add jacuzzi pico/pico6 board") Reviewed-by: Chen-Yu Tsai Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit e018f7d42b5888f62cb490ba44f34fcdf17e4e40 Author: Vladimir Zapolskiy Date: Mon Dec 29 00:49:07 2025 +0200 arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree node [ Upstream commit 71630e581a0e34c03757f5c1706f57c853b92555 ] Motor Control PWM depends on its own supply clock, the clock gate control is present in TIMCLK_CTRL1 register. Fixes: b7d41c937ed7 ("ARM: LPC32xx: Add the motor PWM to base dts file") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin commit 4b992b5cadf6d2920b1a8f0487c32d84f2cf6bb4 Author: Vladimir Zapolskiy Date: Thu Sep 4 21:46:42 2025 +0300 ARM: dts: lpc32xx: Set motor PWM #pwm-cells property value to 3 cells [ Upstream commit 65ae9ea77e1f2a20ad2866f99596df7ccdbd3b95 ] Since commit 4cd2f417a0ac ("dt-bindings: pwm: Convert lpc32xx-pwm.txt to yaml format") both types of PWM controlles on NXP LPC32xx SoC fairly gained 3 cells, reflect it in the platform dtsi file. The change removes a dt binding checker warning: mpwm@400e8000: #pwm-cells:0:0: 3 was expected Cc: Uwe Kleine-König Acked-by: Uwe Kleine-König Reviewed-by: Frank Li Signed-off-by: Vladimir Zapolskiy Stable-dep-of: 71630e581a0e ("arm: dts: lpc32xx: add clocks property to Motor Control PWM device tree node") Signed-off-by: Sasha Levin commit f8b16d5764ee1e78c1ef333017ad383ffe76fcdc Author: Narayana Murty N Date: Wed Dec 10 08:25:59 2025 -0600 powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling [ Upstream commit 815a8d2feb5615ae7f0b5befd206af0b0160614c ] The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled. eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions: eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c000000000050434] eeh_handle_normal_event+0x64/0xa60 [ 84.964446] [ T928] [c0000011a7157f30] [c000000000051de8] eeh_event_handler+0xf8/0x190 [ 84.964450] [ T928] [c0000011a7157f90] [c0000000002747ac] kthread+0x16c/0x180 [ 84.964453] [ T928] [c0000011a7157fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Signed-off-by: Narayana Murty N Reviewed-by: Sourabh Jain Reviewed-by: Mahesh Salgaonkar Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251210142559.8874-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin commit a58c97828911c0b6e25d6b556789da974003efda Author: Zilin Guan Date: Sun Dec 28 16:26:36 2025 +0000 soc: mediatek: svs: Fix memory leak in svs_enable_debug_write() [ Upstream commit 6259094ee806fb813ca95894c65fb80e2ec98bf1 ] In svs_enable_debug_write(), the buf allocated by memdup_user_nul() is leaked if kstrtoint() fails. Fix this by using __free(kfree) to automatically free buf, eliminating the need for explicit kfree() calls and preventing leaks. Fixes: 13f1bbcfb582 ("soc: mediatek: SVS: add debug commands") Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan [Angelo: Added missing cleanup.h inclusion] Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit cdcc7e335f2dfe9a9801d7f68fce1da211de64cf Author: Haotian Zhang Date: Tue Dec 16 09:39:32 2025 +0800 soc: qcom: cmd-db: Use devm_memremap() to fix memory leak in cmd_db_dev_probe [ Upstream commit 0da7824734d8d83e6a844dd0207f071cb0c50cf4 ] If cmd_db_magic_matches() fails after memremap() succeeds, the function returns -EINVAL without unmapping the memory region, causing a potential resource leak. Switch to devm_memremap to automatically manage the map resource. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Suggested-by: Dmitry Baryshkov Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251216013933.773-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 682d9d73d513728c2c119b94660d85b79d6f65b6 Author: Christophe Leroy Date: Wed Dec 24 12:20:49 2025 +0100 powerpc/uaccess: Move barrier_nospec() out of allow_read_{from/write}_user() [ Upstream commit 5fbc09eb0b4f4b1a4b33abebacbeee0d29f195e9 ] Commit 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") added a redundant barrier_nospec() in copy_from_user(), because powerpc is already calling barrier_nospec() in allow_read_from_user() and allow_read_write_user(). But on other architectures that call to barrier_nospec() was missing. So change powerpc instead of reverting the above commit and having to fix other architectures one by one. This is now possible because barrier_nospec() has also been added in copy_from_user_iter(). Move barrier_nospec() out of allow_read_from_user() and allow_read_write_user(). This will also allow reuse of those functions when implementing masked user access which doesn't require barrier_nospec(). Don't add it back in raw_copy_from_user() as it is already called by copy_from_user() and copy_from_user_iter(). Fixes: 74e19ef0ff80 ("uaccess: Add speculation barrier to copy_from_user()") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f29612105c5fcbc8ceb7303808ddc1a781f0f6b5.1766574657.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit 37cf81576dff3dee1a4900976f2c5069e2c17e4e Author: Chen-Yu Tsai Date: Thu Dec 25 18:36:14 2025 +0800 ARM: dts: allwinner: sun5i-a13-utoo-p66: delete "power-gpios" property [ Upstream commit 0b2761eb1287bd9f62367cccf6626eb3107cef6f ] The P66's device tree includes the reference design dtsi files, which defines a node and properties for the touchpanel in the common design. The P66 dts file then overrides all the properties to match its own design, but as the touchpanel model is different, a different schema is matched. This other schema uses a different name for the GPIO. The original submission added the correct GPIO property, but did not delete the one inherited from the reference design, causing validation errors. Explicitly delete the incorrect GPIO property. Fixes: 2a53aff27236 ("ARM: dts: sun5i: Enable touchscreen on Utoo P66") Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20251225103616.3203473-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 5a6ebb6cc3c5cb940b5934a06401dbb85a84d485 Author: Vladimir Zapolskiy Date: Fri Dec 26 02:39:23 2025 +0200 arm64: dts: qcom: msm8994-octagon: Fix Analog Devices vendor prefix of AD7147 [ Upstream commit 7db5fbe508deedec6c183d5056cf3c504c027f40 ] Trivial change, Analog Devices vendor prefix is "adi", but there is a valid "ad" vendor prefix of another company, this may explain why the issue hasn't been discovered by the automatic tests. A problem of not described compatible value is out of this change scope. Fixes: c636eeb751f6 ("arm64: dts: qcom: msm8994-octagon: Add AD7147 and APDS9930 sensors") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251226003923.3341904-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit dce238e12d94a7bd7bf53f25b1c1c3834cb1f519 Author: Abel Vesa Date: Mon Nov 3 18:51:40 2025 +0200 arm64: dts: qcom: x1e80100: Fix USB combo PHYs SS1 and SS2 ref clocks [ Upstream commit 3af51501e2b8c87564b5cda43b0e5c316cf54717 ] It seems the USB combo SS1 and SS2 ref clocks have another gate, unlike the SS0. These gates are part of the TCSR clock controller. At least on Dell XPS 13 (9345), if the ref clock provided by the TCSR clock controller for SS1 PHY is disabled on the clk_disable_unused late initcall, the PHY fails to initialize. It doesn't happen on the SS0 PHY and the SS2 is not used on this device. This doesn't seem to be a problem on CRD though. It might be that the RPMh has a vote for it from some other consumer and does not actually disable it when ther kernel drops its vote. Either way, these TCSR provided clocks seem to be the correct ones for the SS1 and SS2, so use them instead. Fixes: 4af46b7bd66f ("arm64: dts: qcom: x1e80100: Add USB nodes") Signed-off-by: Abel Vesa Reviewed-by: Neil Armstrong Reviewed-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251103-dts-qcom-x1e80100-fix-combo-ref-clks-v1-1-f395ec3cb7e8@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a7037c3eb0130a6167138e69178895b22758d7f3 Author: Casey Connolly Date: Tue Nov 18 15:52:27 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Mark l14a regulator as boot-on [ Upstream commit ad33ee060be46794a03d033894c9db3a9d6c1a0f ] This regulator is used only for the display, which is enabled by the bootloader and left on for continuous splash. Mark it as such. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-3-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c818d840c87866ef5246c73cdfa17c56e6667555 Author: Casey Connolly Date: Tue Nov 18 15:52:25 2025 +0100 arm64: dts: qcom: sdm845-oneplus: Don't mark ts supply boot-on [ Upstream commit c9b98b9dad9749bf2eb7336a6fca31a6af1039d7 ] The touchscreen isn't enabled by bootloader and doesn't need to be enabled at boot, only when the driver probes, thus remove the regulator-boot-on property. Fixes: 288ef8a42612 ("arm64: dts: sdm845: add oneplus6/6t devices") Signed-off-by: Casey Connolly Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251118-dts-oneplus-regulators-v2-1-3e67cea1e4e7@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cd4b042521d202c346bcda7c77f89c536396b7ed Author: Dmitry Baryshkov Date: Thu Dec 11 03:27:45 2025 +0200 arm64: dts: qcom: sdm630: fix gpu_speed_bin size [ Upstream commit e814796dfcae8905682ac3ac2dd57f512a9f6726 ] Historically sdm630.dtsi has used 1 byte length for the gpu_speed_bin cell, although it spans two bytes (offset 5, size 7 bits). It was being accepted by the kernel because before the commit 7a06ef751077 ("nvmem: core: fix bit offsets of more than one byte") the kernel didn't have length check. After this commit nvmem core rejects QFPROM on sdm630 / sdm660, making GPU and USB unusable on those platforms. Set the size of the gpu_speed_bin cell to 2 bytes, fixing the parsing error. While we are at it, update the length to 8 bits as pointed out by Alexey Minnekhanov. Fixes: b190fb010664 ("arm64: dts: qcom: sdm630: Add sdm630 dts file") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Alexey Minnekhanov Link: https://lore.kernel.org/r/20251211-sdm630-fix-gpu-v2-1-92f0e736dba0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7aaa4384b871229c03c66a8d371d931a78fe3cae Author: Haotian Zhang Date: Wed Dec 17 12:13:38 2025 +0800 clk: qcom: Return correct error code in qcom_cc_probe_by_index() [ Upstream commit 1e07ebe744fb522983bd52a4a6148601675330c7 ] When devm_platform_ioremap_resource() fails, it returns various error codes. Returning a hardcoded -ENOMEM masks the actual failure reason. Use PTR_ERR() to propagate the actual error code returned by devm_platform_ioremap_resource() instead of -ENOMEM. Fixes: 75e0a1e30191 ("clk: qcom: define probe by index API as common API") Signed-off-by: Haotian Zhang Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20251217041338.2432-1-vulab@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5c85820e390558ab7a3e2bb5ac4e9872dca98ce1 Author: Alexander Stein Date: Tue Dec 9 11:53:13 2025 +0100 arm64: dts: tqma8mpql-mba8mp-ras314: Fix HDMI CEC pad control settings [ Upstream commit 53a5c1d98d1155ece4c9446c0fea55e17d08774a ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 255af53a67e18df49817991a6675102265ef3152 Author: Alexander Stein Date: Tue Dec 9 11:53:09 2025 +0100 arm64: dts: tqma8mpql-mba8mpxl: Fix HDMI CEC pad control settings [ Upstream commit 8401527abb5e3a00c867b6597b8e1b29c80c9824 ] As per datasheet of the HDMI protection IC the CEC_IC pin has been configured as open-drain. Fixes: 418d1d840e42 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4a4ffd352a693af17482085e3de9f859badd14bc Author: Sudeep Holla Date: Thu Dec 18 14:20:01 2025 +0000 firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET [ Upstream commit be4d4543f78074fbebd530ba5109d39a2a34e668 ] The FF-A specification allows NOTIFICATION_INFO_GET to return either a 64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on whether the firmware chooses the SMC64 or SMC32 calling convention. The driver previously detected the response format by checking ret.a0, but still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of each argument register are undefined by the calling convention, meaning the driver could read stale or garbage values when parsing notification IDs. This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A firmware used an SMC32 return path. Fix the issue by: - Introducing logic to map list indices to the correct u16 offsets, depending on whether the response width matches the kernel word size or is a 32-bit response on a 64-bit kernel. - Ensuring that the packed ID list is parsed using the proper layout, avoiding reads from undefined upper halves in the SMC32 case. With this change, NOTIFICATION_INFO_GET now correctly interprets ID list entries regardless of the response width, aligning the driver with the FF-A specification. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Sourav Mohapatra Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit dca904ffd751f23117601d240e47bfe0436cfdc4 Author: Dan Carpenter Date: Tue Dec 9 17:37:04 2025 +0300 EDAC/i5400: Fix snprintf() limit calculation in calculate_dimm_size() [ Upstream commit 72f12683611344853ab030fe7d19b23970ed2bd8 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But my static checker complains because the limit calculation doesn't take the first 11 space characters that we wrote into the buffer into consideration. Fix this for the sake of correctness even though it doesn't affect runtime. Also delete an earlier "space -= n;" which was not used. Fixes: 68d086f89b80 ("i5400_edac: improve debug messages to better represent the filled memory") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/ccd06b91748e7ed8e33eeb2ff1e7b98700879304.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit 1fd7c29a1543f66accee5b2ad726207ac78f3b8e Author: Dan Carpenter Date: Tue Dec 9 17:36:59 2025 +0300 EDAC/i5000: Fix snprintf() size calculation in calculate_dimm_size() [ Upstream commit 7b5c7e83ac405ff9ecbdd92b37a477f4288f8814 ] The snprintf() can't really overflow because we're writing a max of 42 bytes to a PAGE_SIZE buffer. But the limit calculation doesn't take the first 11 bytes that we wrote into consideration so the limit is not correct. Just fix it for correctness even though it doesn't affect runtime. Fixes: 64e1fdaf55d6 ("i5000_edac: Fix the logic that retrieves memory information") Signed-off-by: Dan Carpenter Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Link: https://patch.msgid.link/07cd652c51e77aad5a8350e1a7cd9407e5bbe373.1765290801.git.dan.carpenter@linaro.org Signed-off-by: Sasha Levin commit 35b034cfddca3ed379d854a133cb4809966ec0d9 Author: Jorge Ramirez-Ortiz Date: Tue Dec 9 08:45:37 2025 +0100 soc: qcom: smem: handle ENOMEM error during probe [ Upstream commit 0fe01a7955f4fef97e7cc6d14bfc5931c660402b ] Fail the driver probe if the region can't be mapped Signed-off-by: Jorge Ramirez-Ortiz Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20251209074610.3751781-1-jorge.ramirez@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9a6fc69a570c0780834246d52c856cc3dbc2605f Author: Sai Ritvik Tanksalkar Date: Sun Feb 1 13:22:40 2026 +0000 pstore/ram: fix buffer overflow in persistent_ram_save_old() [ Upstream commit 5669645c052f235726a85f443769b6fc02f66762 ] persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. Fixes: 201e4aca5aa1 ("pstore/ram: Should update old dmesg buffer before reading") Signed-off-by: Sai Ritvik Tanksalkar Link: https://patch.msgid.link/20260201132240.2948732-1-stanksal@purdue.edu Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit d5b7730f06994499632026c30e38e0317c4569e2 Author: Lianjie Wang Date: Fri Jan 30 06:50:16 2026 +0900 hwrng: core - use RCU and work_struct to fix race condition [ Upstream commit cc2f39d6ac48e6e3cb2d6240bc0d6df839dd0828 ] Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task. Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs: refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held. To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct. Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers. With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever. Fixes: be4000bc4644 ("hwrng: create filler thread") Suggested-by: Herbert Xu Signed-off-by: Lianjie Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 24761c8441c4dcc0b936adface253e9f389d00f0 Author: Jonathan McDowell Date: Tue Sep 23 14:33:05 2025 +0100 hwrng: core - Allow runtime disabling of the HW RNG [ Upstream commit e74b96d77da9eb5ee1b603c937c2adab5134a04b ] The HW RNG core allows for manual selection of which RNG device to use, but does not allow for no device to be enabled. It may be desirable to do this on systems with only a single suitable hardware RNG, where we need exclusive access to other functionality on this device. In particular when performing TPM firmware upgrades this lets us ensure the kernel does not try to access the device. Before: root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 After: root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 root@debian-qemu-efi:~# echo none > /sys/devices/virtual/misc/hw_random/rng_current root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:none grep: /sys/devices/virtual/misc/hw_random/rng_quality: No such device /sys/devices/virtual/misc/hw_random/rng_selected:1 (Observe using bpftrace no calls to TPM being made) root@debian-qemu-efi:~# echo "" > /sys/devices/virtual/misc/hw_random/rng_current root@debian-qemu-efi:~# grep "" /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:tpm-rng-0 none /sys/devices/virtual/misc/hw_random/rng_current:tpm-rng-0 /sys/devices/virtual/misc/hw_random/rng_quality:1024 /sys/devices/virtual/misc/hw_random/rng_selected:0 (Observe using bpftrace that calls to the TPM resume) Signed-off-by: Jonathan McDowell Signed-off-by: Herbert Xu Stable-dep-of: cc2f39d6ac48 ("hwrng: core - use RCU and work_struct to fix race condition") Signed-off-by: Sasha Levin commit 38d80307decc1132626a30e2a62af734630ecca5 Author: Zilin Guan Date: Thu Jan 29 15:10:16 2026 +0000 crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req() [ Upstream commit ccb679fdae2e62ed92fd9acb25ed809c0226fcc6 ] The starfive_aes_aead_do_one_req() function allocates rctx->adata with kzalloc() but fails to free it if sg_copy_to_buffer() or starfive_aes_hw_init() fails, which lead to memory leaks. Since rctx->adata is unconditionally freed after the write_adata operations, ensure consistent cleanup by freeing the allocation in these earlier error paths as well. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests") Signed-off-by: Zilin Guan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit acd06323c2c4a486fcc1911b1968ff90410d8cd0 Author: Titouan Ameline de Cadeville Date: Tue Feb 3 18:59:50 2026 +0100 fs/tests: exec: drop duplicate bprm_stack_limits test vectors [ Upstream commit 46a03ea50b5f380bdb99178b8f90b39c6ba1f528 ] Remove duplicate entries from the bprm_stack_limits KUnit test vector table. The duplicates do not add coverage and only increase test size. Signed-off-by: Titouan Ameline de Cadeville Fixes: 60371f43e56b ("exec: Add KUnit test for bprm_stack_limits()") Link: https://patch.msgid.link/20260203175950.43710-1-titouan.ameline@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit a6a73403733e86748421f2eeaf028c85683ef896 Author: Chen Jinghuang Date: Thu Jan 22 01:25:33 2026 +0000 sched/rt: Skip currently executing CPU in rto_next_cpu() [ Upstream commit 94894c9c477e53bcea052e075c53f89df3d2a33e ] CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) Suggested-by: K Prateek Nayak Signed-off-by: Chen Jinghuang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Reviewed-by: Valentin Schneider Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Sasha Levin commit 375622de010fe29f80002a38c689e9b60f12370c Author: Joel Fernandes Date: Mon Jan 26 10:58:59 2026 +0100 sched/deadline: Clear the defer params [ Upstream commit 3cb3b27693bf30defb16aa096158a3b24583b8d2 ] The defer params were not cleared in __dl_clear_params. Clear them. Without this is some of my test cases are flaking and the DL timer is not starting correctly AFAICS. Fixes: a110a81c52a9 ("sched/deadline: Deferrable dl server") Signed-off-by: Joel Fernandes Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andrea Righi Acked-by: Juri Lelli Tested-by: Christian Loehle Link: https://patch.msgid.link/20260126100050.3854740-2-arighi@nvidia.com Signed-off-by: Sasha Levin commit 6e661a23d886c9d8dbff426c681ad94efbe3fb44 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:40 2026 +0100 media: pci: mg4b: Use IRQF_NO_THREAD [ Upstream commit ef92b98f5f6758a049898b53aa30476010db04fa ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handlers and this supposed to happen from hard interrupt context. Use IRQF_NO_THREAD to forbid forced-threading. Fixes: 0ab13674a9bd1 ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-21-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 8da4ba1694356423a86b30e263269f8720106910 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:35 2026 +0100 mfd: wm8350-core: Use IRQF_ONESHOT [ Upstream commit 553b4999cbe231b5011cb8db05a3092dec168aca ] Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Mark explained that this should not happen with this hardware since it is a slow irqchip which is behind an I2C/ SPI bus but the IRQ-core will refuse to accept such a handler. Set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 1c6c69525b40e ("genirq: Reject bogus threaded irq requests") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Charles Keepax Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260128095540.863589-16-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 670abc7e5694088ea8ba28598880eec0d626593c Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:30 2026 +0100 EDAC/altera: Remove IRQF_ONESHOT [ Upstream commit 5c858d6c66304b4c7579582ec5235f02d43578ea ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt can not fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. Remove IRQF_ONESHOT from irqflags. Fixes: a29d64a45eed1 ("EDAC, altera: Add IRQ Flags to disable IRQ while handling") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-11-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit fb7481344f9ee9b0bc545db2cb3e6ea9c26af289 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:27 2026 +0100 scsi: efct: Use IRQF_ONESHOT and default primary handler [ Upstream commit bd81f07e9a27c341cd7e72be95eb0b7cf3910926 ] There is no added value in efct_intr_msix() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 4df84e8466242 ("scsi: elx: efct: Driver initialization routines") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-8-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit be3ff229b90aa92ea35383fd22a1867cad632033 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:26 2026 +0100 Bluetooth: btintel_pcie: Use IRQF_ONESHOT and default primary handler [ Upstream commit 28abed6569c87eab9071ab56c64433c2f0d9ce51 ] There is no added value in btintel_pcie_msix_isr() compared to irq_default_primary_handler(). Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Use the default primary interrupt handler by specifying NULL and set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: c2b636b3f788d ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-7-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 5938fb0e328508a50c334852e30f02ecc28b74d6 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:22 2026 +0100 platform/x86: int0002: Remove IRQF_ONESHOT from request_irq() [ Upstream commit f6bc712877f24dc89bdfd7bdbf1a32f3b9960b34 ] Passing IRQF_ONESHOT ensures that the interrupt source is masked until the secondary (threaded) handler is done. If only a primary handler is used then the flag makes no sense because the interrupt cannot fire (again) while its handler is running. The flag also prevents force-threading of the primary handler and the irq-core will warn about this. The flag was added to match the flag on the shared handler which uses a threaded handler and therefore IRQF_ONESHOT. This is no longer needed because devm_request_irq() now passes IRQF_COND_ONESHOT for this case. Revert adding IRQF_ONESHOT to irqflags. Fixes: 8f812373d1958 ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") Reported-by: Borah, Chaitanya Kumar Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Hans de Goede Acked-by: Ilpo Järvinen Link: https://patch.msgid.link/20260128095540.863589-3-bigeasy@linutronix.de Closes: https://lore.kernel.org/all/555f1c56-0f74-41bf-8bd2-6217e0aab0c6@intel.com Signed-off-by: Sasha Levin commit a13566c2f7b72c69337005e01633468ceaff1468 Author: Sebastian Andrzej Siewior Date: Wed Jan 28 10:55:21 2026 +0100 genirq: Set IRQF_COND_ONESHOT in devm_request_irq(). [ Upstream commit 943b052ded21feb84f293d40b06af3181cd0d0d7 ] The flag IRQF_COND_ONESHOT was already force-added to request_irq() because the ACPI SCI interrupt handler is using the IRQF_ONESHOT flag which breaks all shared handlers. devm_request_irq() needs the same change since some users, such as int0002_vgpio, are using this function instead. Add IRQF_COND_ONESHOT to the flags passed to devm_request_irq(). Fixes: c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260128095540.863589-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 0db169a91381a473b7974021d1c02f8da72c5775 Author: Paul Chaignon Date: Sat Jan 31 17:08:37 2026 +0100 bpf: Fix bpf_xdp_store_bytes proto for read-only arg [ Upstream commit 6557f1565d779851c4db9c488c49c05a47a6e72f ] While making some maps in Cilium read-only from the BPF side, we noticed that the bpf_xdp_store_bytes proto is incorrect. In particular, the verifier was throwing the following error: ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4 nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE. The verifier checks the helper's memory access to R3 in check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails. Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading from uninitialized memory. This patch simply fixes the expected argument type to match that of bpf_skb_store_bytes. Fixes: 3f364222d032 ("net: xdp: introduce bpf_xdp_pointer utility routine") Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/9fa3c9f72d806e82541071c4df88b8cba28ad6a9.1769875479.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d5c6f254528caf78d5de7d9646dc21c81d351827 Author: Jianpeng Chang Date: Tue Jan 20 09:55:24 2026 +0800 crypto: caam - fix netdev memory leak in dpaa2_caam_probe [ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ] When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang Reviewed-by: Breno Leitao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 96bac9ce2292fbcb7f2e2992497c5a2700dc3328 Author: Weili Qian Date: Sat Jan 17 15:18:21 2026 +0800 crypto: hisilicon/trng - support tfms sharing the device [ Upstream commit 3d3135057ff567d5c09fff4c9ef6391a684e8042 ] Since the number of devices is limited, and the number of tfms may exceed the number of devices, to ensure that tfms can be successfully allocated, support tfms sharing the same device. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a9c6d178d82256c0648e04897a19017d714a346d Author: Jiri Olsa Date: Mon Jan 26 22:18:33 2026 +0100 x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path [ Upstream commit aea251799998aa1b78eacdfb308f18ea114ea5b3 ] Mahe reported missing function from stack trace on top of kprobe multi program. The missing function is the very first one in the stacktrace, the one that the bpf program is attached to. # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 ('*' is used for kprobe_multi attachment) The reason is that the previous change (the Fixes commit) fixed stack unwind for tracepoint, but removed attached function address from the stack trace on top of kprobe multi programs, which I also overlooked in the related test (check following patch). The tracepoint and kprobe_multi have different stack setup, but use same unwind path. I think it's better to keep the previous change, which fixed tracepoint unwind and instead change the kprobe multi unwind as explained below. The bpf program stack unwind calls perf_callchain_kernel for kernel portion and it follows two unwind paths based on X86_EFLAGS_FIXED bit in pt_regs.flags. When the bit set we unwind from stack represented by pt_regs argument, otherwise we unwind currently executed stack up to 'first_frame' boundary. The 'first_frame' value is taken from regs.rsp value, but ftrace_caller and ftrace_regs_caller (ftrace trampoline) functions set the regs.rsp to the previous stack frame, so we skip the attached function entry. If we switch kprobe_multi unwind to use the X86_EFLAGS_FIXED bit, we set the start of the unwind to the attached function address. As another benefit we also cut extra unwind cycles needed to reach the 'first_frame' boundary. The speedup can be measured with trigger bench for kprobe_multi program and stacktrace support. - trigger bench with stacktrace on current code: kprobe-multi : 0.810 ± 0.001M/s kretprobe-multi: 0.808 ± 0.001M/s - and with the fix: kprobe-multi : 1.264 ± 0.001M/s kretprobe-multi: 1.401 ± 0.002M/s With the fix, the entry probe stacktrace: # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... __x64_sys_newuname+9 do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 The return probe skips the attached function, because it's no longer on the stack at the point of the unwind and this way is the same how standard kretprobe works. # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}' Attaching 1 probe... do_syscall_64+134 entry_SYSCALL_64_after_hwframe+118 Fixes: 6d08340d1e35 ("Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"") Reported-by: Mahe Tardy Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: Steven Rostedt (Google) Link: https://lore.kernel.org/bpf/20260126211837.472802-3-jolsa@kernel.org Signed-off-by: Sasha Levin commit 41d766859df7f31d8af03e7177ea3663eeec3a61 Author: Jiri Olsa Date: Tue Nov 4 22:54:03 2025 +0100 x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe [ Upstream commit 20a0bc10272fa17a44fc857c31574a8306f60d20 ] Currently we don't get stack trace via ORC unwinder on top of fgraph exit handler. We can see that when generating stacktrace from kretprobe_multi bpf program which is based on fprobe/fgraph. The reason is that the ORC unwind code won't get pass the return_to_handler callback installed by fgraph return probe machinery. Solving this by creating stack frame in return_to_handler expected by ftrace_graph_ret_addr function to recover original return address and continue with the unwind. Also updating the pt_regs data with cs/flags/rsp which are needed for successful stack retrieval from ebpf bpf_get_stackid helper. - in get_perf_callchain we check user_mode(regs) so CS has to be set - in perf_callchain_kernel we call perf_hw_regs(regs), so EFLAGS/FIXED has to be unset Acked-by: Masami Hiramatsu (Google) Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20251104215405.168643-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Acked-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit 3eb79d8d02c72f9de0b37c329e2afb7ecaefba58 Author: Masami Hiramatsu (Google) Date: Thu Dec 26 14:12:59 2024 +0900 tracing: Add ftrace_fill_perf_regs() for perf event [ Upstream commit d5d01b71996ec03af51b3c0736c92d0fc89703b5 ] Add ftrace_fill_perf_regs() which should be compatible with the perf_fetch_caller_regs(). In other words, the pt_regs returned from the ftrace_fill_perf_regs() must satisfy 'user_mode(regs) == false' and can be used for stack tracing. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Will Deacon Acked-by: Heiko Carstens # s390 Cc: Alexei Starovoitov Cc: Florent Revest Cc: Martin KaFai Lau Cc: bpf Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Alan Maguire Cc: Heiko Carstens Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Naveen N Rao Cc: Madhavan Srinivasan Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Cc: "H. Peter Anvin" Link: https://lore.kernel.org/173518997908.391279.15910334347345106424.stgit@devnote2 Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit a142bbc11f8b68358398c7195e62e8dba3164679 Author: Masami Hiramatsu (Google) Date: Thu Dec 26 14:12:47 2024 +0900 tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs [ Upstream commit b9b55c8912ce1e5555715d126486bdd63ddfeaec ] Add ftrace_partial_regs() which converts the ftrace_regs to pt_regs. This is for the eBPF which needs this to keep the same pt_regs interface to access registers. Thus when replacing the pt_regs with ftrace_regs in fprobes (which is used by kprobe_multi eBPF event), this will be used. If the architecture defines its own ftrace_regs, this copies partial registers to pt_regs and returns it. If not, ftrace_regs is the same as pt_regs and ftrace_partial_regs() will return ftrace_regs::regs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Florent Revest Cc: Alexei Starovoitov Cc: Martin KaFai Lau Cc: bpf Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Alan Maguire Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Link: https://lore.kernel.org/173518996761.391279.4987911298206448122.stgit@devnote2 Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit 33d4e904e24d14ff0fbc528b657ddc7c7b636e6a Author: Masami Hiramatsu (Google) Date: Thu Dec 26 14:11:55 2024 +0900 fgraph: Replace fgraph_ret_regs with ftrace_regs [ Upstream commit a3ed4157b7d89800a0008de0c9e46a438a5c3745 ] Use ftrace_regs instead of fgraph_ret_regs for tracing return value on function_graph tracer because of simplifying the callback interface. The CONFIG_HAVE_FUNCTION_GRAPH_RETVAL is also replaced by CONFIG_HAVE_FUNCTION_GRAPH_FREGS. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Heiko Carstens Acked-by: Will Deacon Cc: Catalin Marinas Cc: Alexei Starovoitov Cc: Florent Revest Cc: Martin KaFai Lau Cc: bpf Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Alan Maguire Cc: Mark Rutland Cc: Huacai Chen Cc: WANG Xuerui Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: Mathieu Desnoyers Link: https://lore.kernel.org/173518991508.391279.16635322774382197642.stgit@devnote2 Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit fee2da39408563e6a3bf9b324c0adac2d7f63534 Author: Masami Hiramatsu (Google) Date: Tue Oct 15 10:28:53 2024 +0900 ftrace: Rename ftrace_regs_return_value to ftrace_regs_get_return_value [ Upstream commit 2d17932da44fdc1ba835ad05110ab996d2912dbf ] Rename ftrace_regs_return_value to ftrace_regs_get_return_value as same as other ftrace_regs_get/set_* APIs. arm64 and riscv are already using this new name. Cc: Alexei Starovoitov Cc: Florent Revest Cc: Martin KaFai Lau Cc: bpf Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Alan Maguire Link: https://lore.kernel.org/172895573350.107311.7564634260652361511.stgit@devnote2 Acked-by: Mark Rutland Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit ff57dbe037be2603df6e5f63b01bd386598a4dd8 Author: Masami Hiramatsu (Google) Date: Tue Oct 15 10:28:43 2024 +0900 ftrace: Use arch_ftrace_regs() for ftrace_regs_*() macros [ Upstream commit 0b582611a8f4270fa357a22a546909b2dd5fc5fe ] Since the arch_ftrace_get_regs(fregs) is only valid when the FL_SAVE_REGS is set, we need to use `&arch_ftrace_regs()->regs` for ftrace_regs_*() APIs because those APIs are for ftrace_regs, not complete pt_regs. Cc: Alexei Starovoitov Cc: Florent Revest Cc: Martin KaFai Lau Cc: bpf Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Alan Maguire Cc: Mark Rutland Link: https://lore.kernel.org/172895572290.107311.16057631001860177198.stgit@devnote2 Fixes: e4cf33ca4812 ("ftrace: Consolidate ftrace_regs accessor functions for archs using pt_regs") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit a701884d1398661aa6a8d0628a7410b301a7a2ff Author: Steven Rostedt Date: Thu Oct 10 20:21:14 2024 -0400 ftrace: Consolidate ftrace_regs accessor functions for archs using pt_regs [ Upstream commit e4cf33ca48128d580e25ebe779b7ba7b4b4cf733 ] Most architectures use pt_regs within ftrace_regs making a lot of the accessor functions just calls to the pt_regs internally. Instead of duplication this effort, use a HAVE_ARCH_FTRACE_REGS for architectures that have their own ftrace_regs that is not based on pt_regs and will define all the accessor functions, and for the architectures that just use pt_regs, it will leave it undefined, and the default accessor functions will be used. Note, this will also make it easier to add new accessor functions to ftrace_regs as it will mean having to touch less architectures. Cc: Cc: "x86@kernel.org" Cc: Mathieu Desnoyers Cc: Mark Rutland Cc: Will Deacon Cc: Huacai Chen Cc: WANG Xuerui Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Naveen N Rao Cc: Madhavan Srinivasan Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Link: https://lore.kernel.org/20241010202114.2289f6fd@gandalf.local.home Acked-by: Masami Hiramatsu (Google) Acked-by: Heiko Carstens # s390 Acked-by: Catalin Marinas Acked-by: Michael Ellerman # powerpc Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit 550a16d87d33b61d18a9f66de57d2ccba3256bb3 Author: Steven Rostedt Date: Tue Oct 8 19:05:28 2024 -0400 ftrace: Make ftrace_regs abstract from direct use [ Upstream commit 7888af4166d4ab07ba51234be6ba332b7807e901 ] ftrace_regs was created to hold registers that store information to save function parameters, return value and stack. Since it is a subset of pt_regs, it should only be used by its accessor functions. But because pt_regs can easily be taken from ftrace_regs (on most archs), it is tempting to use it directly. But when running on other architectures, it may fail to build or worse, build but crash the kernel! Instead, make struct ftrace_regs an empty structure and have the architectures define __arch_ftrace_regs and all the accessor functions will typecast to it to get to the actual fields. This will help avoid usage of ftrace_regs directly. Link: https://lore.kernel.org/all/20241007171027.629bdafd@gandalf.local.home/ Cc: "linux-arch@vger.kernel.org" Cc: "x86@kernel.org" Cc: Mathieu Desnoyers Cc: Mark Rutland Cc: Will Deacon Cc: Huacai Chen Cc: WANG Xuerui Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Naveen N Rao Cc: Madhavan Srinivasan Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Link: https://lore.kernel.org/20241008230628.958778821@goodmis.org Acked-by: Catalin Marinas Signed-off-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) Acked-by: Heiko Carstens # s390 Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit ef3166bd8d33e6faa19ab93d118efad7f5fcc72a Author: Masami Hiramatsu (Google) Date: Sun Aug 18 21:48:13 2024 +0900 tracing: Add a comment about ftrace_regs definition [ Upstream commit a370b72ec7165ebe1230d0225cbe66f6526e68ef ] To clarify what will be expected on ftrace_regs, add a comment to the architecture independent definition of the ftrace_regs. Signed-off-by: Masami Hiramatsu (Google) Acked-by: Mark Rutland Signed-off-by: Steven Rostedt (Google) Stable-dep-of: aea251799998 ("x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path") Signed-off-by: Sasha Levin commit c2681ce178a26100ceea94dc8dad5501f90d63a8 Author: Jiayuan Chen Date: Sat Jan 24 19:32:44 2026 +0800 bpf, sockmap: Fix FIONREAD for sockmap [ Upstream commit 929e30f9312514902133c45e51c79088421ab084 ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. Therefore, for sockmap, relying solely on copied_seq and rcv_nxt to calculate FIONREAD is not enough. This patch adds a new msg_tot_len field in the psock structure to record the data length in ingress_msg. Additionally, we implement new ioctl interfaces for TCP and UDP to intercept FIONREAD operations. Note that we intentionally do not include sk_receive_queue data in the FIONREAD result. Data in sk_receive_queue has not yet been processed by the BPF verdict program, and may be redirected to other sockets or dropped. Including it would create semantic ambiguity since this data may never be readable by the user. Unix and VSOCK sockets have similar issues, but fixing them is outside the scope of this patch as it would require more intrusive changes. Previous work by John Fastabend made some efforts towards FIONREAD support: commit e5c6de5fa025 ("bpf, sockmap: Incorrectly handling copied_seq") Although the current patch is based on the previous work by John Fastabend, it is acceptable for our Fixes tag to point to the same commit. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: Jiayuan Chen Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/r/20260124113314.113584-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4f9f0cbb4b27d19f247fd386f69670b66db1f712 Author: Jiayuan Chen Date: Sat Jan 24 19:32:43 2026 +0800 bpf, sockmap: Fix incorrect copied_seq calculation [ Upstream commit b40cc5adaa80e1471095a62d78233b611d7a558c ] A socket using sockmap has its own independent receive queue: ingress_msg. This queue may contain data from its own protocol stack or from other sockets. The issue is that when reading from ingress_msg, we update tp->copied_seq by default. However, if the data is not from its own protocol stack, tcp->rcv_nxt is not increased. Later, if we convert this socket to a native socket, reading from this socket may fail because copied_seq might be significantly larger than rcv_nxt. This fix also addresses the syzkaller-reported bug referenced in the Closes tag. This patch marks the skmsg objects in ingress_msg. When reading, we update copied_seq only if the data is from its own protocol stack. FD1:read() -- FD1->copied_seq++ | [read data] | [enqueue data] v [sockmap] -> ingress to self -> ingress_msg queue FD1 native stack ------> ^ -- FD1->rcv_nxt++ -> redirect to other | [enqueue data] | | | ingress to FD1 v ^ ... | [sockmap] FD2 native stack Closes: https://syzkaller.appspot.com/bug?extid=06dbd397158ec0ea4983 Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Reviewed-by: Jakub Sitnicki Reviewed-by: John Fastabend Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260124113314.113584-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 57cd88f4b6095b92c020de2ac7dc3fcb249549a1 Author: Tycho Andersen (AMD) Date: Mon Jan 5 10:22:18 2026 -0700 crypto: ccp - narrow scope of snp_range_list [ Upstream commit dc8ccab15081efc4f2c5a9fc7b209cd641d29177 ] snp_range_list is only used in __sev_snp_init_locked() in the SNP_INIT_EX case, move the declaration there and add a __free() cleanup helper for it instead of waiting until shutdown. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Reviewed-by: Alexey Kardashevskiy Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1c3506ea8599a3ad1b9aae5cbd573134f8d18db7 Author: Ashish Kalra Date: Mon Mar 24 21:14:32 2025 +0000 crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls [ Upstream commit ceac7fb89e8da465aec3ac3c20477f912f5c3a6c ] Modify the behavior of implicit SEV initialization in some of the SEV ioctls to do both SEV initialization and shutdown and add implicit SNP initialization and shutdown to some of the SNP ioctls so that the change of SEV/SNP platform initialization not being done during PSP driver probe time does not break userspace tools such as sevtool, etc. Prior to this patch, SEV has always been initialized before these ioctls as SEV initialization is done as part of PSP module probe, but now with SEV initialization being moved to KVM module load instead of PSP driver probe, the implied SEV INIT actually makes sense and gets used and additionally to maintain SEV platform state consistency before and after the ioctl SEV shutdown needs to be done after the firmware call. It is important to do SEV Shutdown here with the SEV/SNP initialization moving to KVM, an implicit SEV INIT here as part of the SEV ioctls not followed with SEV Shutdown will cause SEV to remain in INIT state and then a future SNP INIT in KVM module load will fail. Also ensure that for these SEV ioctls both implicit SNP and SEV INIT is done followed by both SEV and SNP shutdown as RMP table must be initialized before calling SEV INIT if SNP host support is enabled. Similarly, prior to this patch, SNP has always been initialized before these ioctls as SNP initialization is done as part of PSP module probe, therefore, to keep a consistent behavior, SNP init needs to be done here implicitly as part of these ioctls followed with SNP shutdown before returning from the ioctl to maintain the consistent platform state before and after the ioctl. Suggested-by: Tom Lendacky Reviewed-by: Tom Lendacky Signed-off-by: Ashish Kalra Signed-off-by: Herbert Xu Stable-dep-of: dc8ccab15081 ("crypto: ccp - narrow scope of snp_range_list") Signed-off-by: Sasha Levin commit cf8a8f13deb03f435d483eea8585ad35b6bb6f7e Author: Thomas Gleixner Date: Mon Jan 19 11:38:34 2026 +0100 hrtimer: Fix trace oddity [ Upstream commit 5d6446f409da00e5a389125ddb5ce09f5bc404c9 ] It turns out that __run_hrtimer() will trace like: -0 [032] d.h2. 20705.474563: hrtimer_cancel: hrtimer=0xff2db8f77f8226e8 -0 [032] d.h1. 20705.474563: hrtimer_expire_entry: hrtimer=0xff2db8f77f8226e8 now=20699452001850 function=tick_nohz_handler/0x0 Which is a bit nonsensical, the timer doesn't get canceled on expiration. The cause is the use of the incorrect debug helper. Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Reported-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260121143208.219595606@infradead.org Signed-off-by: Sasha Levin commit 0f893b33e6a7e91e90fb84cd7738b7c800e071f5 Author: Kery Qi Date: Wed Jan 21 17:41:16 2026 +0800 selftests/bpf: Fix resource leak in serial_test_wq on attach failure [ Upstream commit a32ae2658471dd87a2f7a438388ed7d9a5767212 ] When wq__attach() fails, serial_test_wq() returns early without calling wq__destroy(), leaking the skeleton resources allocated by wq__open_and_load(). This causes ASAN leak reports in selftests runs. Fix this by jumping to a common clean_up label that calls wq__destroy() on all exit paths after successful open_and_load. Note that the early return after wq__open_and_load() failure is correct and doesn't need fixing, since that function returns NULL on failure (after internally cleaning up any partial allocations). Fixes: 8290dba51910 ("selftests/bpf: wq: add bpf_wq_start() checks") Signed-off-by: Kery Qi Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20260121094114.1801-3-qikeyu2017@gmail.com Signed-off-by: Sasha Levin commit 58059335e46537de682db84984f7716c813208c4 Author: Puranjay Mohan Date: Thu Jan 15 07:11:40 2026 -0800 bpf: Preserve id of register in sync_linked_regs() [ Upstream commit af9e89d8dd39530c8bd14c33ddf6b502df1071b6 ] sync_linked_regs() copies the id of known_reg to reg when propagating bounds of known_reg to reg using the off of known_reg, but when known_reg was linked to reg like: known_reg = reg ; both known_reg and reg get same id known_reg += 4 ; known_reg gets off = 4, and its id gets BPF_ADD_CONST now when a call to sync_linked_regs() happens, let's say with the following: if known_reg >= 10 goto pc+2 known_reg's new bounds are propagated to reg but now reg gets BPF_ADD_CONST from the copy. This means if another link to reg is created like: another_reg = reg ; another_reg should get the id of reg but assign_scalar_id_before_mov() sees BPF_ADD_CONST on reg and assigns a new id to it. As reg has a new id now, known_reg's link to reg is broken. If we find new bounds for known_reg, they will not be propagated to reg. This can be seen in the selftest added in the next commit: 0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPF_ADD_CONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken. After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero. Fix this by preserving id in sync_linked_regs() like off and subreg_def. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Signed-off-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260115151143.1344724-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0bbfa5542670ec1ec9720adbd938ccb684d729f7 Author: Qi Tao Date: Thu Dec 18 21:44:52 2025 +0800 crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware queue unavailable [ Upstream commit e7507439628052363500d717caffb5c2241854dc ] When all hardware queues are busy and no shareable queue, new processes fail to apply for queues. To avoid affecting tasks, support fallback mechanism when hardware queues are unavailable. Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD") Signed-off-by: Qi Tao Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 21ad2c1dcb185ffd8b514e2090de0d1cee6cebb2 Author: Chenghai Huang Date: Thu Dec 18 21:44:42 2025 +0800 crypto: hisilicon/zip - adjust the way to obtain the req in the callback function [ Upstream commit 19c2475ce1984cf675ebfbbeaa5509b2fb1887d6 ] In the shared queue design, multiple tfms use same qp, and one qp need to corresponds to multiple qp_ctx. So use tag to obtain the req virtual address. Build a one-to-one relationship between tfm and qp_ctx. finaly remove the old get_tag operation. Fixes: 2bcf36348ce5 ("crypto: hisilicon/zip - initialize operations about 'sqe' in 'acomp_alg.init'") Signed-off-by: Chenghai Huang Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce2e7e471da0940b57ccbcba90d4a48390c5340c Author: Thomas Fourier Date: Thu Dec 18 11:12:57 2025 +0100 crypto: octeontx - fix dma_free_coherent() size [ Upstream commit 624a6760bf8464965c17c8df10b40b557eaa3002 ] The size of the buffer in alloc_command_queues() is curr->size + OTX_CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dc8af9baf7643a5668162a635f37289c231e590c Author: Thomas Fourier Date: Thu Dec 18 10:56:45 2025 +0100 crypto: cavium - fix dma_free_coherent() size [ Upstream commit 941676c30ba5b40a01bed92448f457ce62fd1f07 ] The size of the buffer in alloc_command_queues() is curr->size + CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4e39e4d847b0c771db1c2e5780f77d349d2f419d Author: Thomas Weißschuh Date: Tue Dec 23 07:59:17 2025 +0100 ARM: VDSO: Patch out __vdso_clock_getres() if unavailable [ Upstream commit b9fecf0dddfc55cd7d02b0011494da3c613f7cde ] The vDSO code hides symbols which are non-functional. __vdso_clock_getres() was not added to this list when it got introduced. Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de Signed-off-by: Sasha Levin commit 5731312c4cb54f031007d90f0a6afd58b8642455 Author: Varun R Mallya Date: Wed Jan 7 05:05:27 2026 +0530 libbpf: Fix OOB read in btf_dump_get_bitfield_value [ Upstream commit 5714ca8cba5ed736f3733663c446cbee63a10a64 ] When dumping bitfield data, btf_dump_get_bitfield_value() reads data based on the underlying type's size (t->size). However, it does not verify that the provided data buffer (data_sz) is large enough to contain these bytes. If btf_dump__dump_type_data() is called with a buffer smaller than the type's size, this leads to an out-of-bounds read. This was confirmed by AddressSanitizer in the linked issue. Fix this by ensuring we do not read past the provided data_sz limit. Fixes: a1d3cc3c5eca ("libbpf: Avoid use of __int128 in typed dump display") Reported-by: Harrison Green Suggested-by: Alan Maguire Signed-off-by: Varun R Mallya Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260106233527.163487-1-varunrmallya@gmail.com Closes: https://github.com/libbpf/libbpf/issues/928 Signed-off-by: Sasha Levin commit 5478540eafbec407cc96ba5be143f63714ae5ea7 Author: Puranjay Mohan Date: Wed Dec 31 14:10:50 2025 -0800 selftests/bpf: veristat: fix printing order in output_stats() [ Upstream commit c286e7e9d1f1f3d90ad11c37e896f582b02d19c4 ] The order of the variables in the printf() doesn't match the text and therefore veristat prints something like this: Done. Processed 24 files, 0 programs. Skipped 62 files, 0 programs. When it should print: Done. Processed 24 files, 62 programs. Skipped 0 files, 0 programs. Fix the order of variables in the printf() call. Fixes: 518fee8bfaf2 ("selftests/bpf: make veristat skip non-BPF and failing-to-open BPF objects") Tested-by: Eduard Zingerman Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20251231221052.759396-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 138fc0ee903454aa2e0741af3a8f69b86555b343 Author: Giovanni Cabiddu Date: Thu Nov 20 16:30:46 2025 +0000 crypto: qat - fix warning on adf_pfvf_pf_proto.c [ Upstream commit 994689b8f91b02fdb5f64cba2412cde5ef3084b5 ] Building the QAT driver with -Wmaybe-uninitialized triggers warnings in qat_common/adf_pfvf_pf_proto.c. Specifically, the variables blk_type, blk_byte, and byte_max may be used uninitialized in handle_blkmsg_req(): make M=drivers/crypto/intel/qat W=1 C=2 "KCFLAGS=-Werror" \ KBUILD_CFLAGS_KERNEL=-Wmaybe-uninitialized \ CFLAGS_MODULE=-Wmaybe-uninitialized ... warning: ‘byte_max’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_type’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_byte’ may be used uninitialized [-Wmaybe-uninitialized] Although the caller of handle_blkmsg_req() always provides a req.type that is handled by the switch, the compiler cannot guarantee this. Add a default case to the switch statement to handle an invalid req.type. Fixes: 673184a2a58f ("crypto: qat - introduce support for PFVF block messages") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9faf20a1819b127926eadba095d2cc7a776ca855 Author: Sandipan Das Date: Fri Dec 5 16:16:46 2025 -0800 perf/x86/core: Do not set bit width for unavailable counters [ Upstream commit b456a6ba5756b6fb7e651775343e713bd08418e7 ] Not all x86 processors have fixed counters. It may also be the case that a processor has only fixed counters and no general-purpose counters. Set the bit widths corresponding to each counter type only if such counters are available. Fixes: b3d9468a8bd2 ("perf, x86: Expose perf capability to other modules") Signed-off-by: Sandipan Das Co-developed-by: Dapeng Mi Signed-off-by: Dapeng Mi Signed-off-by: Mingwei Zhang Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Tested-by: Xudong Hao Link: https://patch.msgid.link/20251206001720.468579-11-seanjc@google.com Signed-off-by: Sasha Levin commit f96c5ccf95ae5f27218c1ce2d6a3ad2d3e105424 Author: Salah Triki Date: Fri Jan 30 21:47:59 2026 +0100 s390/cio: Fix device lifecycle handling in css_alloc_subchannel() [ Upstream commit f65c75b0b9b5a390bc3beadcde0a6fbc3ad118f7 ] `css_alloc_subchannel()` calls `device_initialize()` before setting up the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails, the error path frees the subchannel structure directly, bypassing the device model reference counting. Once `device_initialize()` has been called, the embedded struct device must be released via `put_device()`, allowing the release callback to free the container structure. Fix the error path by dropping the initial device reference with `put_device()` instead of calling `kfree()` directly. This ensures correct device lifetime handling and avoids potential use-after-free or double-free issues. Fixes: e5dcf0025d7af ("s390/css: move subchannel lock allocation") Signed-off-by: Salah Triki Reviewed-by: Vineeth Vijayan Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 06b3e765fdc598bb833378b31ecef7f883ff83c9 Author: Gui-Dong Han Date: Tue Feb 3 11:19:43 2026 +0800 PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races [ Upstream commit 5c9ecd8e6437cd55a38ea4f1e1d19cee8e226cb8 ] dev_pm_clear_wake_irq() currently uses a dangerous pattern where dev->power.wakeirq is read and checked for NULL outside the lock. If two callers invoke this function concurrently, both might see a valid pointer and proceed. This could result in a double-free when the second caller acquires the lock and tries to release the same object. Address this by removing the lockless check of dev->power.wakeirq. Instead, acquire dev->power.lock immediately to ensure the check and the subsequent operations are atomic. If dev->power.wakeirq is NULL under the lock, simply unlock and return. This guarantees that concurrent calls cannot race to free the same object. Based on a quick scan of current users, I did not find an actual bug as drivers seem to rely on their own synchronization. However, since asynchronous usage patterns exist (e.g., in drivers/net/wireless/ti/wlcore), I believe a race is theoretically possible if the API is used less carefully in the future. This change hardens the API to be robust against such cases. Fixes: 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260203031943.1924-1-hanguidong02@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 73caf86fe92ef53518a341e0925b7fb2a40f4986 Author: Yaxiong Tian Date: Tue Feb 3 10:48:52 2026 +0800 cpufreq: intel_pstate: Enable asym capacity only when CPU SMT is not possible [ Upstream commit 1fedbb589448bee9f20bb2ed9c850d1d2cf9963c ] According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 26bec96bc5f318d1134e482eab53a968b5ce0fac Author: Leo Yan Date: Tue Feb 3 14:40:43 2026 +0000 perf: arm_spe: Properly set hw.state on failures [ Upstream commit 283182c1c239f6873d1a50e9e710c1a699f2256b ] When arm_spe_pmu_next_off() fails to calculate a valid limit, it returns zero to indicate that tracing should not start. However, the caller arm_spe_perf_aux_output_begin() does not propagate this failure by updating hwc->state, cause the error to be silently ignored by upper layers. Because hwc->state remains zero after a failure, arm_spe_pmu_start() continues to programs filter registers unnecessarily. The driver still reports success to the perf core, so the core assumes the SPE event was enabled and proceeds to enable other events. This breaks event group semantics: SPE is already stopped while other events in the same group are enabled. Fix this by updating arm_spe_perf_aux_output_begin() to return a status code indicating success (0) or failure (-EIO). Both the interrupt handler and arm_spe_pmu_start() check the return value and call arm_spe_pmu_stop() to set PERF_HES_STOPPED in hwc->state. In the interrupt handler, the period (e.g., period_left) needs to be updated, so PERF_EF_UPDATE is passed to arm_spe_pmu_stop(). When the error occurs during event start, the trace unit is not yet enabled, so a flag '0' is used to drain buffer and update state only. Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b909d420d6b865827ed7ee949db09415141ed1dd Author: Samuel Wu Date: Fri Jan 23 17:21:29 2026 -0800 PM: wakeup: Handle empty list in wakeup_sources_walk_start() [ Upstream commit 75ce02f4bc9a8b8350b6b1b01872467b0cc960cc ] In the case of an empty wakeup_sources list, wakeup_sources_walk_start() will return an invalid but non-NULL address. This also affects wrappers of the aforementioned function, like for_each_wakeup_source(). Update wakeup_sources_walk_start() to return NULL in case of an empty list. Fixes: b4941adb24c0 ("PM: wakeup: Add routine to help fetch wakeup source object.") Signed-off-by: Samuel Wu [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260124012133.2451708-2-wusamuel@google.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c94fd6e8a71efd047ff36930e840f3c25679e136 Author: Zilin Guan Date: Mon Jan 26 07:15:33 2026 +0000 md/raid1: fix memory leak in raid1_run() [ Upstream commit 6abc7d5dcf0ee0f85e16e41c87fbd06231f28753 ] raid1_run() calls setup_conf() which registers a thread via md_register_thread(). If raid1_set_limits() fails, the previously registered thread is not unregistered, resulting in a memory leak of the md_thread structure and the thread resource itself. Add md_unregister_thread() to the error path to properly cleanup the thread, which aligns with the error handling logic of other paths in this function. Compile tested only. Issue found using a prototype static analysis tool and code review. Link: https://lore.kernel.org/linux-raid/20260126071533.606263-1-zilin@seu.edu.cn Fixes: 97894f7d3c29 ("md/raid1: use the atomic queue limit update APIs") Signed-off-by: Zilin Guan Reviewed-by: Li Nan Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit aaac92c72d6e200635212dd8a41b7d576f18b1ba Author: Zheng Qixing Date: Sat Feb 15 10:01:37 2025 +0800 md/raid1: fix memory leak in raid1_run() if no active rdev [ Upstream commit 5fbcf76e0dfe68578ffa2a8a691cc44cf586ae35 ] When `raid1_set_limits()` fails or when the array has no active `rdev`, the allocated memory for `conf` is not properly freed. Add raid1_free() call to properly free the conf in error path. Fixes: 799af947ed13 ("md/raid1: don't free conf on raid0_run failure") Signed-off-by: Zheng Qixing Link: https://lore.kernel.org/linux-raid/20250215020137.3703757-1-zhengqixing@huaweicloud.com Singed-off-by: Yu Kuai Stable-dep-of: 6abc7d5dcf0e ("md/raid1: fix memory leak in raid1_run()") Signed-off-by: Sasha Levin commit db8c4b15deab87392f5834aa9c804f860d513300 Author: Roger Pau Monne Date: Wed Jan 28 12:05:08 2026 +0100 Partial revert "x86/xen: fix balloon target initialization for PVH dom0" [ Upstream commit 0949c646d64697428ff6257d52efa5093566868d ] This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory despite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. However if switching to start_info->nr_pages for PV domains we need to differentiate between released pages (freed back to the hypervisor) as opposed to pages in the physmap which are not populated to start with. Introduce a new xen_unpopulated_pages to account for papges that have never been populated, and hence in the PV case don't need subtracting. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Reported-by: James Dingwall Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260128110510.46425-2-roger.pau@citrix.com> Signed-off-by: Sasha Levin commit dbe8e81a2ec608f87f79a34f6444cd62f6a243bb Author: Govindarajulu Varadarajan Date: Fri Jan 30 10:14:12 2026 -0700 ublk: Validate SQE128 flag before accessing the cmd [ Upstream commit da7e4b75e50c087d2031a92f6646eb90f7045a67 ] ublk_ctrl_cmd_dump() accesses (header *)sqe->cmd before IO_URING_F_SQE128 flag check. This could cause out of boundary memory access. Move the SQE128 flag check earlier in ublk_ctrl_uring_cmd() to return -EINVAL immediately if the flag is not set. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Govindarajulu Varadarajan Reviewed-by: Caleb Sander Mateos Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8af710156c53cdb392d529497ef2b3a10a1f9370 Author: Felix Gu Date: Sat Jan 24 03:06:40 2026 +0800 thermal/of: Fix reference leak in thermal_of_cm_lookup() [ Upstream commit a1fe789a96fe47733c133134fd264cb7ca832395 ] In thermal_of_cm_lookup(), tr_np is obtained via of_parse_phandle(), but never released. Use the __free(device_node) cleanup attribute to automatically release the node and fix the leak. Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Signed-off-by: Felix Gu Reviewed-by: Lukasz Luba [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260124-thermal_of-v1-1-54d3416948cf@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 87283ce6218b199793296ec7dbe9939c7e381d1d Author: Christoph Hellwig Date: Mon Jan 26 06:53:38 2026 +0100 iomap: fix submission side handling of completion side errors [ Upstream commit 4ad357e39b2ecd5da7bcc7e840ee24d179593cd5 ] The "if (dio->error)" in iomap_dio_bio_iter exists to stop submitting more bios when a completion already return an error. Commit cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") made it revert the iov by "copied", which is very wrong given that we've already consumed that range and submitted a bio for it. Fixes: cfe057f7db1f ("iomap_dio_actor(): fix iov_iter bugs") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Darrick J. Wong Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 10bb2f5d365de512062c59bd03bb7eca1e47bba8 Author: Felix Gu Date: Wed Jan 21 23:32:06 2026 +0800 cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id() [ Upstream commit 0b7fbf9333fa4699a53145bad8ce74ea986caa13 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In scmi_cpu_domain_id(), it does not release the reference. Fixes: e336baa4193e ("cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq") Signed-off-by: Felix Gu Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b114bc9f075c7f81c13a4b1a70d4bd6c459a686e Author: Aleks Todorov Date: Fri Jan 23 14:03:44 2026 +0000 OPP: Return correct value in dev_pm_opp_get_level [ Upstream commit 0b7277e02dabba2a9921a7f4761ae6e627e7297a ] Commit 073d3d2ca7d4 ("OPP: Level zero is valid") modified the documentation for this function to indicate that errors should return a non-zero value to avoid colliding with the OPP level zero, however forgot to actually update the return. No in-tree kernel code depends on the error value being 0. Fixes: 073d3d2ca7d4 ("OPP: Level zero is valid") Signed-off-by: Aleks Todorov Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 9a205d16e88bcd9c88492a254612e0cc8e8daf81 Author: Li Nan Date: Mon Jan 5 19:02:58 2026 +0800 md/raid10: fix any_working flag handling in raid10_sync_request [ Upstream commit 99582edb3f62e8ee6c34512021368f53f9b091f2 ] In raid10_sync_request(), 'any_working' indicates if any IO will be submitted. When there's only one In_sync disk with badblocks, 'any_working' might be set to 1 but no IO is submitted. Fix it by setting 'any_working' after badblock checks. Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-11-linan666@huaweicloud.com Fixes: e875ecea266a ("md/raid10 record bad blocks as needed during recovery.") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit fcb54ef1dbfcf6fd1f2769e61beba8588d0903a4 Author: Yu Kuai Date: Thu Jan 15 01:12:29 2026 +0800 md/raid5: fix raid5_run() to return error when log_init() fails [ Upstream commit 2d9f7150ac197ce79c9c917a004d4cf0b26ad7e0 ] Since commit f63f17350e53 ("md/raid5: use the atomic queue limit update APIs"), the abort path in raid5_run() returns 'ret' instead of -EIO. However, if log_init() fails, 'ret' is still 0 from the previous successful call, causing raid5_run() to return success despite the failure. Fix this by capturing the return value from log_init(). Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-2-yukuai@fnnas.com Fixes: f63f17350e53 ("md/raid5: use the atomic queue limit update APIs") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601130531.LGfcZsa4-lkp@intel.com/ Signed-off-by: Yu Kuai Reviewed-by: Li Nan Reviewed-by: Xiao Ni Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 3c08d86d0c8e74f1e024fac8a1681eaa17690ca3 Author: Rafael J. Wysocki Date: Tue Jan 20 16:23:41 2026 +0100 thermal: intel: x86_pkg_temp_thermal: Handle invalid temperature [ Upstream commit 9635c586a559ba0e45b2bfbff79c937ddbaf1a62 ] After commit be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates"), THERMAL_TEMP_INVALID can be passed to sys_set_trip_temp() and it is treated as a regular temperature value there, so the sysfs write fails even though it is expected to succeed and disable the given trip point. Address this by making sys_set_trip_temp() clear its temp variable when it is equal to THERMAL_TEMP_INVALID. Fixes: be0a3600aa1e ("thermal: sysfs: Rework the handling of trip point updates") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2815400.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Sasha Levin commit 101cc8e5506aa72225121f184e5fb5e860f0b339 Author: Rafael J. Wysocki Date: Tue Jan 20 16:26:14 2026 +0100 cpuidle: governors: menu: Always check timers with tick stopped [ Upstream commit 80606f4eb8d7484ab7f7d6f0fd30d71e6fbcf328 ] After commit 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases"), if the return value of get_typical_interval() multiplied by NSEC_PER_USEC is not greater than RESIDENCY_THRESHOLD_NS, the menu governor will skip computing the time till the closest timer. If that happens when the tick has been stopped already, the selected idle state may be too deep due to the subsequent check comparing predicted_ns with TICK_NSEC and causing its value to be replaced with the expected time till the closest timer, which is KTIME_MAX in that case. That will cause the deepest enabled idle state to be selected, but the time till the closest timer very well may be shorter than the target residency of that state, in which case a shallower state should be used. Address this by making menu_select() always compute the time till the closest timer when the tick has been stopped. Also move the predicted_ns check mentioned above into the branch in which the time till the closest timer is determined because it only needs to be done in that case. Fixes: 5484e31bbbff ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases") Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/5959091.DvuYhMxLoT@rafael.j.wysocki Signed-off-by: Sasha Levin commit c812673deb811ca756c590115bf94efd0a6d9b9c Author: Jens Axboe Date: Wed Jan 21 11:48:56 2026 -0700 io_uring/sync: validate passed in offset [ Upstream commit 649dd18f559891bdafc5532d737c7dfb56060a6d ] Check if the passed in offset is negative once cast to sync->off. This ensures that -EINVAL is returned for that case, like it would be for sync_file_range(2). Fixes: c992fe2925d7 ("io_uring: add fsync support") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cce354524da4d10fd2c7eb835e2e4e8ab8c0ce97 Author: Alexey Simakov Date: Wed Jan 14 13:20:17 2026 +0100 ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch() [ Upstream commit f851e03bce968ff9b3faad1b616062e1244fd38d ] Cover a missed execution path with a new check. Fixes: 0acf24ad7e10 ("ACPICA: Add support for PCC Opregion special context data") Link: https://github.com/acpica/acpica/commit/f421dd9dd897 Signed-off-by: Alexey Simakov Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3030574.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Sasha Levin commit a67a23e9dedffb6b77335dc12d03d4a39a66024a Author: Caleb Sander Mateos Date: Mon Jan 5 14:05:40 2026 -0700 io_uring: use release-acquire ordering for IORING_SETUP_R_DISABLED [ Upstream commit 7a8737e1132ff07ca225aa7a4008f87319b5b1ca ] io_uring_enter(), __io_msg_ring_data(), and io_msg_send_fd() read ctx->flags and ctx->submitter_task without holding the ctx's uring_lock. This means they may race with the assignment to ctx->submitter_task and the clearing of IORING_SETUP_R_DISABLED from ctx->flags in io_register_enable_rings(). Ensure the correct ordering of the ctx->flags and ctx->submitter_task memory accesses by storing to ctx->flags using release ordering and loading it using acquire ordering. Signed-off-by: Caleb Sander Mateos Fixes: 4add705e4eeb ("io_uring: remove io_register_submitter") Reviewed-by: Joanne Koong Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit becedc3aceca9e4c155b2c7f8df741ab4896fd56 Author: Teddy Astie Date: Tue Jan 6 17:36:50 2026 +0000 xen/virtio: Don't use grant-dma-ops when running as Dom0 [ Upstream commit dc8ea8714311e549ee93a2b0bdd5487d20bfadbf ] Dom0 inherit devices from the machine and is usually in PV mode. If we are running in a virtual that has virtio devices, these devices would be considered as using grants with Dom0 as backend, while being the said Dom0 itself, while we want to use these devices like regular PCI devices. Fix this by preventing grant-dma-ops from being used when running as Dom0 (initial domain). We still keep the device-tree logic as-is. Signed-off-by: Teddy Astie Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> Signed-off-by: Sasha Levin commit 4dd5c62c201cb438167ec10504c1c0a33bfe0eeb Author: Florian-Ewald Mueller Date: Fri Dec 5 13:47:32 2025 +0100 rnbd-srv: Fix server side setting of bi_size for special IOs [ Upstream commit 4ac9690d4b9456ca1d5276d86547fa2e7cd47684 ] On rnbd-srv, the bi_size of the bio is set during the bio_add_page function, to which datalen is passed. But for special IOs like DISCARD and WRITE_ZEROES, datalen is 0, since there is no data to write. For these special IOs, use the bi_size of the rnbd_msg_io. Fixes: f6f84be089c9 ("block/rnbd-srv: Add sanity check and remove redundant assignment") Signed-off-by: Florian-Ewald Mueller Signed-off-by: Md Haris Iqbal Signed-off-by: Grzegorz Prajsner Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5afd2f4e1608c5d9a33c06dc627f34531d67e44b Author: Christoph Hellwig Date: Wed May 7 14:04:33 2025 +0200 rnbd-srv: use bio_add_virt_nofail [ Upstream commit a216081323a1391991c9073fed2459265bfc7f5c ] Use the bio_add_virt_nofail to add a single kernel virtual address to a bio as that can't fail. Signed-off-by: Christoph Hellwig Acked-by: Jack Wang Reviewed-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20250507120451.4000627-10-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 4ac9690d4b94 ("rnbd-srv: Fix server side setting of bi_size for special IOs") Signed-off-by: Sasha Levin commit cef2315cb84ebcb9b9fb2873e72c7a784a497079 Author: Christoph Hellwig Date: Wed May 7 14:04:25 2025 +0200 block: add a bio_add_virt_nofail helper [ Upstream commit 850e210d5ad21b94b55b97d4d82b4cdeb0bb05df ] Add a helper to add a directly mapped kernel virtual address to a bio so that callers don't have to convert to pages or folios. For now only the _nofail variant is provided as that is what all the obvious callers want. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20250507120451.4000627-2-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 4ac9690d4b94 ("rnbd-srv: Fix server side setting of bi_size for special IOs") Signed-off-by: Sasha Levin commit 4d339b219004869e96c4ce56b8891f83a38da4c0 Author: Paulo Alcantara Date: Thu Feb 5 13:19:52 2026 -0300 smb: client: fix potential UAF and double free in smb2_open_file() [ Upstream commit ebbbc4bfad4cb355d17c671223d0814ee3ef4eda ] Zero out @err_iov and @err_buftype before retrying SMB2_open() to prevent an UAF bug if @data != NULL, otherwise a double free. Fixes: e3a43633023e ("smb/client: fix memory leak in smb2_open_file()") Reported-by: David Howells Closes: https://lore.kernel.org/r/2892312.1770306653@warthog.procyon.org.uk Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Reviewed-by: ChenXiaoSong Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4eb830847d84276f1c8ea46541cfeeedaba1fb63 Author: Boris Burkov Date: Mon Dec 22 16:15:44 2025 -0800 btrfs: fix block_group_tree dirty_list corruption [ Upstream commit 3a1f4264daed4b419c325a7fe35e756cada3cf82 ] When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the block group tree to the switch_commits list before calling switch_commit_roots, as we do for the tree root and the chunk root. However, the block group tree uses normal root dirty tracking and in any transaction that does an allocation and dirties a block group, the block group root will already be linked to a list by the dirty_list field and this use of list_add_tail() is invalid and corrupts the prev/next members of block_group_root->dirty_list. This is apparent on a subsequent list_del on the prev if we enable CONFIG_DEBUG_LIST: [32.1571] ------------[ cut here ]------------ [32.1572] list_del corruption. next->prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538) [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607 [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none) [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014 [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120 [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202 [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538 [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00 [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538 [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538 [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000 [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0 [32.1609] Call Trace: [32.1610] [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs] [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs] [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [32.1621] __iterate_supers+0xe8/0x190 [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10 [32.1623] ksys_sync+0x63/0xb0 [32.1624] __do_sys_sync+0xe/0x20 [32.1625] do_syscall_64+0x73/0x450 [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e [32.1627] RIP: 0033:0x7f0c28d05d2b [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2 [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000 [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80 [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034 [32.1643] [32.1644] irq event stamp: 0 [32.1644] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260 [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260 [32.1650] softirqs last disabled at (0): [<0000000000000000>] 0x0 [32.1652] ---[ end trace 0000000000000000 ]--- Furthermore, this list corruption eventually (when we happen to add a new block group) results in getting the switch_commits and dirty_cowonly_roots lists mixed up and attempting to call update_root on the tree root which can't be found in the tree root, resulting in a transaction abort: [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1 [87.8272] ------------[ cut here ]------------ [87.8274] BTRFS: Transaction aborted (error -117) [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703 [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none) [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 04/01/2014 [87.8289] RIP: 0010:btrfs_update_root+0x296/0x790 [btrfs] [87.8295] RSP: 0018:ffffa58d035dfd60 EFLAGS: 00010282 [87.8297] RAX: ffff9a59126ddb68 RBX: ffff9a59126dc000 RCX: 0000000000000000 [87.8299] RDX: 0000000000000000 RSI: 00000000ffffff8b RDI: ffffffffc0b28270 [87.8301] RBP: ffff9a5904aec000 R08: 0000000000000000 R09: 00000000ffffefff [87.8303] R10: ffffffff9ac8c200 R11: ffffffff9ace4200 R12: 0000000000000001 [87.8305] R13: ffff9a59041740e8 R14: ffff9a5904aec1f7 R15: ffff9a590fdefaf0 [87.8307] FS: 00007f54cde6b740(0000) GS:ffff9a5b5a81c000(0000) knlGS:0000000000000000 [87.8309] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [87.8310] CR2: 00007f54cde403cc CR3: 0000000112902004 CR4: 0000000000370ef0 [87.8312] Call Trace: [87.8313] [87.8314] ? _raw_spin_unlock+0x23/0x40 [87.8315] commit_cowonly_roots+0x1ad/0x250 [btrfs] [87.8317] ? btrfs_commit_transaction+0x79b/0x1560 [btrfs] [87.8320] btrfs_commit_transaction+0x8aa/0x1560 [btrfs] [87.8322] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs] [87.8325] __iterate_supers+0xf1/0x170 [87.8326] ? __pfx_sync_fs_one_sb+0x10/0x10 [87.8327] ksys_sync+0x63/0xb0 [87.8328] __do_sys_sync+0xe/0x20 [87.8329] do_syscall_64+0x73/0x450 [87.8330] entry_SYSCALL_64_after_hwframe+0x76/0x7e [87.8331] RIP: 0033:0x7f54cdd05d2b [87.8336] RSP: 002b:00007fff1b58ff78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a2 [87.8338] RAX: ffffffffffffffda RBX: 00007fff1b590158 RCX: 00007f54cdd05d2b [87.8340] RDX: 00007f54cde02301 RSI: 00007fff1b592b66 RDI: 00007f54cddba90d [87.8342] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [87.8344] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e07ca96b80 [87.8346] R13: 000055e07ca9519f R14: 00007f54cddfa434 R15: 000055e07ca95034 [87.8348] [87.8348] irq event stamp: 0 [87.8349] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [87.8351] hardirqs last disabled at (0): [] copy_process+0xb37/0x21e0 [87.8353] softirqs last enabled at (0): [] copy_process+0xb37/0x21e0 [87.8355] softirqs last disabled at (0): [<0000000000000000>] 0x0 [87.8357] ---[ end trace 0000000000000000 ]--- [87.8358] BTRFS: error (device nvme1n1 state A) in btrfs_update_root:153: errno=-117 Filesystem corrupted [87.8360] BTRFS info (device nvme1n1 state EA): forced readonly [87.8362] BTRFS warning (device nvme1n1 state EA): Skipping commit of aborted transaction. [87.8364] BTRFS: error (device nvme1n1 state EA) in cleanup_transaction:2037: errno=-117 Filesystem corrupted Since the block group tree was pulled out of the extent tree and uses normal root dirty tracking, remove the offending extra list_add. This fixes the list corruption and the resulting fs corruption. Fixes: 14033b08a029 ("btrfs: don't save block group root into super block") Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit af30ffbdeb054bd0cb96d7417d397237d9483b21 Author: Filipe Manana Date: Tue Jan 20 19:35:23 2026 +0000 btrfs: qgroup: return correct error when deleting qgroup relation item [ Upstream commit 51b1fcf71c88c3c89e7dcf07869c5de837b1f428 ] If we fail to delete the second qgroup relation item, we end up returning success or -ENOENT in case the first item does not exist, instead of returning the error from the second item deletion. Fixes: 73798c465b66 ("btrfs: qgroup: Try our best to delete qgroup relations") Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8d582d65d20bb4796db01b19e86909ad68cb337b Author: Gao Xiang Date: Fri Jan 30 15:54:22 2026 +0800 erofs: handle end of filesystem properly for file-backed mounts [ Upstream commit bc804a8d7e865ef47fb7edcaf5e77d18bf444ebc ] I/O requests beyond the end of the filesystem should be zeroed out, similar to loopback devices and that is what we expect. Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 113eac582ccbbddc5fe915340d47f2787195ef20 Author: Gao Xiang Date: Thu Nov 27 16:07:56 2025 +0800 erofs: get rid of raw bi_end_io() usage [ Upstream commit 80d0c27a0a4af8e0678d7412781482e6f73c22c7 ] These BIOs are actually harmless in practice, as they are all pseudo BIOs and do not use advanced features like chaining. Using the BIO interface is a more friendly and unified approach for both bdev and and file-backed I/Os (compared to awkward bvec interfaces). Let's use bio_endio() instead. Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: bc804a8d7e86 ("erofs: handle end of filesystem properly for file-backed mounts") Signed-off-by: Sasha Levin commit cc09d55f519e15355de343264a22ac6682b8305e Author: Alper Ak Date: Fri Dec 26 15:09:27 2025 +0300 tpm: st33zp24: Fix missing cleanup on get_burstcount() error [ Upstream commit 3e91b44c93ad2871f89fc2a98c5e4fe6ca5db3d9 ] get_burstcount() can return -EBUSY on timeout. When this happens, st33zp24_send() returns directly without releasing the locality acquired earlier. Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)") Signed-off-by: Alper Ak Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit a61b8412e3eb8b71646dba867e8252d8560a1a27 Author: Alper Ak Date: Fri Dec 26 13:23:38 2025 +0300 tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure [ Upstream commit bbd6e97c836cbeb9606d7b7e5dcf8a1d89525713 ] get_burstcount() can return -EBUSY on timeout. When this happens, the function returns directly without releasing the locality that was acquired at the beginning of tpm_tis_i2c_send(). Use goto out_err to ensure proper cleanup when get_burstcount() fails. Fixes: aad628c1d91a ("char/tpm: Add new driver for Infineon I2C TIS TPM") Signed-off-by: Alper Ak Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 140a45bd4f6db7d1b30cab967d29689b946c52fa Author: Zilin Guan Date: Mon Jan 26 08:11:21 2026 +0000 i3c: dw: Fix memory leak in dw_i3c_master_i2c_xfers() [ Upstream commit 2537089413514caaa9a5fdeeac3a34d45100f747 ] The dw_i3c_master_i2c_xfers() function allocates memory for the xfer structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get() fails, the function returns without freeing the allocated xfer, resulting in a memory leak. Add a dw_i3c_master_free_xfer() call to the error path to ensure the allocated memory is properly freed. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Signed-off-by: Zilin Guan Reviewed-by: Frank Li Link: https://patch.msgid.link/20260126081121.644099-1-zilin@seu.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7ff9c410dd26fceb7c0613dbb13e2bbea8e6b31c Author: Fredrik Markstrom Date: Fri Jan 16 15:29:42 2026 +0100 i3c: dw: Initialize spinlock to avoid upsetting lockdep [ Upstream commit b58eaa4761ab02fc38c39d674a6bcdd55e00f388 ] The devs_lock spinlock introduced when adding support for ibi:s was never initialized. Fixes: e389b1d72a624 ("i3c: dw: Add support for in-band interrupts") Suggested-by: Jani Nurminen Signed-off-by: Fredrik Markstrom Reviewed-by: Ivar Holmqvist Link: https://patch.msgid.link/20260116-i3c_dw_initialize_spinlock-v3-1-cf707b6ed75f@est.tech Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 87d4954b5c59735a99ea98cb208d47130f6dce7d Author: Deepanshu Kartikey Date: Fri Jan 30 14:51:34 2026 +0530 gfs2: Fix use-after-free in iomap inline data write path [ Upstream commit faddeb848305e79db89ee0479bb0e33380656321 ] The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] Reported-by: syzbot+ea1cd4aa4d1e98458a55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ea1cd4aa4d1e98458a55 Fixes: d0a22a4b03b8 ("gfs2: Fix iomap write page reclaim deadlock") Signed-off-by: Deepanshu Kartikey Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ca7c67bdd293089b3483f18886d6b2d0037d2ad9 Author: Andreas Gruenbacher Date: Sun Dec 14 16:47:34 2025 +0000 gfs2: Fix slab-use-after-free in qd_put [ Upstream commit 22150a7d401d9e9169b9b68e05bed95f7f49bf69 ] Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey . Fixes: a475c5dd16e5 ("gfs2: Free quota data objects synchronously") Reported-by: syzbot+046b605f01802054bff0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=046b605f01802054bff0 Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ae4d9781ed0fed5b4f4f65dee8261ceabc18a56c Author: Andreas Gruenbacher Date: Tue Dec 9 22:59:12 2025 +0000 gfs2: Retries missing in gfs2_{rename,exchange} [ Upstream commit 11d763f0b0afc2cf5f92f4adae5dbbbbef712f8f ] Fix a bug in gfs2's asynchronous glock handling for rename and exchange operations. The original async implementation from commit ad26967b9afa ("gfs2: Use async glocks for rename") mentioned that retries were needed but never implemented them, causing operations to fail with -ESTALE instead of retrying on timeout. Also makes the waiting interruptible. In addition, the timeouts used were too high for situations in which timing out is a rare but expected scenario. Switch to shorter timeouts with randomization and exponentional backoff. Fixes: ad26967b9afa ("gfs2: Use async glocks for rename") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 1d8a994edffad48880d9f4bf1004b5bd267f537f Author: Adrian Hunter Date: Tue Jan 13 09:26:44 2026 +0200 i3c: master: Update hot-join flag only on success [ Upstream commit f0775157b9f9a28ae3eabc8d05b0bc52e8056c80 ] To prevent inconsistent state when an error occurs, ensure the hot-join flag is updated only when enabling or disabling hot-join succeeds. Fixes: 317bacf960a48 ("i3c: master: add enable(disable) hot join in sys entry") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7edd798f191e211991d42aef937a4397ce8a5b4c Author: Ben Dooks Date: Thu Jan 8 11:58:56 2026 +0000 fs: add for 'init_fs' [ Upstream commit 589cff4975afe1a4eaaa1d961652f50b1628d78d ] The init_fs symbol is defined in but was not included in fs/fs_struct.c so fix by adding the include. Fixes the following sparse warning: fs/fs_struct.c:150:18: warning: symbol 'init_fs' was not declared. Should it be static? Fixes: 3e93cd671813e ("Take fs_struct handling to new file") Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260108115856.238027-1-ben.dooks@codethink.co.uk Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 28050803c559c2b9247f0edb4dabc87deda387db Author: Billy Tsai Date: Mon Jan 12 14:07:22 2026 +0800 i3c: Move device name assignment after i3c_bus_init [ Upstream commit 3502cea99c7ceb331458cbd34ef6792c83144687 ] Move device name initialization to occur after i3c_bus_init() so that i3cbus->id is guaranteed to be assigned before it is used. Fixes: 9d4f219807d5 ("i3c: fix refcount inconsistency in i3c_master_register") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260112-upstream_i3c_fix-v1-1-cbbf2cb71809@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 01fd0ceb44e1983faf17ae8dccce99c92b968173 Author: Ben Dooks Date: Fri Jan 9 13:39:38 2026 +0000 audit: move the compat_xxx_class[] extern declarations to audit_arch.h [ Upstream commit 76489955c6d4a065ca69dc88faf7a50a59b66f35 ] The comapt_xxx_class symbols aren't declared in anything that lib/comapt_audit.c is including (arm64 build) which is causing the following sparse warnings: lib/compat_audit.c:7:10: warning: symbol 'compat_dir_class' was not declared. Should it be static? lib/compat_audit.c:12:10: warning: symbol 'compat_read_class' was not declared. Should it be static? lib/compat_audit.c:17:10: warning: symbol 'compat_write_class' was not declared. Should it be static? lib/compat_audit.c:22:10: warning: symbol 'compat_chattr_class' was not declared. Should it be static? lib/compat_audit.c:27:10: warning: symbol 'compat_signal_class' was not declared. Should it be static? Trying to fix this by chaning compat_audit.c to inclde does not work on arm64 due to compile errors with the extra includes that changing this header makes. The simpler thing would be just to move the definitons of these symbols out of into which is included. Fixes: 4b58841149dca ("audit: Add generic compat syscall support") Signed-off-by: Ben Dooks [PM: rewrite subject line, fixed line length in description] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 1f16679a5aa60238466ce339c35f5e82ece60337 Author: Yao Kai Date: Thu Jan 1 11:34:10 2026 -0500 rcu: Fix rcu_read_unlock() deadloop due to softirq [ Upstream commit d41e37f26b3157b3f1d10223863519a943aa239b ] Commit 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") removes the recursion-protection code from __rcu_read_unlock(). Therefore, we could invoke the deadloop in raise_softirq_irqoff() with ftrace enabled as follows: WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180 Modules linked in: my_irq_work(O) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180 RSP: 0018:ffffc900000034a8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329 RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4c R10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000 R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054 FS: 0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 unwind_next_frame+0x203/0x9b0 __unwind_start+0x15d/0x1c0 arch_stack_walk+0x62/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 raise_softirq_irqoff+0x6e/0xa0 rcu_read_unlock_special+0xb1/0x160 __is_insn_slot_addr+0x54/0x70 kernel_text_address+0x48/0xc0 __kernel_text_address+0xd/0x40 unwind_get_return_address+0x1e/0x40 arch_stack_walk+0x9c/0xf0 stack_trace_save+0x48/0x70 __ftrace_trace_stack.constprop.0+0x144/0x180 trace_buffer_unlock_commit_regs+0x6d/0x220 trace_event_buffer_commit+0x5c/0x260 trace_event_raw_event_softirq+0x47/0x80 __raise_softirq_irqoff+0x61/0x80 __flush_smp_call_function_queue+0x115/0x420 __sysvec_call_function_single+0x17/0xb0 sysvec_call_function_single+0x8c/0xc0 Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work") fixed the infinite loop in rcu_read_unlock_special() for IRQ work by setting a flag before calling irq_work_queue_on(). We fix this issue by setting the same flag before calling raise_softirq_irqoff() and rename the flag to defer_qs_pending for more common. Fixes: 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") Reported-by: Tengda Wu Signed-off-by: Yao Kai Reviewed-by: Joel Fernandes Tested-by: Paul E. McKenney Signed-off-by: Joel Fernandes Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 586a5effe50f2414a5c1337254dc337355ae202b Author: Zqiang Date: Wed Aug 13 21:30:02 2025 +0800 rcu: Remove local_irq_save/restore() in rcu_preempt_deferred_qs_handler() [ Upstream commit 42d590d100f2e47e47d974a902b9ed610e464824 ] The per-CPU rcu_data structure's ->defer_qs_iw field is initialized by IRQ_WORK_INIT_HARD(), which means that the subsequent invocation of rcu_preempt_deferred_qs_handler() will always be executed with interrupts disabled. This commit therefore removes the local_irq_save/restore() operations from rcu_preempt_deferred_qs_handler() and adds a call to lockdep_assert_irqs_disabled() in order to enable lockdep to diagnose mistaken invocations of this function from interrupts-enabled code. Signed-off-by: Zqiang Signed-off-by: Paul E. McKenney Stable-dep-of: d41e37f26b31 ("rcu: Fix rcu_read_unlock() deadloop due to softirq") Signed-off-by: Sasha Levin commit 24d44e0f05ab596cace53c980734a62e39a11a59 Author: Joel Fernandes Date: Tue Jul 15 16:01:52 2025 -0400 rcu: Refactor expedited handling check in rcu_read_unlock_special() [ Upstream commit 908a97eba8c8b510996bf5d77d1e3070d59caa6d ] Extract the complex expedited handling condition in rcu_read_unlock_special() into a separate function rcu_unlock_needs_exp_handling() with detailed comments explaining each condition. This improves code readability. No functional change intended. Reviewed-by: "Paul E. McKenney" Signed-off-by: Joel Fernandes Signed-off-by: Neeraj Upadhyay (AMD) Stable-dep-of: d41e37f26b31 ("rcu: Fix rcu_read_unlock() deadloop due to softirq") Signed-off-by: Sasha Levin commit 51838112d9c22502333c3085ca0c0d691e7093c6 Author: Shardul Bankar Date: Tue Dec 30 02:19:38 2025 +0530 hfsplus: return error when node already exists in hfs_bnode_create [ Upstream commit d8a73cc46c8462a969a7516131feb3096f4c49d3 ] When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values. Reported-by: syzbot+1c8ff72d0cd8a50dfeaa@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=1c8ff72d0cd8a50dfeaa Link: https://lore.kernel.org/all/784415834694f39902088fa8946850fc1779a318.camel@ibm.com/ Fixes: 634725a92938 ("[PATCH] hfs: cleanup HFS+ prints") Signed-off-by: Shardul Bankar Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20251229204938.1907089-1-shardul.b@mpiricsoftware.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 517813eb6e73cb02d8a5d348352df13c0abbf527 Author: Thomas Fourier Date: Tue Dec 16 18:47:13 2025 +0100 auxdisplay: arm-charlcd: fix release_mem_region() size [ Upstream commit b5c23a4d291d2ac1dfdd574a68a3a68c8da3069e ] It seems like, after the request_mem_region(), the corresponding release_mem_region() must take the same size. This was done in (now removed due to previous refactoring) charlcd_remove() but not in the error path in charlcd_probe(). Fixes: ce8962455e90 ("ARM: 6214/2: driver for the character LCD found in ARM refdesigns") Signed-off-by: Thomas Fourier Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 9c80d688f402539dfc8f336de1380d6b4ee14316 Author: YunJe Shin Date: Tue Feb 3 19:06:21 2026 +0900 RDMA/umad: Reject negative data_len in ib_umad_write commit 5551b02fdbfd85a325bb857f3a8f9c9f33397ed2 upstream. ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80 Fixes: 2be8e3ee8efd ("IB/umad: Add P_Key index support") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260203100628.1215408-1-ioerts@kookmin.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 87b7a036d2c73d5bb3ae2d47dee23de465db3355 Author: YunJe Shin Date: Wed Feb 4 18:24:57 2026 +0900 RDMA/siw: Fix potential NULL pointer dereference in header processing commit 14ab3da122bd18920ad57428f6cf4fade8385142 upstream. If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50 Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Signed-off-by: YunJe Shin Link: https://patch.msgid.link/20260204092546.489842-1-ioerts@kookmin.ac.kr Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman