Author: Lizhi Hou <[email protected]> Date: Wed Aug 12 13:56:28 2026 -0700 accel/amdxdna: Skip unmapped range in aie2_populate_range() [ Upstream commit 6c916e301fa10de9158b922474ade7b43d726cda ] aie2_populate_range() incorrectly failed jobs for BOs with multiple mmaps: if the unmapped entry appeared first in umap_list, the loop would pick it up, call hmm_range_fault() on a gone VMA, and return -EFAULT without ever trying the remaining valid mapps. Fix it by skipping unmapped entries. After the loop, if the map list is empty or all maps are valid, map_invalid can be cleared normally. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen <[email protected]> Signed-off-by: Lizhi Hou <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Aug 10 15:04:47 2026 +0000 af_packet: Don't send zero-byte data in tpacket_snd(). [ Upstream commit 6bcd76c134c55c697148acb5c0194e9666abdf84 ] syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") and in packet_sendmsg_spkt() via commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Reviewed-by: Jiayuan Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Tue Aug 4 00:21:54 2026 +0000 af_unix: Unlink scc_entry in unix_del_edge(). [ Upstream commit 594d905195024b228c962627ae5ae7c17bd582a4 ] Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge(). Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Reported-by: Kyle Zeng <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Kyle Zeng <[email protected]> Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm."). Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ajrat Makhmutov <[email protected]> Date: Sat Aug 8 21:55:00 2026 +0300 ALSA: hda/realtek: Enable headset mic on F+ FLAPTOP r [ Upstream commit 7097666b993b37f4e47982026b703b2379a364f8 ] The BIOS of the F+ FLAPTOP r laptop (Realtek ALC897, SSID 1e63:6d9a) declares only pin 0x1b, the headphone output of the 3.5 mm combo jack. Every other external pin is left at 0x411111f0, so the headset mic pin 0x19 is never parsed and no headset mic input exists. The pin is wired on this board - retasking it makes the headset mic record. Reuse ALC897_FIXUP_HP_HSMIC_VERB, which already sets the pin config this machine needs: 0x19 as a headset mic without its own presence detect. Only 0x1b reports jack presence here, so a mic pin with presence detect would leave the driver in auto-mic mode waiting for an event that never arrives. Without the quirk the generic parser retasks the lone headphone pin as an input instead. That surfaces as a "Headphone Mic" input which records only the internal mic bleed, so the headset mic appears present but dead. Tested on ALT Linux, kernel 6.12, by recording a CTIA headset mic on the combo jack with the internal mic as a reference. ALSA info before the patch: https://alsa-project.org/db/?f=18363eddea933baee100c9bf461d0e5cf74c8de2 ALSA info after the patch: https://alsa-project.org/db/?f=48ae2cd7aaf1eb0f24639ce83cd38cfd93b25f76 Cc: [email protected] # 6.12.x Signed-off-by: Ajrat Makhmutov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Sat Aug 8 17:22:54 2026 +0200 ALSA: usb-audio: Fix mixer regression on SteelSeries Arctis Nova 5 [ Upstream commit 885c22d259c8b245c479f3e19e9eeee54dee8b24 ] The recent "sticky mixer" sanity check in USB-audio driver caused a regression on SteelSeries Arctis Nova 5 (1038:2232); because the firmware doesn't handle GET_CUR requests, some mixers are effectively disabled, leading to the too low / soft volumes: usb 5-1.1: 9:0: sticky mixer values (-19712/0/256 => 0), disabling usb 5-1.1: 10:0: sticky mixer values (-21248/0/256 => 0), disabling Restore the functionality by ignoring GET_CUR errors intentionally with MIXER_GET_CUR_BROKEN quirk. Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers") Reported-by: Gert Burger <[email protected]> Closes: https://lore.kernel.org/CAEQ1D3kdA3mkQx7ei9Kq0gwky0qroJqCLKrkvgfkqgTbeu086A@mail.gmail.com Link: https://bbs.archlinux.org/viewtopic.php?id=314220 Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jon Hunter <[email protected]> Date: Tue Jul 28 16:50:59 2026 +0100 arm64: tegra: Add EL2 virtual timer interrupt for Tegra194 [ Upstream commit a7c28483fd57dd0e1487024af70622315320774b ] Commit d87773de9efe ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE") updated the ARM arch timer driver to use the virtual timer by default if the CPU is running at EL2 with VHE enabled. If the CPU is running at EL2 with VHE enabled but there is no interrupt provided for the virtual timer, then the following warning is displayed: arch_timer: [Firmware Bug]: VHE-capable CPU without EL2 virtual timer interrupt This warning is observed on Tegra194 platforms. Tegra194 SoC includes NVIDIA Carmel ARM v8.2 CPUs and support an EL2 virtual timer. Fix the above warning by adding the PPI for the EL2 virtual timer interrupt for Tegra194. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dawid Wróbel <[email protected]> Date: Thu Jul 30 12:58:12 2026 +0200 ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses commit 1ba381759e45d5d0442452cfa5c42e836191a568 upstream. The "DEC0 MODE" to "DEC7 MODE" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow Fixes: c39667ddcfc5 ("ASoC: codecs: lpass-tx-macro: add support for lpass tx macro") Assisted-by: Claude:claude-fable-5 Cc: [email protected] Signed-off-by: Dawid Wróbel <[email protected]> Reviewed-by: Srinivas Kandagatla <[email protected]> Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-1-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dawid Wróbel <[email protected]> Date: Thu Jul 30 12:58:13 2026 +0200 ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses commit 56f24311fd5607588a47e44675195a9efb200f29 upstream. EAR SPKR PA Gain" and the four "WSA RX* Mux" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL. Fixes: 809bcbcecebf ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro") Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Assisted-by: Claude:claude-fable-5 Cc: [email protected] Signed-off-by: Dawid Wróbel <[email protected]> Reviewed-by: Srinivas Kandagatla <[email protected]> Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-2-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Aug 5 11:24:11 2026 +0300 ASoC: cs35l41: sort the register default table commit d74aac116cfb2058b15df53996d23232b310f7ff upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so the binary search does not find those two entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Reviewed-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Aug 5 11:24:12 2026 +0300 ASoC: cs35l45: sort the register default table commit f39a68ed08bb6eef0ae711b41d645ee5e9448c09 upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers (0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with much lower addresses, so the binary search does not find 36 of its 73 entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 74b14e2850a3 ("ASoC: cs35l45: DSP Support") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Reviewed-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Wed Aug 5 11:24:13 2026 +0300 ASoC: cs4265: sort the register default table commit e4fe3e046524e5de3c04c6eef3743780cbdc231c upstream. reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e), CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search does not find those three entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Reviewed-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Thu Jul 30 14:23:43 2026 +0300 ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout commit 17661c67b206612cb3ba65d5ae726cd2015d0a53 upstream. Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state. Fixes: c40aad7c81e5 ("ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Thu Jul 30 08:48:22 2026 +0300 ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup commit 0c0e418dbcf0582bf80d8dbfd9b306607c065992 upstream. The ipc_config_data buffer for copier widgets is built once during ipc_prepare (called from sof_pcm_setup_connected_widgets) and cached for reuse. For host copiers this buffer contains the copier_data with gtw_cfg.node_id (host DMA ID). For DAI copiers it additionally includes a dma_config_tlv trailer with stream_id and dma_channel_id for HDA link DMA. On suspend/resume, both host and link DMA streams are released and re-allocated with potentially different stream tags. The underlying copier_data and dma_config_tlv structures are correctly updated by host_config and sdw_hda_dai_hw_params respectively. However, since the widget list (spcm->stream[].list) persists across suspend, sof_pcm_hw_params skips sof_pcm_setup_connected_widgets and ipc_prepare never runs again to rebuild ipc_config_data. The stale cached payload is then sent to firmware with boot-time DMA channel assignments, causing DMA channel conflicts that lead to firmware errors and crashes. Fix this by refreshing copier_data and dma_config_tlv portions of ipc_config_data in sof_ipc4_widget_setup right before the IPC message is sent. This ensures the payload always reflects the current DMA state regardless of whether ipc_prepare ran. For DAI copiers, the gtw_cfg.config_length in copier_data is temporarily inflated to include the TLV size (matching the ipc_config_data layout) before copying, then restored, mirroring what sof_ipc4_prepare_copier_module does when first building the buffer. Fixes: e9c6b118de1a ("ASoC: SOF: make dma_config_tlv be an array") Cc: [email protected] Link: https://github.com/thesofproject/sof/issues/10700 Link: https://github.com/thesofproject/sof/issues/10955 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Ujfalusi <[email protected]> Date: Thu Jul 30 11:59:14 2026 +0300 ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() commit e780e4917d43683224812400fe3dc4816fceba75 upstream. If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes. Link: https://github.com/thesofproject/sof/issues/10826 Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bard Liao <[email protected]> Date: Thu Jul 30 10:17:24 2026 +0300 ASoC: SOF: topology: Use acpi mach from the machine driver commit ae63720dd7c3647d64f7a85e5e1870f90eb569d6 upstream. The parameters may be changed by the sof_sdw machine driver is the SOC_SDW_PCH_DMIC quirk is set. Use the mach_params from the machine driver to ensure the sof_sdw_get_tplg_files() function select the right function topologies. Fixes: 2fbeff33381c ("ASoC: Intel: add sof_sdw_get_tplg_files ops") Cc: [email protected] Signed-off-by: Bard Liao <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mark Brown <[email protected]> Date: Mon Aug 10 19:51:11 2026 -0400 ASoC: tas2562: Validate values for volume writes [ Upstream commit 8fb41964f7e4e4207c8999af2056894caa7a252a ] tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array. Cc: [email protected] Reviewed-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shenghao Ding <[email protected]> Date: Fri Aug 7 08:03:04 2026 +0800 ASoC: tas2781: fix clang build error for goto bypassing cleanup variable [ Upstream commit 566fec6a33075a0ea5c441c26571221f17f4ed98 ] Remove invalid goto exit paths that jump across guard(mutex) cleanup variable initialization, replace them with direct kfree(src) and return, to fix the s390 clang build error in acoustic_ctl_write(). Fixes: d75d38dc4604 ("ASoC: tas2781: Add a debugfs node for acoustic tuning") Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rosen Penev <[email protected]> Date: Thu Aug 6 16:32:31 2026 -0700 ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers [ Upstream commit f12afefb7b01f94d6d66d397f323a9914edbf70e ] The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect. Fixes: 6f6c3c36f091 ("ASoC: xlnx: add pcm formatter platform driver") Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Rosen Penev <[email protected]> Reviewed-by: Michal Simek <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Shi <[email protected]> Date: Mon Jul 27 16:12:57 2026 -0400 block: stop the timeout timer when releasing a never added disk [ Upstream commit 26cb8ebbfaf713c82e142d08828d4d765057633b ] disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme. Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Acked-by: Weidong Zhu <[email protected]> Signed-off-by: Chao Shi <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Max Kellermann <[email protected]> Date: Fri Aug 7 11:19:22 2026 -0400 ceph: avoid fs reclaim while using current->journal_info [ Upstream commit 5b602344a49e039e792ce5a8923bcc61412ee134 ] handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data. Cc: [email protected] Fixes: 315f24088048 ("ceph: fix security xattr deadlock") Signed-off-by: Max Kellermann <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Reviewed-by: Xiubo Li <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Max Kellermann <[email protected]> Date: Fri Aug 7 14:11:26 2026 -0400 ceph: fix hanging __ceph_get_caps() with stale mds_wanted [ Upstream commit 50958bb928bad3bdba9e5d1b7ff4bbadcf6951e6 ] A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ] Cc: [email protected] Fixes: 0a454bdd501a ("ceph: reorganize __send_cap for less spinlock abuse") Signed-off-by: Max Kellermann <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yiming Zhu <[email protected]> Date: Fri Jul 24 18:49:20 2026 +0800 ceph: fix MDS random selection readiness predicate commit 2c11c4bfdb7bd2808b3b3ac228e1f2d9bcf25457 upstream. CEPH_MDS_IS_READY() is parsed so that the ternary expression can return true for an MDS entry with state 0 when it is not laggy. This allows the random selector to choose a down/DNE rank. Group the ternary expression under the state check so zero-state ranks are not treated as ready. Cc: [email protected] Fixes: b38c9eb4757d ("ceph: add possible_max_rank and make the code more readable") Link: https://tracker.ceph.com/issues/78648 Signed-off-by: Yiming Zhu <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jun 23 13:56:45 2026 +0200 clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK [ Upstream commit 2ef00630c5c0b7b2c08aba7643f47594952d357e ] Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its Display Clock Controller is enabled and references parent clocks from DSI PHYs, which causes clock reparenting issues during probe (init) and warning on Eliza EVK: disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration. WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273 ... update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P) clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471) clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540) __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368) devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1)) devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104) qcom_cc_really_probe (drivers/clk/qcom/common.c:418) qcom_cc_probe (drivers/clk/qcom/common.c:445) disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza platform_probe (drivers/base/platform.c:1432) Fixes: 0e66f10942b5 ("clk: qcom: dispcc-eliza: Add Eliza display clock controller support") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Taniya Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yixun Lan <[email protected]> Date: Mon May 18 02:58:36 2026 +0000 clk: spacemit: k3: fix USB2 bus clock [ Upstream commit 51ed53630915c9cc290036fe4f430849e23bbf8e ] According to SpacemiT K3's updated docs, the USB2 ahb reset and USB2 bus clock enable bit was wrongly swapped, the correct one should be: Register : APMU_USB_CLK_RES_CTRL bit[1] : usb2_port_bus_clk_en bit[0] : usb2_port_ahb_rstn Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Reported-by: Junzhong Pan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Yixun Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yixun Lan <[email protected]> Date: Tue Jun 30 08:53:19 2026 +0000 clk: spacemit: k3: set hdma clock as critical [ Upstream commit eb525edd48907795c0d4e498ff57ad168070b289 ] HDMA clock is responsible for the internal TCM access path of X100 RISC-V core, so set the clock flag as critical to prevent it from being shut off, otherwise the Linux system will hang, for example in the case of a vector instruction access generates a page fault. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Reported-by: Han Gao <[email protected]> Tested-by: Aurelien Jarno <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Yixun Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Mon Jul 20 11:34:21 2026 +1000 crypto: ccm - Set rfc4309 maxauthsize from child [ Upstream commit 438f4896f78f69ec73d5f32d2c024193f1223569 ] Set the maxauthsize of rfc4309 using that of the child algorithm. Fixes: 4a49b499dfa0 ("[CRYPTO] ccm: Added CCM mode") Reported-by: Seohyeon Maeng <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Fri Jul 24 10:15:38 2026 +0200 crypto: qce - fix error path in devm_qce_register_algs commit 9c75402286409f5e1a75e4a445555c84066f89db upstream. If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead. Fixes: e80cf84b6087 ("crypto: qce - unregister previously registered algos in error path") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Sat Jul 25 11:06:10 2026 +0200 crypto: starfive - use scatterlist length before DMA mapping commit 6b36f13891ab4709b7d60023005176cdd5c368cf upstream. Using sg_dma_len() is only valid after mapping a scatterlist with dma_map_sg(). However, starfive_aes_aead_do_one_req() uses it before mapping the scatterlist. Use the original scatterlist length because the DMA length has not been populated yet when CONFIG_NEED_SG_DMA_LENGTH=y. Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vladislav Dronov <[email protected]> Date: Tue Jul 21 00:33:31 2026 +0200 crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req() [ Upstream commit 360f2974fcea49c61f6d6f81554741a9eeee7168 ] Perform rctx->cryptlen calculation in tegra_gcm_do_one_req() the same way it is done in tegra_ccm_crypt_init(). The current formulae may lead to a crash if a caller does not call tegra_gcm_setauthsize() and so ctx->authsize remains zero. Then a decrypt operation with incorrect rctx->cryptlen will lead to a write beyound rctx->dst_sg buffer. As a follow-up cleanup delete struct tegra_aead_ctx->authsize field since it appears to be completely unused. Also simplify tegra_ccm_setauthsize() and tegra_gcm_setauthsize() functions respectively. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Vladislav Dronov <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Lucas <[email protected]> Date: Sun Aug 2 08:35:23 2026 -0600 drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix commit 2f9a5c0f018d4a1586ee892f81f1383219676415 upstream. COLOR_SPACE_YCBCR2020_TYPE, which is selected for COLOR_SPACE_2020_YCBCR_LIMITED color_space, has coefficients that are incorrect for limited-range output. Its luma and chroma scaling is full-range so output is too bright and colors are incorrect. COLOR_SPACE_YCBCR2020_TYPE is closer to a full-range conversion matrix with incorrect luma offset, so correct the luma offset for full-range and rename it to COLOR_SPACE_YCBCR2020_FULL_TYPE. Add COLOR_SPACE_YCBCR2020_LIMITED_TYPE with correct scaling and range for limited-range output. Fix related functions so COLOR_SPACE_YCBCR2020_LIMITED_TYPE and COLOR_SPACE_YCBCR2020_FULL_TYPE are correctly selected based on dc_color_space. Derivation of both matrices follows ITU-T H.273: Table 4, MatrixCoefficients 9, BT.2020-NCL weights: KR = 0.2627, KB = 0.0593, KG = 1 - KR - KB = 0.6780. Equations 45-47 in matrix form: [ KR KG KB 0 ] M2020_NCL = [ -KR/(2(1-KB)) -KG/(2(1-KB)) 1/2 0 ] [ 1/2 -KG/(2(1-KR)) -KB/(2(1-KR)) 0 ] [ 0 0 0 1 ] Limited and Full transforms based on equations 30-32 and 36-38 with bit depth 10, normalized by 1023: [ 876/1023 0 0 64/1023 ] MLimited = [ 0 896/1023 0 512/1023 ] [ 0 0 896/1023 512/1023 ] [ 0 0 0 1 ] [ 1023/1023 0 0 0 ] MFull = [ 0 1023/1023 0 512/1023 ] [ 0 0 1023/1023 512/1023 ] [ 0 0 0 1 ] M2020_NCL_Limited = MLimited x M2020_NCL M2020_NCL_Full = MFull x M2020_NCL The upper three rows of M2020_NCL_* are stored in CR, Y, CB order. Each M2020_NCL_* value is stored as Round(value * 8192) in its 16-bit two's-complement representation. Fixes: 973a9c810c78 ("drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix") Assisted-by: OpenAI-Codex:GPT-5.6-Sol Tested-by: Igor Paunovic <[email protected]> Tested-by: Satyajit Roy <[email protected]> Signed-off-by: Nathan Lucas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 3b906e1dc7e3c9ff9f7940f6828b367a6a9ec73c) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Lucas <[email protected]> Date: Sun Aug 2 08:35:24 2026 -0600 drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE commit cd22349e86faf6e15e6c622d70c0efc57d43201e upstream. The commit cited by the Fixes tag added separate limited and full-range BT.2020 YCbCr entries to the DCE output CSC tables, but populated both entries with the same matrix copied from the common DC table. That matrix combined full-range scaling with limited-range luma offset and was incorrect for both limited and full-range output. Replace the coefficients in both entries in the DCE paths with those from the new COLOR_SPACE_YCBCR2020_LIMITED_TYPE and COLOR_SPACE_YCBCR2020_FULL_TYPE entries in the preceding commit ("drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix"). Fixes: 51e6668ab4ba ("drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs") Assisted-by: OpenAI-Codex:GPT-5.6-Sol Tested-by: Igor Paunovic <[email protected]> Tested-by: Satyajit Roy <[email protected]> Signed-off-by: Nathan Lucas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 14c8726b79d19934d6eb6d35c612e3f7204af2c6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Samuel Pitoiset <[email protected]> Date: Fri Aug 7 16:58:55 2026 +0200 drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() commit f2a1c4c6fe0a6fcde02e59dde546dba28d283635 upstream. amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. Fixes: 34d66bc7ff10 ("drm/amd/display: Fix Xorg desktop unresponsive on Replay panel") Reviewed-by: Melissa Wen <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Travis K. Bangs <[email protected]> Date: Mon Aug 3 15:13:52 2026 -0400 drm/amd: Disable DP audio spread spectrum for Cyan Skillfish commit ff209cd04845d819acc2fcc19b25904b4b7c3ea9 upstream. The VBIOS for Cyan Skillfish devices (DCN201) indicates there is DisplayPort ref clock spread spectrum downspread, so the audio clock is corrected for it. However, the clock source in this hardware does not seem to actually be running with a clock downspread, so DisplayPort audio desyncs with video after several minutes. Ignore dprefclk SS downspread on CYAN_SKILLFISH2 asic. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5429 Signed-off-by: Travis K. Bangs <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit f3a2d86587432fdd9a6d401507b60a01153453c5) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Tue Jul 28 11:20:38 2026 -0400 drm/amdgpu/gmc12.1: fix MMHUB0 check in pasid tlb flush commit 5227c2c77c3869cbbc680d5a61cb5d4574fd8e38 upstream. Check for mmhub0 rather than mmhub1. Looks like a copy paste typo. Fixes: d0c989a0aad3 ("drm/amd/amdgpu : Use the MES INV_TLBS API for tlb invalidation on gfx12_1") Cc: Shaoyun Liu <[email protected]> Reviewed-by: Shaoyun Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 0e8faef0aaa4d08f3f4f67ee7bb74e1babc8efc4) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Thu Jul 30 12:00:06 2026 -0400 drm/amdgpu/gmc12.1: implement tlb inv semaphore commit cda6ab11c1a25a572857b9ea2ded4b7cb13c2895 upstream. Needed to properly lock the interface before using it. Cc: Sonny Jiang <[email protected]> Reviewed-by: Sonny Jiang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 8e37aa0bd56ba75801a6a21bed45f96372cd9fdc) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Mon Aug 3 17:19:46 2026 +0800 drm/amdgpu/userq: serialize queue map against GPU reset commit b77a725e50c87c091f51affc8e46710badea0d49 upstream. Creating a user queue can race with a GPU reset. While recovery holds reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue create fails: amdgpu: MES(0) failed to respond to msg=ADD_QUEUE [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110) amdgpu: [drm] *ERROR* ... Failed to map Queue amdgpu: [drm] *ERROR* ... Failed to create usermode queue Take reset_domain->sem for read around the map so it runs only once MES is back up. This mirrors amdgpu_userq_cleanup() and honors the userq_mutex -> reset_domain->sem order; the reset path never takes userq_mutex, so there is no deadlock. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit a8e151fe629c63b0eb08aa57de0d434614db3e1b) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Wang <[email protected]> Date: Wed Aug 5 20:39:18 2026 +0800 drm/amdgpu: check ASPM on the dGPU host link commit 2a9c5154a5650c09ad44ff5e1dff74754e15a3c6 upstream. dGPUs with an internal PCIe switch expose graphics functions below the switch downstream port. The automatic ASPM check uses the display endpoint and evaluates the internal link instead of the host link. Use the switch upstream port for the check and report the selected link. Fixes: 0ab5d711ec74 ("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device") Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4e0d6f2876e704fff707b18c40dbd383aea4a1c9) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Thu Aug 6 12:45:24 2026 +0800 drm/amdgpu: disallow multiple FENCE chunks in one submit commit 931cd1d1baeae68e8eb2c23bc1f3d8934dca6241 upstream. amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did for p->bo_list. Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Reported-by: Yuhao Jiang <[email protected]> Assisted-by: Claude:claude-opus-5 Cc: [email protected] Reviewed-by: Christian König <[email protected]> Signed-off-by: Junrui Luo <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82) Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Asad Kamal <[email protected]> Date: Thu Jul 30 15:00:00 2026 +0800 drm/amdgpu: fix aperture iounmap skipped on device removal commit f9e5f51549000e2665e3b5e02ff876b9e09cfe95 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before invoking the fini routines. After drm_dev_unplug() the drm_dev_enter() guard in amdgpu_ttm_fini() always returns false, so iounmap() for aper_base_kaddr is silently skipped. On connected_to_cpu hardware ioremap_cache() maps the aperture as WB; when iounmap() is skipped the stale WB PAT entry persists. On reload IP discovery's memremap(MEMREMAP_WC) on the same aperture range hits a WB/WC conflict, producing an ioremap error and failing re-probe. Remove the drm_dev_enter() guard and call iounmap() unconditionally. The aperture mapping is plain MMIO and does not require device-presence protection. Surprise-removal cleanup of aper_base_kaddr is already handled unconditionally by amdgpu_device_unmap_mmio(). Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit fb3f68af9f6fce9343a2bd13b4d68a1c02d283df) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Wed Jul 29 16:57:08 2026 +0800 drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG mode commit 4301e60e406c613aea06fdc0c36bf0675b0b8a2e upstream. Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 75a308eef4503a9d2bf297bef5a9317d2209e696) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Wed Jul 29 16:57:08 2026 +0800 drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG mode commit c87801f545dac9fcbb84c96f280706572be00a85 upstream. In DPG mode jpeg_v5_0_0_ring_reset() takes the DPG stop path, which only clears the JPEG_PG_MODE bit and never resets the JRBC. A hung ring is not recovered: the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset which has no DPG path. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 79b3612827d1adcd2008cd585961fa35a6ff20f2) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse Zhang <[email protected]> Date: Wed Jul 29 16:57:08 2026 +0800 drm/amdgpu: fix JPEG v5.3.0 queue reset failure in DPG mode commit d2dc81ed5191e7e06a8aa3e153f665d36bae8eb6 upstream. Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test times out and the driver falls back to a full MODE1 reset. Temporarily force the static power-gating path during the reset so the stop/start sequence power-cycles the JPEG block (JMI soft reset + power off/on), matching the jpeg_v4_0 reset. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit e93659cab11c48255dcac58af60203c99815586b) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Jun 5 17:46:19 2026 -0400 drm/amdgpu: fix missing check in vm_flush() commit 47cd31185090bd1439d4587b835ac22d7ba6f1e3 upstream. We shouldn't return early if we need to emit spm update. Reviewed-by: David Rosca <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 54a118f1d7e184fcbb18f83889f48f17a767878a) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Wang <[email protected]> Date: Mon Aug 10 12:48:19 2026 +0800 drm/amdgpu: fix nbif 6.3.1 l1 low power not functional commit cd688a3cb342b9f56399aa076157f1c324c15c5a upstream. The PCIe L1 low‑power settings for NBIF 6.3.1 were never applied due to unresolved register mapping, which caused the relevant code to be compiled out. As a result, the PCIe link could not enter L1/L23 power‑down states or transition to L0s. Properly configure the link control register to enable L1 and L23 power‑down, and permit L0s link transitions. Keep LTR disabled and let the PCI core enable it only after verifying end‑to‑end root complex support across switches. Fixes: 894c6d3522d1 ("drm/amdgpu: Add nbif v6_3_1 ip block support") Signed-off-by: Yang Wang <[email protected]> Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit c2417f9fd7049d5a8d87eefd82fd6e36ba1ff7b6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Thu Jul 30 18:01:51 2026 +0200 drm/amdgpu: Fix UVD decode image min size calculation commit b8bb9ba3f101a1b0011f785a577a4a0a38371174 upstream. This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. Signed-off-by: David Rosca <[email protected]> Acked-by: Leo Liu <[email protected]> Reviewed-by: Ruijing Dong <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Thu Jul 30 17:56:17 2026 +0200 drm/amdgpu: Fix UVD dpb min size calculation for H264 commit 21a8084cd76223a13493237e04d45f5226d7cee6 upstream. This should use actual number of references from the decode message, instead of maximum derived from level. Signed-off-by: David Rosca <[email protected]> Acked-by: Leo Liu <[email protected]> Reviewed-by: Ruijing Dong <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Thu Jul 30 18:05:52 2026 +0200 drm/amdgpu: Fix UVD min buffer sizes commit 18727670b44753865b81c56a9338c0d7bd102c54 upstream. Use correct size for message buffer = sizeof(struct ruvd_msg). Add ITSCALING_TABLE_BUFFER size. Signed-off-by: David Rosca <[email protected]> Acked-by: Leo Liu <[email protected]> Reviewed-by: Ruijing Dong <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 37519d007e4261febbcf35b3045f8344f3145497) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Mon Aug 10 11:11:35 2026 +0200 drm/amdgpu: Implement insert_end for VCE 3 commit d5ab4c6a64efef2d143a96df5357f59703cd703d upstream. After a recent change VCE now hangs when VCE_CMD_END is emitted after a pipeline sync without VM flush. Implement insert_end to correctly insert only one VCE_CMD_END per job. Fixes: bc639a9eadc7 ("drm/amdgpu: always emit the job vm fence") Signed-off-by: David Rosca <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 8897ea8c761b856f02061848a7908040a1fe5e68) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Mon Jul 13 16:34:24 2026 +0530 drm/amdgpu: Prefer default discovery offset commit ac828b94e027d29af82325fcc55556dc8173fd85 upstream. If a valid signature is seen at the default offset, use the default size/offset for discovery. Fixes: 01bdc7e219c4 ("drm/amdgpu: New interface to get IP discovery binary v3") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5447 Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 46a0df99a0b2fa2fa61d864b04b6a5d5fe748779) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qiang Yu <[email protected]> Date: Thu Jul 23 17:20:47 2026 +0800 drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12 commit 2d69604b4d0b9c0c0ac71624b5fafb36cf249729 upstream. TA_CNTL2.TRUNCATE_COORD_MODE selects whether texture coordinate truncation is D3D9/GL/Vulkan conformant. gfx11 reads it and reports it to userspace via AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, but gfx12 never read it, so the flag was always reported as 0 and userspace fell back to the non-conformant path. Read it in gfx_v12_0_constants_init() like gfx11 does. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Signed-off-by: Qiang Yu <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4261cbc7b03f1f56e95aeaf1492b8690fa5a253e) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Candice Li <[email protected]> Date: Thu Jul 30 11:28:10 2026 +0800 drm/amdgpu: reject oversized IBs with per-ring packet limits commit fd37f9dd5b5ab70a46fa7bc76623c0528d602b27 upstream. On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. Signed-off-by: Candice Li <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Thu Jul 30 17:37:44 2026 +0200 drm/amdgpu: Reject UVD message with dimensions above 4096 commit 8c9aebcdd9f46f7a14b98d6ab18574b7a48fbb08 upstream. Fixes potential overflow in DPB size calculations. Signed-off-by: David Rosca <[email protected]> Acked-by: Leo Liu <[email protected]> Reviewed-by: Ruijing Dong <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 05e1387d151f71569fbe122d2c89f9db0c21dc10) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Rosca <[email protected]> Date: Tue Aug 11 11:03:10 2026 +0200 drm/amdgpu: Reject UVD message with invalid number of h265 refs commit 9fca434208f1f9ab977feac62df8ebb1cc7ce893 upstream. Same change as for h264, avoids overflow later when calculating min dpb size. Signed-off-by: David Rosca <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Wed Jul 29 13:00:21 2026 +0530 drm/amdgpu: Use virtual alloc during coredump commit b88a5a43c070df46939de419663d4679b90caf2f upstream. The number of rings with outstanding fences can be large, requiring a bigger allocation. Such allocations don't need to be physically contiguous, so use kvzalloc/kvcalloc which fall back to vmalloc when contiguous memory isn't available. This also matches the existing kvfree used to free these allocations. Also guard the allocation with ring_count to avoid passing 0 size to allocation routines. Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device") Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 74d48bd6b7e12eba65de0507475b059966685ad1) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Candice Li <[email protected]> Date: Mon Jul 27 11:51:37 2026 +0800 drm/amdgpu: validate GEM_CREATE domain combinations commit 5e9d136ad74df4edec67e502ce267597064d8f86 upstream. AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) Signed-off-by: Candice Li <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Palacek <[email protected]> Date: Sat Aug 15 11:55:32 2026 -0400 drm/amdkfd: Add bounds check for CRAT subtype length [ Upstream commit 6e7566ba4739dd573c331adde1c96690f7a567bd ] The CRAT parser validates that the subtype header fits within the image, but does not verify that the advertised subtype length fits. A malformed CRAT table with an oversized length field causes out-of-bounds reads when kfd_parse_subtype() casts the header to specific subtype structures. Add validation that sub_type_hdr + length does not exceed the image boundary before parsing the subtype contents. Signed-off-by: William Palacek <[email protected]> Reviewed-by: Alysa Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d) Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John Harrison <[email protected]> Date: Thu Jul 23 15:06:52 2026 -0700 drm/connector/hdmi: Fix out of bounds memory read commit 9ecf8ba763d0ffe0673538eb4bf7806f20455d19 upstream. A helper function was copying a given audio infoframe into the connector's copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation. Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination. I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can't corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Cc: Ville Syrjälä <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Simona Vetter <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Nicolas Frattaroli <[email protected]> Cc: Jani Nikula <[email protected]> Cc: José Expósito <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: [email protected] Cc: [email protected] # v6.11+ Signed-off-by: John Harrison <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shixiong Ou <[email protected]> Date: Thu Jul 30 09:44:40 2026 +0800 drm/log: Fix division by zero when scale module parameter is 0 [ Upstream commit 921ac6cb066d09b5765db892d0db0ffaffa98767 ] The scale module parameter can be set to 0 via kernel command line. When scale is 0, scaled_font_h and scaled_font_w become 0, causing a division by zero in the rows/columns calculation. Since the scale module parameter is read-only (0444 permissions), it cannot be changed at runtime via sysfs. Clamp it to 1 once in drm_log_register(). Fixes: 8a4b913df427 ("drm/log: Add integer scaling support") Signed-off-by: Shixiong Ou <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jocelyn Falempe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shixiong Ou <[email protected]> Date: Wed Jul 29 16:48:15 2026 +0800 drm/log: Fix infinite loop when scale is too large for display [ Upstream commit f4f2bba28df9b9aaa00262a462139dbbcdc38d9f ] When scale is large enough that scaled_font exceeds the display dimensions, rows or columns become 0. A columns value of 0 causes an infinite loop in drm_log_draw_kmsg_record() because the loop never decrements len. Check for zero rows/columns in drm_log_setup_modeset() and return an error, cleaning up the already allocated buffer to avoid a leak. Fixes: 8a4b913df427 ("drm/log: Add integer scaling support") Signed-off-by: Shixiong Ou <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jocelyn Falempe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shixiong Ou <[email protected]> Date: Wed Jul 29 16:45:17 2026 +0800 drm/log: Fix out-of-bounds read on empty message length [ Upstream commit 60baa179ed1333535f6e2da4133511db55278ee4 ] drm_log_draw_kmsg_record() accesses s[len - 1] to strip the trailing newline, but len is unsigned int. If len is 0, the subtraction wraps to UINT_MAX, causing an out-of-bounds read. Add an early return when len is 0. Fixes: 25e2c2a3eff5 ("drm/log: Color the timestamp, to improve readability") Signed-off-by: Shixiong Ou <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jocelyn Falempe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhishek Rajput <[email protected]> Date: Wed Aug 12 08:30:21 2026 -0400 drm/mediatek: Convert legacy DRM logging to drm_* helpers in mtk_dsi.c [ Upstream commit c319b83e152181cc669a761695a9475510f5d3e5 ] Replace DRM_INFO(), DRM_WARN() and DRM_ERROR() calls in drivers/gpu/drm/mediatek/mtk_dsi.c with the corresponding drm_info(), drm_warn() and drm_err() helpers. The drm_*() logging helpers take a struct drm_device * argument, allowing the DRM core to prefix log messages with the correct device name and instance. This is required to correctly distinguish log messages on systems with multiple GPUs. This change aligns the radeon driver with the DRM TODO item: "Convert logging to drm_* functions with drm_device parameter". Signed-off-by: Abhishek Rajput <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Stable-dep-of: 3e191eddbdcb ("drm/mediatek: mtk_dsi: Enable HS clock only at pre-enable") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Wed Aug 12 08:30:22 2026 -0400 drm/mediatek: mtk_dsi: Enable HS clock only at pre-enable [ Upstream commit 3e191eddbdcb8bf7beb1e9b58209073bd5450719 ] Commit 76255024cadb ("drm/mediatek: mtk_dsi: enable hs clock during pre-enable") rightfully moves the HS clock enablement to before atomic_enable(), but it's moving it to mtk_dsi_poweron(), which is not only called in the .atomic_pre_enable() callback for the DRM bridge, but also in the MediaTek DRM's .ddp_start() callback, which happens way before the bridge ones. The HS clock enablement should be done at just the right time, otherwise some bridge chips (or some Display Driver ICs) may not work correctly: this is seen at least with a Parade DSI to eDP bridge (PS8640) on the MT8173 Elm Chromebook. This resolves a regression that was seen on the aforementioned machine, which was happening only after a suspend-resume cycle. Cc: <[email protected]> # 7.1.x Fixes: 76255024cadb ("drm/mediatek: mtk_dsi: enable hs clock during pre-enable") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Tested-by: Adam Thiede <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Osama Abdelkader <[email protected]> Date: Fri Jul 24 19:26:20 2026 +0200 drm/panthor: skip zero-sized firmware sections commit 2b8f13d3c7e26c46c20d9e367904cf01729c88e6 upstream. panthor_fw_load_section_entry() skips BO creation when the firmware section VA range is empty. If such a section is added to the firmware section list, section->mem is left as NULL. Later reload and unplug paths iterate over all firmware sections and dereference section->mem, which can lead to a NULL pointer dereference. Zero-sized firmware sections are valid, so accept them as no-op entries but skip adding them to the section list. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: [email protected] Signed-off-by: Osama Abdelkader <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Reviewed-by: Steven Price <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Steven Price <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Sat Aug 8 21:59:42 2026 +0800 drm/radeon: fix autosuspend cleanup during teardown commit 587be7a17358ef8c0106775fcedae5a7bef50735 upstream. radeon_driver_load_kms() calls pm_runtime_use_autosuspend() for PX devices, but radeon_driver_unload_kms() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver unload path. This issue was found by manual code inspection. Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)") Signed-off-by: Guangshuo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 0fdc1ff82ea14844c22795e9e0813c3ca03235e1) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wang Jiang <[email protected]> Date: Wed Jul 29 18:26:26 2026 +0800 drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression commit 5f08eee9c3fb1a5a70966612e0ff249900f8e77b upstream. Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") removed the hardware polling from radeon_fence_is_signaled() to fix a self-deadlock caused by wake_up_all(&rdev->fence_queue) being called with the fence queue lock held. However, removing the polling entirely causes significant performance regression (e.g. glxgears FPS drop) because the fence signaled check becomes purely passive — it only reads the cached last_seq without probing the GPU, so completed GPU work is not detected in time, causing unnecessary CPU stalls in sync-heavy workloads. Fix this by calling radeon_fence_activity() directly instead of radeon_fence_process(). radeon_fence_activity() reads the hardware fence counter and updates last_seq via atomic ops without calling wake_up_all(), thus avoiding the deadlock while restoring timely fence detection. Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock") Acked-by: Christian König <[email protected]> Signed-off-by: Wang Jiang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit f59ad4cca219c7fdf934f712c5860ec5f5900fd7) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian A. Ehrhardt <[email protected]> Date: Mon Jun 22 23:57:17 2026 +0200 drm/shmem_helper: Check VMA boundaries for PMD mappings commit 617bbd08714857c1613d7c550d43a9092ec0fb97 upstream. In the ->huge_fault handler do not install a PMD huge page mapping if the huge page exceeds the boundaries of the VMA. All other ->huge_fault handlers have similar checks and the resulting mapping will trigger a VM_BUG_ON_VMA() if it ever reaches copy_pmd_range(). Cc: Pedro Demarchi Gomes <[email protected]> Cc: Boris Brezillon <[email protected]> Cc: [email protected] Fixes: fc3bbf34e643 ("drm/shmem-helper: Fix huge page mapping in fault handler") Signed-off-by: Christian A. Ehrhardt <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Boris Brezillon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jia Yao <[email protected]> Date: Tue Aug 4 16:50:55 2026 +0000 drm/xe/guc_ads: allocate UM queues in a separate BO commit 99b01815957bd7d848420cb697f79ed11f7f215c upstream. Move the UM queues into a dedicated BO (ads->um_queue_bo) and avoid CPU memset operations on it, which eliminates the CPU as a potential cacheline-polluting agent and helps maintain consistency between GAM writes and GuC reads. We also need to ensure the base_dpa for the queue is contiguous on hw where this is used instead of a GGTT address. Another good reason to split this out to a separate BO. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <[email protected]> Cc: Matthew Auld <[email protected]> Cc: <[email protected]> # v6.12+ Signed-off-by: Jia Yao <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 6af05de0dc19bbf3aaeec2020fe48b37c834b811) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jia Yao <[email protected]> Date: Tue Aug 4 16:50:56 2026 +0000 drm/xe/guc_ads: allocate UM queues in VRAM on dGFX commit f342810a141f8a7e8b3786a6e4b6c0695a078a74 upstream. On iGPU, the UM queue BO is allocated in system memory. On dGFX, the BO was previously created in system memory and later reallocated in xe_guc_realloc_post_hwconfig(). Allocate the UM queue BO directly in VRAM on dGFX, where it is ultimately required. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <[email protected]> Cc: Matthew Auld <[email protected]> Cc: <[email protected]> # v6.12+ Signed-off-by: Jia Yao <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit ace076ef0a854ab5940bacc539bf66afd61d118c) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jia Yao <[email protected]> Date: Tue Aug 4 16:50:57 2026 +0000 drm/xe/guc_ads: use uncached mapping for UM queue BO commit 8d5134ae4177fa4f5a9bc8e71e6656cfc2852882 upstream. On Pre-Xe3p platform, the GAM write the UM queue through DPA using UC. if GuC reads the queue via GGTT (WB), stale data may be observed when the cacheline has been polluted by another agent. To match the GAM's UC writes, configure the GuC mapping as UC as well. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <[email protected]> Cc: Matthew Auld <[email protected]> Cc: <[email protected]> # v6.12+ Signed-off-by: Jia Yao <[email protected]> Reviewed by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 9daa302a82590eeee7bdc68023ddad302df4b88c) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linmao Li <[email protected]> Date: Mon Jul 13 16:30:53 2026 +0800 drm/xe/oa: Check managed mutex initialization errors [ Upstream commit f110dbbfa2a94c91704bf19806907a98fd73ca14 ] drmm_mutex_init() can fail while registering its managed cleanup action. On failure, the reset path destroys the mutex, so continuing OA setup leaves an unusable lock that later paths may acquire. Return the error from per-GT OA initialization and abort device-wide OA initialization if the metrics lock cannot be initialized. Fixes: a9f905ae7b6f ("drm/xe/oa/uapi: Initialize OA units") Fixes: cdf02fe1a94a ("drm/xe/oa/uapi: Add/remove OA config perf ops") Signed-off-by: Linmao Li <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 360b293de27bfdd0d07047f8efd5ba8e91fa90b7) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linmao Li <[email protected]> Date: Fri Jul 31 09:19:32 2026 +0800 drm/xe/oa: Fix sync entry leak on OA config emit failure [ Upstream commit 8d33c4987cd162527375a3905017ae129ba7c3fe ] xe_oa_emit_oa_config() releases the sync entries and the syncs array only on its success path. When it fails before the point of no return (fence allocation, config buffer allocation or batch submission), it returns without touching stream->syncs. The stream open path handles such failures in the caller, but xe_oa_config_locked() propagates the error without any cleanup, so the syncs array and the fence references held by the parsed entries are leaked. The next config ioctl overwrites stream->syncs, making the memory unreachable for good. Clean up the parsed syncs when xe_oa_emit_oa_config() fails, matching the cleanup done by the stream open error path. Fixes: 9920c8b88c5c ("drm/xe/oa: Add syncs support to OA config ioctl") Signed-off-by: Linmao Li <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Ashutosh Dixit <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 8af97b3da2cfce04e6b457c6eb17ed3c1daf912b) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniele Ceraolo Spurio <[email protected]> Date: Mon Jul 20 15:27:58 2026 -0700 drm/xe/pxp: add termination on resume [ Upstream commit 51afaf53e01e01bda489fc6ffacf07a706e72783 ] Suspend/resume causes the PXP keys to become invalid, but doesn't actually kill the session. The driver also doesn't explicitly kill and re-start the session until a new PXP request comes in, which means that the "zombie" session can potentially stick around if there are no new requests from userspace. While this is not an issue for PXP, HDCP has a new behavior starting on PTL where a communication is sent to GSC if a session is active at suspend time (even if it doesn't have a valid key), which can lead to delays in the suspend flow if we suspend while the zombie session is still active. To avoid this, we can trigger a termination on resume and kill the zombie session immediately, instead of delaying the termination to the next PXP request. Due to restrictions in the rpm suspend/resume flow, we can't call the termination flow from within the resume call itself, so the pxp irq worker is expanded to cover this scenario. The existing logic in the worker doesn't work as-is for the new flow, because the pm_get_if_active will fail if the worker runs before the pci_resume call has completed (which is possible, since we queue it from within that call) or after we're started to suspend again. Given that we always want to run the worker after a resume (differently from the irq case, where we want to skip if we're suspended), we can solve this by just taking the PM reference before queueing the worker. As part of this rework, the pxp->events variable has been moved to atomic, to avoid having to take xe->irq.lock from non-irq related paths. Fixes: b1dcec9bd8a1 ("drm/xe/ptl: Enable PXP for PTL") Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Julia Filipchuk <[email protected]> Cc: Alan Previn <[email protected]> Reviewed-by: Alan Previn <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 757bda2b8b93fa36ad9b2c7993081d5f9d0d6e3b) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vinay Belgaumkar <[email protected]> Date: Wed Aug 5 16:46:49 2026 -0700 drm/xe: Fix a bug in pc_adjust_freq_bounds() [ Upstream commit 5cf82c8cec90056511eb881a267aab6101eaf57a ] In cases where min frequency was actually greater than BMG_MIN_FREQ, we were not using the updated min frequency as there was a missing call to pc_action_query_task_state() between the two settings of min frequency. Since we know what min_freq was last set, use that cached value while comparing to BMG_MIN_FREQ to fix this issue. v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay with pc_action_query_task_state() instead. v3: Update commit message (Stuart) Fixes: bdde16c9ac5c ("drm/xe/bmg: Update Wa_14022085890") Signed-off-by: Balasubramani Vivekanandan <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit a2c2d2b13a9ea9494d2d76b46273833111749507) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raag Jadav <[email protected]> Date: Mon Aug 10 18:08:20 2026 +0530 drm/xe: Fix xe_device_probe() failure commit ef526d122b62af5afa437f095aa6661a953676c4 upstream. Currently, xe_device_probe() jumps to err_unregister_display label in case of failure except for its last call, which directly returns the error without required cleanup handling. This results in stale drm device that isn't cleaned up on unwind. Fix it. [ 810.194180] 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' [ 810.194183] CPU: 9 UID: 0 PID: 5616 Comm: modprobe Kdump: loaded Tainted: G S U E 7.2.0-rc2-xe #382 PREEMPT(full) [ 810.194185] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER, [E]=UNSIGNED_MODULE [ 810.194186] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1805 10/30/2024 [ 810.194186] Call Trace: [ 810.194187] <TASK> [ 810.194188] dump_stack_lvl+0xe0/0x100 [ 810.194195] dump_stack+0x14/0x20 [ 810.194197] sysfs_warn_dup+0x5f/0x80 [ 810.194204] sysfs_create_dir_ns+0xbe/0xd0 [ 810.194210] kobject_add_internal+0xbc/0x2b0 [ 810.194215] kobject_add+0x7c/0xe0 [ 810.194220] ? get_device_parent+0xcf/0x1e0 [ 810.194227] device_add+0xe3/0x870 [ 810.194231] ? __pfx_drm_gem_name_info+0x10/0x10 [drm] [ 810.194280] drm_minor_register+0x73/0x130 [drm] [ 810.194322] drm_dev_register+0x76/0x2a0 [drm] Cc: [email protected] Fixes: da3799c97572 ("drm/xe: Use GuC to do GGTT invalidations for the GuC firmware") Signed-off-by: Raag Jadav <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> (cherry picked from commit 5ce3042c67c539480882567137ff8d56118885d6) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthew Brost <[email protected]> Date: Fri Aug 7 10:17:16 2026 -0700 drm/xe: Order ring writes before ring tail updates commit 9f83c94469ff0fa37274b873ba24922e02531fa7 upstream. The ring buffer and the LRC context image are both mapped WC, so the ring tail update can become visible to the device before the ring contents it is meant to publish. The GuC CT send does contain an xe_device_wmb(), so sending the H2G would flush the ring contents. The problem is that it comes too late: xe_lrc_set_ring_tail() publishes the tail before the H2G is sent, and the device samples the tail from the context image independently of it, either at context switch-in or while the context is already resident. A submitter which is interrupted between updating the tail and sending its H2G therefore leaves the device free to observe the new tail while the ring contents behind it are not yet visible: 1. Thread A emits a job into the ring, sets the tail to T_A and sends the H2G, which flushes A's ring contents. The GuC starts scheduling the context in, but it is not executing yet. 2. Thread B emits a job into ring[T_A..T_B]. Those writes are not yet visible to the device. 3. Thread B updates the ring tail to T_B. That write targets a different page and becomes visible first. 4. Thread B is interrupted before it sends its H2G, so the flush which would have published ring[T_A..T_B] has not happened yet. 5. The context is switched in and samples the ring tail from the context image, picking up T_B rather than T_A. 6. The GPU executes A's job, advances HEAD to T_A, and continues on to ring[T_A..T_B], which still holds the previous wrap's contents, so the CS parses stale commands. The result is command stream corruption, which typically manifests as a hang or a spurious pagefault rather than anything that points back at the submission path. Kernel jobs are by far the most likely to hit this. Kernel queues such as the migration queue are shared and can be driven by many threads concurrently, producing back-to-back submissions on an LRC which is already executing. User queues are typically tied to a single submitting thread, so the same interleaving is much harder to produce. Add an xe_device_wmb() at the end of xe_lrc_write_ring() so that it covers every ring tail publication site, and so the invariant is local: once xe_lrc_write_ring() returns, the ring contents are visible to the device. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8651 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7810 Cc: [email protected] Signed-off-by: Matthew Brost <[email protected]> Assisted-by: GitHub_Copilot:claude-opus-5 Reviewed-by: Stuart Summers <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 136360290f314890428a3fbf31aaa8e4f1d43567) Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nareshkumar Gollakoti <[email protected]> Date: Thu Mar 26 12:04:09 2026 +0530 drm/xe: Set GT rp min frequency as 1.2GHz default for BMG/CRI [ Upstream commit d0672008cde3a8616c517d53d657300dce3c36a7 ] While previously applied only to both tiles GT0(Graphics) and Media(GT1) the BMG G21(Battle image) platform via workaround Wa_14022085890, this 1.2 GHz minimum is now the default for GT0(Graphics) tile of BMG and CRI platforms. Setting this frequency floor(1.2GHz) default is critical in multi GPU environment for supporting effective Peer-to-Peer(P2P) transactions. v2: - Fix Indentation(Thomas) - Add comment about power impact(Stuart) v3:(Thomas/Ankur/Matt Roper) - Add setting frequency to only GT0(Graphics) Tile of BMG/CRI v4:(Stuart) - Move WA check to pc_needs_min_freq_change function Signed-off-by: Nareshkumar Gollakoti <[email protected]> Reviewed-by: Vinay Belgaumkar <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> Stable-dep-of: 5cf82c8cec90 ("drm/xe: Fix a bug in pc_adjust_freq_bounds()") Signed-off-by: Sasha Levin <[email protected]>
Author: Gao Xiang <[email protected]> Date: Wed Aug 12 21:11:43 2026 +0800 erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms [ Upstream commit a64d500b0078e16e9abb25baca4dee1dbc9054fc ] CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this can cause make oldconfig to loop indefinitely when CONFIG_SMP=n: $ make ARCH=arm allmodconfig $ sed -i "/CONFIG_SMP=y/d" .config $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) ... Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS depend on SMP"). The initial report from SJ Park was for m68k [1] (m68k is the only arch without NR_CPUS in Kconfig), and that got fixed in commit 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Reported-by: SJ Park <[email protected]> Link: https://lore.kernel.org/all/[email protected]/T/#u [1] Closes: https://lore.kernel.org/r/[email protected] Reported-by: Guenter Roeck <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Gao Xiang <[email protected]> Tested-by: SJ Park <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Aug 3 12:31:35 2026 -0700 eth: bnxt: avoid deadlock when canceling IRQ affinity notifier [ Upstream commit 51e96fa31f7e7eac2cba8f854e24d36600cc040b ] Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Tested-by: Vishvambar Panth S <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Aug 3 12:31:32 2026 -0700 eth: bnxt: cancel IRQ notifier before freeing affinity mask [ Upstream commit c703f62c30f2db7f40ad575f0034636d8a401fac ] bnxt_irq_affinity_notify() copies into irq->cpu_mask. Cancel the notifier before freeing irq->cpu_mask. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Reviewed-by: Michael Chan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Aug 3 12:31:34 2026 -0700 eth: bnxt: decrease indent in bnxt_request_irq() [ Upstream commit 0fd562c7b9e48e7958f7405e54bf98e8e22ad184 ] bnxt_request_irq() has unnecessary level of indentation. Use continue instead. No need to re-fetch NUMA node for each IRQ, move to the function level. No functional changes. Reviewed-by: Breno Leitao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 51e96fa31f7e ("eth: bnxt: avoid deadlock when canceling IRQ affinity notifier") Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Aug 3 12:31:33 2026 -0700 eth: bnxt: keep the aRFS rmap updated when TPH is enabled [ Upstream commit 4b5cb58a4443fff67aa18a0d7b645b2220f2fcf8 ] The TPH support must have broken aRFS in bnxt. IRQ can only have one notifier, so installing the TPH notifier is overriding the one implicitly installed by irq_cpu_rmap_add(). Make sure we call cpu_rmap_update() from the TPH notifier. We need to be careful with the ordering and not free the rmap until we unregistered the notifier. Note that moving the rmap freeing after the early return in bnxt_free_irq() is fine - there's no path that could leave rmap with irq_tbl being NULL. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Reviewed-by: Michael Chan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Melbin K Mathew <[email protected]> Date: Thu Jul 2 01:42:46 2026 +0200 fbdev: bound mode sysfs output to the sysfs buffer commit d15d51fb26e830af58f3f21964f1c09c239077ea upstream. mode_string() uses snprintf() which can return a value larger than the remaining buffer space. show_modes() accumulates the return value into i without checking whether i has reached PAGE_SIZE, causing the offset to advance past the sysfs buffer if the modelist is long enough. Add a size parameter to mode_string() and use scnprintf() to return only the bytes actually written. Add an early return when offset already exceeds the buffer. In show_modes(), stop accumulating once the buffer is full. Cc: [email protected] # v7.1+ Signed-off-by: Melbin K Mathew <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Melbin K Mathew <[email protected]> Date: Thu Jul 2 01:42:47 2026 +0200 fbdev: clear fb_info->mode before deleting a videomode commit 95e647d2a5304a8fd11f1ba3c8502de700650131 upstream. fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode. fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer. Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed. Cc: [email protected] # v7.1+ Signed-off-by: Melbin K Mathew <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mingyu Wang <[email protected]> Date: Tue Jul 21 16:19:42 2026 +0800 fbdev: core: Fix pointer desynchronization in fb_io_read() commit 81cc73be40c6f028f1ee3f438ace46afe666dbae upstream. In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations. Fixes: 6121cd9ef911 ("fbdev: Move I/O read and write code into helper functions") Cc: [email protected] Signed-off-by: Mingyu Wang <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksandr Nogikh <[email protected]> Date: Fri Aug 7 14:25:26 2026 +0000 firewire: ohci: fix NULL pointer dereference in ar_context_release [ Upstream commit 42d217add8d80d6e7d9f58f80d11ea9b07ea113e ] During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release(). When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()). ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772 To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer. Fixes: 5716e58aecdd ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9 Signed-off-by: Aleksandr Nogikh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Josh Poimboeuf <[email protected]> Date: Wed Aug 5 21:56:46 2026 -0700 ftrace: Fix off-by-one fentry site disable in ftrace_free_mem() commit 8b8292d6487c81bd57c2605a9b404b1cf8f1edfb upstream. When a module's init text is freed, do_init_module() calls ftrace_free_mem() with a half-open [start, end) range. However the ftrace_cmp_recs() comparator treats the upper bound as inclusive, as all its other users do, passing 'ip + size - 1'. So ftrace_free_mem() can delete a record sitting exactly at 'end', which is outside the freed range. For a kernel without CFI or IBT, the first record of a function is at the function start, which for the first function in a module is also the base of its text allocation. As the module allocator packs its regions, that address is often the 'end' passed by a neighboring module's do_init_module(), causing the first function's ftrace location to get disabled, preventing an attempt to livepatch it: livepatch: failed to find location for function 'pcspkr_probe' Convert the exclusive end to the inclusive 'end - 1' the comparator expects, and return early for an empty range to avoid the subtraction from underflowing when the init text size is zero. Cc: [email protected] Fixes: 42c269c88dc1 ("ftrace: Allow for function tracing to record init functions on boot up") Link: https://patch.msgid.link/1b5ccfa8095bdb1277f84af1c2c2e2205aca03ae.1785992188.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leon Hwang <[email protected]> Date: Thu Jul 30 23:04:08 2026 +0800 ftrace: Protect direct_functions in ftrace_find_rec_direct commit 63444b7617c09aeed36282e061c3f80818f2b600 upstream. Fix accessing the __rcu pointer direct_functions with RCU protection. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Acked-by: Jiri Olsa <[email protected]> Suggested-by: Steven Rostedt <[email protected]> Signed-off-by: Leon Hwang <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leon Hwang <[email protected]> Date: Thu Jul 30 23:04:09 2026 +0800 ftrace: Protect direct_functions in update_ftrace_direct_del commit f26e5fa75fccd54bb95793c6519d405cf83233b2 upstream. Fix accessing the __rcu pointer direct_functions with RCU protection. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: 8d2c1233f371 ("ftrace: Add update_ftrace_direct_del function") Acked-by: Jiri Olsa <[email protected]> Signed-off-by: Leon Hwang <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leon Hwang <[email protected]> Date: Thu Jul 30 23:04:10 2026 +0800 ftrace: Protect direct_functions in update_ftrace_direct_mod commit 092f8ec7dbdc71f5bde9bb0f8dead384d2115a44 upstream. Fix accessing the __rcu pointer direct_functions with RCU protection. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: e93672f770d7 ("ftrace: Add update_ftrace_direct_mod function") Acked-by: Jiri Olsa <[email protected]> Signed-off-by: Leon Hwang <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junjie Cao <[email protected]> Date: Tue Aug 4 17:59:35 2026 +0800 gpio: ml-ioh: share the register lock across channels [ Upstream commit a9253ee6771c8ab3c6de07ea75d9e2c1cef3cd97 ] Suspend and resume hold channel 0's lock while saving and restoring registers for all eight channels. Code paths using the other seven locks can therefore run concurrently with PM. Use one controller-wide lock shared by all channels. Fixes: b490fa0bf86e ("gpio-ml-ioh: Fix suspend/resume issue") Reported-by: sashiko-bot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Junjie Cao <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junjie Cao <[email protected]> Date: Fri Jul 31 11:27:47 2026 +0800 gpio: ml-ioh: use raw_spinlock_t for the register lock commit 600411ea1f2443fdf5b1af9b6480f616d7aff9d0 upstream. ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 ("gpio: pch: use raw_spinlock_t for the register lock"); this driver shares the same structure as gpio-pch. Fixes: 54be566317b6 ("gpio-ml-ioh: Support interrupt function") Cc: [email protected] Reviewed-by: Linus Walleij <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Junjie Cao <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cengiz Can <[email protected]> Date: Fri Jul 31 01:02:57 2026 +0300 gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind commit 44f3468a0aef1aabdad551898ab7cfa2a9d20e99 upstream. The "trigger" debugfs file has a hand-rolled ->write handler (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The file is created with debugfs_create_file_unsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs. priv is allocated with devm_kzalloc(). devres frees it when the platform device is unbound. debugfs_create_file_unsafe() installs no full_proxy wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not wait for an in-flight trigger_write(). The blob_lock taken there does not help, because trigger_write() never takes it. A write that races an unbind therefore writes into freed memory: trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [may sleep] mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [no wait] mutex_unlock(&priv->blob_lock) (remove returns; devres frees priv) priv->trig_data = buf <-- use-after-free write priv->trig_len = count The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind. Create "trigger" with debugfs_create_file() instead. Its full_proxy wrapper makes debugfs_remove_recursive() drain any in-flight ->write before it returns. The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler. Fixes: 7828b7bbbf20 ("gpio: add sloppy logic analyzer using polling") Cc: [email protected] Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Cengiz Can <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe Leroy (CS GROUP) <[email protected]> Date: Wed Jul 29 11:47:20 2026 +0200 gpiolib: Check gc->get_direction() before calling gpiod_get_direction() [ Upstream commit d761c7e38a000603a9d16270a1af770a0e8efb5e ] According to 'struct gpio_chip' documentation in linux/gpio/driver.h, implementing .get_direction() is recommended but not mandatory. Most places verify that gc->get_direction() exists before calling gpiod_get_direction(), but gpiolib_dbg_show() doesn't. Until commit 471e998c0e31 ("gpiolib: remove redundant callback check") it was also verified by gpiod_get_direction() itself so calling it at all time from gpiolib_dbg_show() was not an issue. But after the check in gpiod_get_direction() has been removed, calling it inconditionaly leads to a big fat warning in gpiochip_get_direction(). In gpiod_get_direction(), verify that gc->get_direction() exists before calling gpiod_get_direction(). Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check") Signed-off-by: Christophe Leroy (CS GROUP) <[email protected]> Link: https://patch.msgid.link/ad89f92f91d004e63dd5599bb58e9581f373a601.1785318183.git.chleroy@kernel.org Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jordan Rhee <[email protected]> Date: Fri Aug 7 22:43:15 2026 +0000 gve: fix NULL dereference due to missing ptp adjfine commit 3992ced109c70b771efad9e51ae68e5c7a04dea3 upstream. Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] <TASK> [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610 Cc: [email protected] Fixes: acd16380523b ("gve: Add initial PTP device support") Signed-off-by: Jordan Rhee <[email protected]> Signed-off-by: Harshitha Ramamurthy <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jordan Rhee <[email protected]> Date: Fri Aug 7 22:43:14 2026 +0000 gve: fix zero-length skb frag with header-split commit 6bf14575c65569dcded90ef78afb8a6d57323f04 upstream. When header split is enabled and a header-only packet is received such as a pure TCP ACK, GVE will indicate an RX SKB with a zero-length fragment. If this SKB is then hairpinned and sent back out, the GVE TX path will emit a zero-length descriptor. Hardware considers this an illegal descriptor and stops the queue, causing a TX timeout and interface reset. Fix it by not adding the zero-length skb frag. Cc: [email protected] Fixes: 5e37d8254e7f ("gve: Add header split data path") Suggested-by: Praveen Kaligineedi <[email protected]> Co-developed-by: Ziwei Xiao <[email protected]> Signed-off-by: Ziwei Xiao <[email protected]> Signed-off-by: Jordan Rhee <[email protected]> Signed-off-by: Harshitha Ramamurthy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donglin Lyu <[email protected]> Date: Sun Aug 2 15:37:18 2026 -0700 Input: atkbd - skip deactivate for HONOR ZQC-P commit 410c44b1096789d0c40fbee706520e981dba7bc1 upstream. The internal keyboard on the HONOR ZQC-P (HONOR MagicBook Pro 14 2026) does not work after boot. Using the kernel command line 'i8042.dumbkbd=1' makes the keyboard functional, but the CapsLock LED does not work. Adding the 'atkbd_deactivate_fixup' quirk fixes the keyboard and CapsLock LED natively without requiring boot parameters. DMI: HONOR ZQC-P/ZQC-P-PCB, BIOS 1.09 03/19/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Signed-off-by: Donglin Lyu <[email protected]> Tested-by: Ruslan Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] [dtor: keep all HONOR entries together] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhefu Zhang <[email protected]> Date: Sun Aug 2 15:36:54 2026 -0700 Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard commit 3a046db33bb9f28b43a951a7a090db771dc0f8b3 upstream. The internal keyboard of the Xiaomi Book Pro 14 does not work unless atkbd skips deactivating it at the end of atkbd_probe(). Using 'i8042.dumbkbd=1' also makes the keyboard work, but then the driver never writes to the keyboard at all, so the Caps Lock LED is lost. The atkbd_deactivate_fixup quirk fixes both without a boot parameter. DMI: XIAOMI Xiaomi Book Pro 14/TM2424, BIOS XMAPT4B0P0909 05/06/2026 Signed-off-by: Zhefu Zhang <[email protected]> Reviewed-by: Andrew Zhou <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linmao Li <[email protected]> Date: Mon Jul 20 14:12:59 2026 +0800 Input: byd - synchronize timer deletion before freeing private data commit c83e79c0842ed29860648bcce5022ef0ba5001c6 upstream. byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op. Fixes: 2d5f5611dd0d ("Input: byd - enable absolute mode") Cc: [email protected] Signed-off-by: Linmao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: HyeongJun An <[email protected]> Date: Sat Jul 18 16:40:32 2026 +0900 Input: cs40l50-vibra - validate custom data from user space commit 7d5c576cb1c86047b1fcb1aa9532e17fc5e46c1d upstream. cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything: work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len; The driver then reads two words out of that buffer: custom_data[0] as the waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled: - custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it. - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one word past the allocation. The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes the "bank_type >= CS40L50_WVFRM_BANK_NUM" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the switch statement's default case gets a chance to reject it: base_index = vib->dsp.banks[effect->type].base_index; max_index = vib->dsp.banks[effect->type].max_index; Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way. Fixes: c38fe1bb5d21 ("Input: cs40l50 - Add support for the CS40L50 haptic driver") Cc: [email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Davies <[email protected]> Date: Sun Aug 2 17:53:10 2026 -0700 Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet commit 296736076b3fd078742651c719555a488624023a upstream. Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1]. Fixes: 05be1d079ec0 ("Input: psmouse - support for the FocalTech PS/2 protocol extensions") Signed-off-by: Richard Davies <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jianing Li <[email protected]> Date: Mon Aug 3 21:18:52 2026 -0700 Input: hynitron_cstxxx - validate touch count and finger IDs commit 27f380ef0e1d3de3cde114e02d33f9320ce3a5a6 upstream. The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device. Fixes: 66603243f528 ("Input: add driver for Hynitron cstxxx touchscreens") Signed-off-by: Jianing Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Fri Jul 24 20:46:27 2026 -0700 Input: iforce - validate input packet lengths commit 5751c781d3c97ab6ce0e2a966156ed882152c415 upstream. iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses. Signed-off-by: Pengpeng Hou <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linmao Li <[email protected]> Date: Fri Jul 24 18:42:06 2026 -0700 Input: psxpad-spi - set driver data before use commit 732f38c36059e68ba3b4b89c56911d777fd3185c upstream. psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe. Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI") Signed-off-by: Linmao Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Mon Jun 15 22:12:29 2026 -0700 Input: sur40 - fix input device registration ordering commit 9da976eb649c9e2f588a4499410e4d8af687925f upstream. In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered. Reported-by: [email protected] Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Mon Jun 15 22:12:30 2026 -0700 Input: sur40 - fix V4L error path cleanup commit 062dc4693e2c10d77de06f61e6f3faf37c0a8383 upstream. In sur40_probe(), if video_register_device() fails, the error path jumps to err_unreg_video. This incorrectly attempts to unregister a video device that was never successfully registered, and fails to free the V4L2 control handler (v4l2_ctrl_handler_free) that was initialized immediately prior. Fix this by introducing an err_free_ctrl label to properly free the V4L2 control handler and bypass video_unregister_device() when video device registration fails. Reported-by: [email protected] Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Thu Jun 25 22:17:54 2026 -0700 Input: synaptics-rmi4 - block s_input when F54 queue is busy commit fbfd76746adc16d64be29ff113f673b70bc3f5c2 upstream. Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming). Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Hans Verkuil <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Thu Jun 25 22:17:52 2026 -0700 Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer commit 49c5adc2b7d6e43c5cf033e1c86fdb9c16ababb1 upstream. rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check. Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Cc: [email protected] Signed-off-by: Bryam Vargas <[email protected]> Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Thu Jun 25 22:17:50 2026 -0700 Input: synaptics-rmi4 - fix F55 transmitter electrode count typo commit 6058f0fea10f3caf63a435677358d1b8e9325114 upstream. During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts. Fixes: 6adba43fd222 ("Input: synaptics-rmi4 - add support for F55 sensor tuning") Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54") Reported-by: [email protected] Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Thu Jun 25 22:17:55 2026 -0700 Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue commit 8786d74bf50e6797b6f655eb381ef6b25451161f upstream. Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Reported-by: [email protected] Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Thu Jun 25 22:17:51 2026 -0700 Input: synaptics-rmi4 - zero report size on F54 work error commit dc76c3c8e8ad09362b8c1561f3928288c15cba2e upstream. In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Cc: [email protected] Reported-by: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyohei Kadota <[email protected]> Date: Thu Jul 23 19:55:57 2026 +0900 Input: xpad - add support for ZENAIM LEVERLESS commit 7d971337ebfad0b173cb46097c709db174ac3557 upstream. Add the VID/PID for the ZENAIM LEVERLESS controller to xpad_device and the VID to xpad_table. Signed-off-by: KADOTA, Kyohei <[email protected]> Link: https://patch.msgid.link/CAFMepckDUuOHiDDVVhUYc-UqJMeCqrWSfCuxbJ2x2sGgdDD4nw@mail.gmail.com Cc: [email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Aug 6 10:38:57 2026 +0000 ipvlan: inherit needed_headroom and needed_tailroom from phy_dev [ Upstream commit e16e960d55a40d36bd7c2494cc005e757dc9a1ef ] ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Reported-by: Tangxin Xie <[email protected]> Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#mcc6307f115e500df23ea2980d5669fe95f20b6b4 Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Julian Anastasov <[email protected]> Date: Thu Aug 6 13:52:11 2026 +0300 ipvs: revalidate ihl to prevent out-of-bounds access [ Upstream commit d93660df4dd1d116f608ada4a29a80a5d6f0a6ed ] While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access. One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls. Add check to drop the packet if the ihl field is changed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260730183506.87473-1-ja%40ssi.bg Signed-off-by: Julian Anastasov <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Aug 11 14:46:51 2026 +0000 l2tp: fix tunnel and session refcount leak on seq_file release [ Upstream commit 9006c116dd111d457bf5d074990210f70a4ad2c8 ] In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file. Fixes: 0e0c3fee3a59 ("l2tp: hold reference on tunnels printed in pppol2tp proc file") Fixes: f726214d9b23 ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Assisted-by: Jetski:Gemini-3.1-Pro Cc: James Chapman <[email protected]> Cc: Guillaume Nault <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raphael Zimmer <[email protected]> Date: Tue Jul 28 10:43:40 2026 +0200 libceph: Avoid using invalid osd indices from primary_temp commit 3660b98d1204b419f6a77e9a295f148dcf38d042 upstream. A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] Cc: [email protected] Fixes: 5e8d4d36bf23 ("libceph: add support for primary_temp mappings") Signed-off-by: Raphael Zimmer <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavitra Jha <[email protected]> Date: Tue Jun 2 01:02:19 2026 -0400 libceph: fix multiple unsafe decodes in decode_locker() commit 437b6551cfcc235eea1d735a874f9d421f555e17 upstream. decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ] Cc: [email protected] Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavitra Jha <[email protected]> Date: Wed Jul 8 01:39:41 2026 -0400 libceph: fix OOB read in decode_watchers() via missing bounds check commit 00ead17c7de137a692edee59f2772e6af687e8eb upstream. ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ] Cc: [email protected] Fixes: a4ed38d7a180 ("libceph: support for CEPH_OSD_OP_LIST_WATCHERS") Signed-off-by: Pavitra Jha <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kefu Chai <[email protected]> Date: Thu Jun 11 19:32:51 2026 +0800 libceph: tolerate addrvecs with multiple entries of the same type commit 5a87925539acecfe88229bad76ab81bd75a7e3f5 upstream. ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: [email protected] Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Sun Aug 23 14:29:34 2026 +0200 Linux 7.1.10 Link: https://lore.kernel.org/r/[email protected] Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Ronald Warsow <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Jeffrin Jose T <[email protected]> Tested-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Fri Jul 31 11:49:49 2026 +0200 m68k: Define NR_CPUS to 1 [ Upstream commit 1fd495ef09eef96169a379a749c24b5e69974bb8 ] This fixes a Kconfig warning fs/erofs/Kconfig:137:warning: range is invalid which originates from EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS using NR_CPUS which up to now didn't exist for ARCH=m68k. All other architectures define this symbol, so fix the outlier. [geert] This also fixes: - CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS being set to the literal NR_CPUS instead of a number by automatic configs like "make allmodconfig" or "make olddefconfig", - An infinite loop in manual configs like "make oldconfig" when CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is not present or has an invalid value in your existing .config. Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Aug 6 14:19:38 2026 +0000 macvlan: inherit needed_headroom and needed_tailroom from lowerdev [ Upstream commit cef51860becd9700217c81732ca1eb1ea6ed6fe1 ] macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Reported-by: Tangxin Xie <[email protected]> Closes: https://lore.kernel.org/netdev/CANn89i+1EW-sFNK8xoq98gMbPCeLS7e=+rs9gHfLg5Wj+4x0sw@mail.gmail.com/T/#m16adf0ff972cbfd8066c3a8e656e75eaeb12d021 Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ramin Moussavi <[email protected]> Date: Mon Jul 27 23:58:23 2026 +0200 microblaze: restore the page alignment of swapper_pg_dir commit c2689266e5f70ecc960e64d40516518c038ae34e upstream. microblaze handles TLB misses in software, and the handler builds the address of the L1 entry by ORing the index into the page directory base instead of adding it (hw_exception_handler.S): bsrli r5, r3, PGDIR_SHIFT - 2 andi r5, r5, PAGE_SIZE - 4 /* Assume pgdir aligned on 4K boundary, no need for "andi r4,r4,0xfffff003" */ or r4, r4, r5 lwi r4, r4, 0 /* Get L1 entry */ The index is masked to the low 12 bits, so the OR only works if those bits of the base are zero -- which is exactly the assumption the comment states and the reason the masking of the base can be skipped. swapper_pg_dir had no alignment directive of its own. It was aligned because it followed empty_zero_page in head.S, and that one carried the .align 12: .section .data .global empty_zero_page .align 12 empty_zero_page: .space PAGE_SIZE .global swapper_pg_dir swapper_pg_dir: .space PAGE_SIZE Commit 6215d9f4470f ("arch, mm: consolidate empty_zero_page") removed empty_zero_page from head.S, and with it the .align 12 that -- despite sitting next to empty_zero_page -- was what page aligned swapper_pg_dir. Since then swapper_pg_dir lands wherever .data happens to put it, its low bits are no longer zero, and every kernel TLB miss ORs the index into a base with a nonzero offset. The resulting L1 lookups read the wrong words, no valid translation is ever installed, and the kernel spins in exceptions long before it can print anything. On qemu-system-microblazeel (petalogix-s3adsp1800) the console stays completely silent at 100% CPU; there is no oops and no guest error reported by qemu, which makes this awkward to diagnose. Give swapper_pg_dir the alignment it requires, rather than relying on a neighbour to provide it. microblaze has no noMMU variant left in mainline -- CONFIG_MMU is def_bool y and mmu_defconfig is the only defconfig -- so this is not a corner case: every mainline microblaze kernel since v7.1-rc1 fails to boot, including the v7.1 release. v7.0: swapper_pg_dir = 0xc05fd000 (aligned) v7.1-rc1: swapper_pg_dir = 0xc0603140 (offset 320) v7.1-rc1 + this fix: swapper_pg_dir = 0xc0604000 (aligned) next-20260726: swapper_pg_dir = 0xc0615140 (offset 320) next-20260726 + this fix: swapper_pg_dir = 0xc0616000 (aligned) Verified on qemu-system-microblazeel (petalogix-s3adsp1800) with mmu_defconfig and microblazeel gcc 12.5.0: v7.1-rc1 and next-20260726 both print nothing at all without the fix, and both boot to userspace with it. Link: https://lore.kernel.org/[email protected] Fixes: 6215d9f4470f ("arch, mm: consolidate empty_zero_page") Signed-off-by: Ramin Moussavi <[email protected]> Cc: Michal Simek <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pei Xiao <[email protected]> Date: Mon Aug 3 17:48:21 2026 +0800 mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition commit c125ee35a49a0518521b52b27631eef061b8719a upstream. In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove. Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers") Assisted-by: Codex:deepseek-v4-flash Signed-off-by: Pei Xiao <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Binbin Zhou <[email protected]> Date: Tue Aug 4 14:12:00 2026 +0800 mmc: loongson2: Fix sg iteration in data reorder functions commit 00179ed9fbe07799676e2cb63c4e7f0e7cd80a5c upstream. In ls2k0500_mmc_reorder_cmd_data() and ls2k2000_mmc_reorder_cmd_data(), the for_each_sg() macro already iterates over the scatterlist entries, with 'sg' pointing to the current entry. However, the code incorrectly uses '&sg[i]' and 'sg_dma_len(&sg[i])' inside the loop, which treats 'sg' as an array base and indexes it again, leading to access of wrong sg entries (or out-of-bounds if the list is not an array). Cc: [email protected] Fixes: d0f8e961deae ("mmc: loongson2: Add Loongson-2K2000 SD/SDIO/eMMC controller driver") Fixes: 2115772014bd ("mmc: loongson2: Add Loongson-2K SD/SDIO controller driver") Signed-off-by: Binbin Zhou <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhan Xusheng <[email protected]> Date: Tue Aug 4 10:25:00 2026 +0800 mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit commit f64ea900e4bda3055ef24a2c906f8d049cf1c3bd upstream. omap_hsmmc_prepare_data() converts the command busy timeout to nanoseconds with: timeout = req->cmd->busy_timeout * NSEC_PER_MSEC; busy_timeout is an unsigned int (milliseconds) and timeout is a u64, but NSEC_PER_MSEC is 1000000L. On 32-bit builds the multiplication is performed in 32-bit arithmetic and wraps for busy_timeout values above ~4294 ms, before the result is assigned to the u64. The driver does not set mmc->max_busy_timeout, so the core does not cap the busy timeout, and commands such as erase or SANITIZE (MMC_SANITIZE_TIMEOUT_MS is 240000 ms) can pass a busy_timeout far larger than 4294 ms. The wrapped, much smaller ns value is then programmed via set_data_timeout(), so the data timeout is set too short and the operation can time out prematurely. Cast busy_timeout to u64 before the multiplication so the conversion is done in 64-bit arithmetic. Fixes: 8cc9a3e73de1 ("mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6") Cc: [email protected] Signed-off-by: Zhan Xusheng <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haibo Chen <[email protected]> Date: Mon Jul 27 18:38:49 2026 +0800 mmc: sdhci: make tuning_err a signed int commit ae31bcc92bb42502bb7c9029e6dc7a824cf6cd14 upstream. Coverity report INTEGER_OVERFLOW for host->tuning_err. The tuning_err field in struct sdhci_host is used to store an error code for re-tuning, but it was declared as unsigned int. Several call sites store negative error codes into it and later compare against negative values: - sdhci.c, sdhci-of-dwcmshc.c and sdhci-pci-gli.c assign it the return value of __sdhci_execute_tuning()/__sdhci_execute_tuning_9750(), both of which return a signed int (possibly a negative errno); - sdhci-of-esdhc.c assigns host->tuning_err = -EAGAIN and later does "ret = host->tuning_err; if (ret == -EAGAIN ...)"; - sdhci-of-dwcmshc.c prints it with the %d (signed) conversion. Storing a negative errno in an unsigned int and reading it back as a signed int only happens to work because of two's-complement, same-width integer conversions. It is misleading and triggers sign-conversion warnings. All users treat the value either as a signed error code or as a boolean (zero / non-zero), so changing the type to a signed int is safe and makes the intent explicit. Fixes: 7d8bb1f46e13 ("mmc: sdhci: add tuning error codes") Assisted-by: Cline:claude-sonnet [read_file, search_files, git] Signed-off-by: Haibo Chen <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Mon Jul 27 23:03:22 2026 +0900 mmc: sdhci: unmap the bounce buffer before device release commit 9e9f561269dff35e6f84ed21776ec37fd6360b03 upstream. sdhci_allocate_bounce_buffer() allocates its buffer with devm_kmalloc() but maps it with dma_map_single(). The buffer is therefore released by devres without the streaming DMA mapping being unmapped. Register a managed action after dma_map_single() succeeds so the mapping is removed before devres releases the buffer. The action is registered only for buffers allocated and mapped by the SDHCI core, leaving buffers provided by host drivers under their existing ownership. Fixes: bd9b902798ab ("mmc: sdhci: Implement an SDHCI-specific bounce buffer") Cc: [email protected] Co-developed-by: Ijae Kim <[email protected]> Signed-off-by: Ijae Kim <[email protected]> Signed-off-by: Myeonghun Pak <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Aug 3 18:16:34 2026 +0200 mptcp: avoid combining some incoming suboptions commit b6ee361524641f57b2e2363f7737f20e17f67827 upstream. Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN. Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options") Cc: [email protected] Link: https://www.rfc-editor.org/rfc/rfc8684.html#section-3.5-5.1 [1] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wyatt Feng <[email protected]> Date: Mon Aug 3 18:16:39 2026 +0200 mptcp: fastopen: only mark MPTFO subflows with SYN data commit e00b63056fb4f261455b3e5df5268a1f8ce47a87 upstream. Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO". Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Zhengchuan Liang <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Wyatt Feng <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-7-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Aug 3 18:16:33 2026 +0200 mptcp: options: reset DSS fields in case of unexpected size commit 35772b4981f38ba8059372cde8753e8e477e98ec upstream. A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size. Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d%40kernel.org?part=1 Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: [email protected] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-1-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qing Luo <[email protected]> Date: Mon Aug 3 18:16:36 2026 +0200 mptcp: pm: fix data race in add_addr timer callback commit a7aad5b69d3bdaec20a3ed9284e184502450c0cd upstream. The timer callback reads entry->retrans_times outside pm.lock to decide whether to call mptcp_pm_subflow_established(). Since mptcp_pm_announced_del_timer() can concurrently set retrans_times = ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists. I discovered this issue while studying the code. AI tools helped me to verify the issue can potentially happen under race conditions. Use a local 'retransmit' flag set inside pm.lock to capture whether retransmission is still possible when the lock is taken. This allows to call mptcp_pm_subflow_established() accordingly, and not depending on the situation that can be different when checked outside the pm.lock. Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout") Cc: [email protected] Signed-off-by: Qing Luo <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Mon Aug 3 18:16:40 2026 +0200 mptcp: reclaim forward-allocated memory on RX path errors commit 41b49a8b914ec7dcb03eae93fb27f3c464078644 upstream. After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped. Fixes: 9db5b3cec4ec ("mptcp: borrow forward memory from subflow") Cc: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-8-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jamal Hadi Salim <[email protected]> Date: Sun Aug 9 05:09:28 2026 -0400 net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain [ Upstream commit f60b396ee174206fe08ebf997d16cd3801b77b22 ] tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value. Fixes: ee3bbfe806cd ("net/sched: let actions use RCU to access 'goto_chain'") Reported-by: [email protected] Tested-by: Victor Nogueira <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Reviewed-by: Davide Caratti <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jamal Hadi Salim <[email protected]> Date: Sun Aug 9 05:44:18 2026 -0400 net/sched: cls_bpf: reject dev-bound programs bound to a different device [ Upstream commit 120977e2c096deea4e866e4273be9220b957c29e ] cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: [email protected] Tested-by: Victor Nogueira <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Changzhong <[email protected]> Date: Fri Aug 7 15:50:38 2026 +0800 net/sched: cls_u32: skip hash tables in u32_bind_class() [ Upstream commit 6d3724e616faf952c3adcf8414fc21a828ef3709 ] u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check. Fixes: 07d79fc7d94e ("net_sched: add reverse binding for tc class") Signed-off-by: Zhang Changzhong <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Thu Aug 6 20:44:07 2026 -0400 net/tls: Fail tls_sw_splice_read() after a failed async decrypt [ Upstream commit 976df67f463db1fddaf2a32fb04f57ad2891a23d ] When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do. Fixes: f314bfee81b1 ("tls: rx: return the already-copied data on crypto error") Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Siddharth Vadapalli <[email protected]> Date: Fri Aug 7 16:47:37 2026 +0530 net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG [ Upstream commit 36a05d2820077bb3955acb8111e1041d39148037 ] On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Siddharth Vadapalli <[email protected]> Reviewed-by: Chintan Vankar <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Wed Aug 19 19:09:25 2026 -0400 net: expect instance lock in netdev_queue_get_dma_dev() [ Upstream commit 92465f46f3c3a92e4758af20d2363b7adc43e1f5 ] netdev_queue_get_dma_dev() uses "compat" locking assert which wants either the rtnl_lock or netdev instance lock. This is not right, the callers are taking the instance lock unconditionally. All entry points for queue config are purely instance locked. In other words the callers use netdev_get_by_index_lock(), not netdev_get_by_index_lock_ops_compat(). All the state we will access is effectively instance lock protected (it's const for devices which are not ops-locked). Update the assert to avoid false positive warnings. Cc: [email protected] Fixes: b6c5f9454ef34 ("io_uring/zcrx: call netdev_queue_get_dma_dev() under instance lock") Reported-by: [email protected] Reviewed-by: Simon Horman <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiawen Wu <[email protected]> Date: Fri Aug 7 14:22:14 2026 +0800 net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling [ Upstream commit 5f3a13e0bb5ebcc1ca2dfda42ea40b9f3c2be6ea ] In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences wx->msix_entry->entry, leading to a NULL pointer dereference crash. This issue was introduced by fixing the IRQ vector when the number of VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to determine the correct vector index. Additionally, as a side fix, set the interrupt mask to BIT(0) for the non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts share vector 0, and the WX_PX_MISC_IVAR register is only valid in the MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause when MSI-X is disabled. Fixes: 4174c0c331a2 ("net: ngbe: specify IRQ vector when the number of VFs is 7") Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wei Fang <[email protected]> Date: Fri Aug 7 14:34:04 2026 +0800 net: packet: fix wrong transport_header when sending VLAN-tagged frame [ Upstream commit 01fdecc0480d916c799dbee584833a4a37e94d06 ] In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to the outer VLAN EtherType (e.g. ETH_P_8021Q), while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly. Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO") Assisted-by: WChat:claude-opus-4-8 Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksij Rempel <[email protected]> Date: Thu Aug 6 15:47:16 2026 +0200 net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path [ Upstream commit 202fef9bbbf5784487eec27581389c6fb97c350d ] In rtlgen_write_mmd(), the MDIO_AN_EEE_ADV case swaps the arguments to rtlgen_write_vend2(): it passes the MMD register number as the OCP address and the OCP address constant as the value. The caller's value is discarded and the write lands on the wrong register, so the EEE advertisement cannot be configured on the affected PHYs. Mirror rtlgen_read_mmd() and write the value to RTL_MDIO_AN_EEE_ADV. Fixes: da681ed73fb9 ("net: phy: realtek: improve mmd register access for internal PHY's") Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Nicolai Buchwitz <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Wed Aug 19 19:09:24 2026 -0400 net: rename netdev_ops_assert_locked() [ Upstream commit 251bc9db88fb351ea2dfbd976c4e6aaae6507a91 ] Jakub suggests renaming the existing assert to match the netdev_lock_ops_compat() semantics. We want netdev_assert_locked_ops() to mean - if the driver is ops locked - check that it's holding the device lock. The existing helper check for either ops lock or rtnl_lock, which is the locking behavior of netdev_lock_ops_compat(). The reason for naming divergence is likely that netdev_ops_assert_locked() predated the _compat() helpers. Suggested-by: Jakub Sitnicki <[email protected]> Reviewed-by: Nicolai Buchwitz <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 92465f46f3c3 ("net: expect instance lock in netdev_queue_get_dma_dev()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wei Fang <[email protected]> Date: Fri Aug 7 14:34:05 2026 +0800 net: tap: fix wrong transport_header when sending VLAN-tagged frame [ Upstream commit cbb35cbe8db268fefe34c23df15348cf99025298 ] In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g. ETH_P_8021Q), skb_set_network_header() is called first to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to ETH_P_8021Q, while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_set_network_header() to after skb_probe_transport_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the flow dissector can parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly. Fixes: 8c76e77f9069 ("tap: call skb_probe_transport_header after setting skb->dev") Assisted-by: WChat:claude-opus-4-8 Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jérémy Jean <[email protected]> Date: Sat Aug 8 12:40:02 2026 +0000 netfilter: flowtable: publish GC-visible tuple last [ Upstream commit 2014ac62df9d45bb9a004a043e85df7be09ed780 ] nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.). Fixes: ac2a66665e23 ("netfilter: add generic flow table infrastructure") Signed-off-by: Jérémy Jean <[email protected]> Assisted-by: Codex:gpt-5 Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Aug 6 15:53:41 2026 +0200 netfilter: ipset: fix list type element drift bug [ Upstream commit 4cbd69766b35a089664cadb1f613bb85f7ef77a9 ] If list_set_uadd() calls list_set_replace() to swap an expired entry, the element count remains the same, therefore the increment must be elided. Fixes: 702b71e7c666 ("netfilter: ipset: Add element count to all set types header") Link: https://sashiko.dev/#/patchset/20260806101947.2802-1-fw%40strlen.de Signed-off-by: Florian Westphal <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Wed Jul 22 22:38:32 2026 +0000 netfilter: ipset: fix refcount race between list:set GC and swap [ Upstream commit 0c88868271653537ed443272dd8e7d13634d214b ] __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: <IRQ> list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) </IRQ> Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9076aea76538 ("netfilter: ipset: Increase the number of maximal sets automatically") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Aug 6 16:17:50 2026 +0200 netfilter: ipset: let destroy callbacks adjust ext mem size [ Upstream commit 490937b88cb592cc0c5367758edd700fd5abd15c ] For bitmap this change makes no difference, because destructors are called synchronously. List type however calls them via call_rcu() so accounting decrement can happen after list_set_flush() set ext_size to 0. 'set->elements = 0' can be removed for the same reason in the list type case, it calls 'set->elements--' for each element. Fixes: 9e41f26a505c ("netfilter: ipset: Count non-static extension memory for userspace") Suggested-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Velichayshiy <[email protected]> Date: Thu Aug 6 19:11:38 2026 +0300 netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path [ Upstream commit d02f592064347e0c1e0d84f24941ad338838cc48 ] In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug. Trace for example: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nf_tables transaction processing: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Change the condition to WARN_ON_ONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 63b48c73ff56 ("netfilter: nf_tables_offload: undo updates if transaction fails") Signed-off-by: Alexey Velichayshiy <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ali Ahmet Memis <[email protected]> Date: Fri Aug 7 23:42:30 2026 +0000 openrisc: signal: do not restore privileged SR bits on sigreturn commit 32ef1b30ad736519f7a207bcc2986f3d4129d972 upstream. restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged. Fixes: ac689eb7f9d4 ("OpenRISC: Signal handling") Cc: [email protected] Signed-off-by: Ali Ahmet Memis <[email protected]> Signed-off-by: Stafford Horne <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mostafa Saleh <[email protected]> Date: Wed Jun 17 14:51:24 2026 +0000 optee: ffa: Add NULL check in optee_ffa_lend_protmem [ Upstream commit 650c88738ae8976f46ba71b24dd8aa311adc6fde ] Sashiko (locally) reports a possible null dereference under memory pressure due to the lack of validation of the allocated pointer. Fix that by adding the missing check. Fixes: 2b78d79cdf96 ("optee: FF-A: dynamic protected memory allocation") Signed-off-by: Mostafa Saleh <[email protected]> Signed-off-by: Sebastian Ene <[email protected]> Reviewed-by: Sumit Garg <[email protected]> Reviewed-by: Sebastian Ene <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ralf Lici <[email protected]> Date: Wed Jul 29 12:21:46 2026 +0200 ovpn: defer key slot crypto freeing to workqueue [ Upstream commit 2da3dfa1ddfe55a065f484750c83660e3bd4ac00 ] Key slots are released through a kref and the existing release path frees the AEAD transforms from an RCU callback. That is not safe for all crypto implementations: crypto_free_aead can sleep, for example when an async or hardware implementation has teardown work to complete. Use queue_rcu_work for key-slot release. This keeps the RCU grace period needed by lockless key-slot readers, but runs the actual crypto teardown from workqueue context where sleeping is allowed. Once the rcu_work callback runs, pre-existing RCU readers are gone, and the final kref put already proves that no transform user remains, so the worker can release the AEAD transforms and free the slot directly. The previous patch drains ovpn_wq during module exit, so queued key-slot teardown work cannot outlive module text. Fixes: 8534731dbf2d ("ovpn: implement packet processing") Signed-off-by: Ralf Lici <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ralf Lici <[email protected]> Date: Wed Jul 29 12:21:44 2026 +0200 ovpn: finish crypto callback cleanup before peer release [ Upstream commit 9e163917a86c6adfbe150e13f4c73653a54616de ] Crypto completion callbacks hold both key-slot and peer references. The peer reference pins the netdev, and dropping the last peer reference can let netdev unregistration and module removal make progress. Do not release that peer reference before the callback has finished its own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can schedule an RCU callback backed by module text after ovpn_cleanup rcu_barrier has already run. The TX error path also freed the remaining skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev lifetime window. Release the key slot and free any remaining skb first, then drop the peer reference as the last callback action. Fixes: 8534731dbf2d ("ovpn: implement packet processing") Signed-off-by: Ralf Lici <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ralf Lici <[email protected]> Date: Wed Jul 29 12:21:41 2026 +0200 ovpn: fix NULL dereference when killing missing key [ Upstream commit 41d44ac7a61e2f74453af40d4fe1b82af9ea0ada ] ovpn_crypto_kill_key assumes both crypto slots are populated and dereferences each slot before checking it. That is not guaranteed: a peer can have only one installed key, and the kill path may be asked to remove a key that is not present. Read each slot once while holding the crypto state lock, check for NULL before looking at key_id, and only replace the slot that actually matches. Fixes: 89d3c0e4612a ("ovpn: kill key and notify userspace in case of IV exhaustion") Signed-off-by: Ralf Lici <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ralf Lici <[email protected]> Date: Fri Aug 7 09:55:43 2026 +0200 ovpn: run deferred work on a module-owned workqueue [ Upstream commit e9714db8041763f59dde152c812b96b3de05c6d9 ] ovpn queues several work items whose callbacks execute module text. These works currently run on the global system workqueues, so module exit has no driver-owned drain point that guarantees the callbacks have fully returned before the module text can be freed. Object references protect the objects used by the callbacks, but they do not prove that a workqueue function has returned. In particular, a worker can drop the final reference that unblocks device teardown while it is still executing ovpn code. Add a module-owned workqueue and queue all ovpn work items on it. During module exit, unregister rtnl and netlink first, flush the workqueue so ordinary ovpn workers finish, run the final RCU barrier, and destroy the workqueue last. This keeps the workqueue available for cleanup work queued from RCU callbacks, while ensuring no ovpn work item can outlive the module text. The per-device delayed keepalive work remains explicitly disabled during netdev teardown (disable_delayed_work_sync in ndo_uninit), since flush_workqueue does not flush delayed work that is still only pending on its timer. Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Thu Aug 6 13:56:55 2026 -0700 perf: Reject exited events as group leaders [ Upstream commit fa091f46c3833fb22384f10eade2b4e1e1d0b278 ] perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent] Fixes: 037a3c43edfb ("perf/core: Detach event groups during remove_on_exec") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jérémy Jean <[email protected]> Date: Tue Aug 11 19:10:11 2026 +0000 pid: reject allocations through dead ancestor pid namespaces [ Upstream commit b64a9f67e082e04835ddd69d422a25168d69375b ] alloc_pid() checks PIDNS_ADDING only on the leaf pid namespace before making a new struct pid visible in every ancestor namespace. That is insufficient when an unborn descendant pid namespace outlives an ancestor whose init task has already exited. The descendant can still be initialized later through setns(), and the new pid is then published into the dead ancestor as well. Keep the existing ENOMEM behavior, but require PIDNS_ADDING to be set in every namespace that will receive the new pid before publishing any of them. This preserves the invariant that free_pid() never decrements pid_allocated in a namespace whose child_reaper is no longer live. Fixes: a3bdc23ba8ea ("pid_namespace: allow opening pid_for_children before init was created") Signed-off-by: Jérémy Jean <[email protected]> Reviewed-by: Pavel Tikhomirov <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Praveen Talari <[email protected]> Date: Wed Aug 5 01:27:39 2026 +0530 pmdomain: arm: Fix -EINVAL from scmi_pd_set_perf_state() on state 0 commit 3314c90a2eda3df7da4ab6f4388e667b2758de7f upstream. Currently, scmi_pd_set_perf_state() treats a performance state of 0 as invalid and returns -EINVAL. As a result, devices attached to SCMI performance domains can report failures when relinquishing their performance vote. The OPP framework use performance state 0 to indicate that no performance vote is required. For example, dev_pm_opp_set_rate(dev, 0) is commonly used (by firmware or linux) when a device is runtime suspended. A zero performance state does not require any SCMI performance request to be sent. Treat it as a no-op and return success instead of reporting an error. Signed-off-by: Praveen Talari <[email protected]> Fixes: 2af23ceb8624 ("pmdomain: arm: Add the SCMI performance domain") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Osipenko <[email protected]> Date: Wed Jul 29 15:59:07 2026 +0300 pmdomain: mediatek: Fix mt8183 hang on boot commit 818d56ac1d08b68a4c42d0326786f030cc640722 upstream. Depending on firmware, part of the MFG domains may be partially left ON at boot time with kernel detecting PD as ON, while it's OFF. Some of MFG cores may be left powered after bootloader, to let the ACP to prefetch the GPU region when the display controller is brought up for a continuous splash animation performed by downstream stack. This doesn't play well with an eventual delay in probing upstream Panfrost driver when the display controller is fully set up, as that would make genpd's sync_state() to power off the domain while ACP tries to prefetch: this is causing an AXI stall, effectively freezing the AP indefinitely. In order to prevent trouble from happening, the sync_state() functionality must be obliterated on all of the MFG domains: while this guarantees a power leakage if the bootloader boots the kernel with MFG PDs partially powered on, this is the only way to ensure stable operation of the SoC during boot on devices with such firmware because, of course, those will never officially receive a firmware update. Fixes Kappa Chromebook hanging during system boot. Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync") Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Jul 8 17:20:38 2026 +0800 pmdomain: mediatek: fix remaining %pOF after of_node_put() commit 3e013bc8b941bd52c8e3a99798d0ae8792cb71ca upstream. scpsys_get_bus_protection_legacy() looks up several legacy bus protection regmaps from device-tree nodes. Two error paths put the device node before checking whether the regmap lookup failed, but still pass that node to dev_err_probe() with %pOF on failure. If of_node_put() drops the last reference, the later %pOF formatting can dereference a freed device node. Keep the node reference until after the error message has been emitted in the infracfg and SMI lookup paths. Also drop the SMI node before returning when the SMI phandle is missing. Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval") Signed-off-by: Guangshuo Li <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Karl Mehltretter <[email protected]> Date: Sat Aug 8 17:05:06 2026 +0200 pmdomain: mediatek: mfg: initialize prev_o in mtk_mfg_attach_dev() commit 090a95dbe13df9965279b588d97eda134831769c upstream. mtk_mfg_attach_dev() reads prev_o on the first iteration of its loop, in "if (prev_o && prev_o->freq == o->freq)", before prev_o is assigned at the end of the loop body. On that first iteration, evaluating prev_o reads an indeterminate value. If it is non-NULL, the condition dereferences a stale or invalid pointer, potentially faulting or incorrectly skipping the first OPP. Initialize prev_o to NULL. This matches the intent as well: there is no previous OPP to compare against on the first iteration. Found with Clang's -Wconditional-uninitialized. Fixes: f08e7a4e8d6ac ("pmdomain: mediatek: Add support for MFlexGraphics") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <[email protected]> Reviewed-by: Nicolas Frattaroli <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Abel Vesa <[email protected]> Date: Mon Aug 10 14:10:38 2026 +0300 pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza commit b48a0a0a76ccecec60f0568e2af4d89994b08bec upstream. MXC and MMCX were initially omitted as they were believed to have no consumers, and they were not present downstream either. The Iris video codec requires these power domains, so add MXC and MMCX along with the MXC_AO and MMCX_AO. Fixes: f387ecdd492f ("pmdomain: qcom: rpmhpd: Add Eliza RPMh Power Domains") Signed-off-by: Abel Vesa <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Jul 16 13:42:47 2026 +0200 pmdomains: mediatek: Avoid setting RTFF's CLK_DIS before NRESTORE commit cbb0140379de69fa46526672f3003f128f0b4e2e upstream. For the PCIE_PHY (also called PEXTP_PHY) type of RTFF hardware, there is special handling setting CLK_DIS before performing the NRESTORE sequence for resetting the RTFF and start sequencing from a clean state. That special handling, though, poses an issue in case the machine specific bootchain (bootloader in particular) ends up booting the kernel with both PCIe MAC and PHY enabled (not just power domains) as doing so will partially corrupt the PCIe MAC/PHY registers in an unpredictable manner, producing either an initialization fail in the PCI-Express drivers, or even a hard lockup! Resolve this by simply removing the special handling: in this case the bootchain, or remote processors, setting is getting honored by the later check for PWR_RTFF_SAVE_FLAG presence in the RTFF ctl register. Fixes: 9d02c94342b3 ("pmdomain: mediatek: Add support for RTFF Hardware in MT8196/MT6991") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: George Wilson <[email protected]> Date: Fri Aug 7 11:59:00 2026 -0500 powerpc/pseries: lparcfg - fix kbuf[] underflow commit fb442a6673ff1046bf67754957d95880fdb394b5 upstream. In lparcfg_write(), a count of 0 results in kbuf[] being indexed at -1. Check for count == 0 in the existing check for count > sizeof(kbuf) and return -EINVAL if true. Fixes: 74422e2b1939 ("powerpc/pseries: Remove VLA from lparcfg_write()") Acked-by: Nayna Jain <[email protected]> Tested-by: R Nageswara Sastry <[email protected]> Cc: [email protected] # 4.20 Signed-off-by: George Wilson <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: George Wilson <[email protected]> Date: Fri Aug 7 11:56:21 2026 -0500 powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak commit 5b17f3f34391372faf03e79d947e0c50ab6dd258 upstream. In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd. Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for physical-attestation RTAS") Acked-by: Haren Myneni <[email protected]> Acked-by: Nayna Jain <[email protected]> Tested-by: R Nageswara Sastry <[email protected]> Cc: [email protected] # 6.16 Signed-off-by: George Wilson <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: George Wilson <[email protected]> Date: Fri Aug 7 11:58:36 2026 -0500 powerpc/pseries: pci - logic bug commit 649c10bff5cb7a514bf299094833ec8c9190aac3 upstream. The checks on num_vfs in pseries_pci_sriov_enable() are ANDed where OR was apparently intended. Change it to OR. Fixes: 9a7f6b438664 ("powerpc/pseries/pci: Associate PEs to VFs in configure SR-IOV") Acked-by: Nayna Jain <[email protected]> Tested-by: R Nageswara Sastry <[email protected]> Cc: [email protected] # 4.16 Signed-off-by: George Wilson <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrey Golovko <[email protected]> Date: Tue Aug 11 22:14:35 2026 +0300 regmap: sdw-mbq: don't call an unset readable_reg callback [ Upstream commit 00268f9452d2a0d660aa9c1bb0ca07a994af6a4f ] regmap_sdw_mbq_poll_busy() decides whether to poll the Function Busy bit by calling ctx->readable_reg(), which is a straight copy of config->readable_reg. That callback is optional: regmap_readable() treats a NULL ->readable_reg as "every register is readable", and drivers rely on that. es9356 and tac5xx2-sdw both build an MBQ regmap without one. Since commit ca1b11b36d82 ("regmap: sdw-mbq: Allow defers on undeferrable controls") the poll runs on every -ENODATA, not only for Controls the driver marked deferrable, so any of those devices answering COMMAND_IGNORED takes the kernel through a NULL function pointer. Treat a missing callback the way the rest of regmap does and poll. Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Andrey Golovko <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Keepax <[email protected]> Date: Tue Aug 11 14:18:16 2026 +0100 regmap: sdw-mbq: Fix swap of timeout and retry times [ Upstream commit ae7fd6ff4c6713270d2efe6db87a4a58ccb7cc61 ] When polling Function Busy using read_poll_timeout() the total timeout and retry delay arguments are swapped. This leads to only a single retry being processed, it seems the existing users typically do succeed before the first retry. Swap the arguments over to ensure the correct polling time. Reported-by: Ville Saarinen <[email protected]> Link: https://lore.kernel.org/linux-sound/[email protected]/T/#m680731a2f307f1f5176b27ed5aa560ddc94e5d62 Fixes: 5bc493bf0c37 ("regmap: sdw-mbq: Add support for SDCA deferred controls") Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robby Cai <[email protected]> Date: Fri Jul 24 18:34:40 2026 +0800 regulator: fp9931: Fix VPOS/VNEG voltage selector table [ Upstream commit 66694b5f90f3876fccb87bbd02b453cdc33b3ae4 ] The VPOSNEG_table[] mapping does not match the FP9931 datasheet. The datasheet defines the VPOS/VNEG voltage mapping as: 00h-04h -> 7.04V (-7.04V) 05h -> 7.26V (-7.26V) 06h -> 7.49V (-7.49V) ... 28h-3Fh -> 15.06V (-15.06V) However, VPOSNEG_table[] has two issues: 1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the table has 6 entries of 7.04V, causing all subsequent entries to be shifted by one position. 2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but the table has only 41 entries. Any selector value above 0x28 would result in an out-of-bounds table access. Fix both issues by removing the duplicate 7.04V entry and appending the missing 23 clamped 15.06V entries, bringing the table to the correct size of 64 entries (0x00~0x3F). Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver") Signed-off-by: Robby Cai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Wed Jul 22 12:27:48 2026 +0200 rhashtable: fix false-positive lockdep splat on rhltable destruction [ Upstream commit 1132c38927886259c694f77cd74fc577c2216eeb ] Blamed commit removed ht->mutex usage during destruction but forgot to switch rhashtable_free_one() to rcu_dereference_raw(), this triggers a lockdep splat when an rhltable gets zapped. Fixes: 09ae540e1d5c ("rhashtable: drop ht->mutex in rhashtable_free_and_destroy()") Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Mikhail Gavrilov <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pu Lehui <[email protected]> Date: Sun Aug 2 09:49:29 2026 +0000 riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions [ Upstream commit 2820d227ad4ee70805d693d698437cc3e88d6c3d ] We are frequently hitting the following splat during the riscv bpf selftests: 00000000026dc75a: expected (7c3ff297) but got (00100073) ------------[ ftrace bug ]------------ ftrace failed to modify [<ffffffff03c44c1c>] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod] actual: e7:82:c2:ce Updating ftrace call site to call a different ftrace function ftrace record flags: 80100002 (2) expected tramp: ffffffff80043904 ------------[ cut here ]------------ WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98 ... [<ffffffff80008f4e>] ftrace_bug+0x46e/0x4b0 [<ffffffff803d3e86>] ftrace_replace_code+0x16e/0x170 [<ffffffff803d42b6>] ftrace_modify_all_code+0x12e/0x1b8 [<ffffffff800430f4>] arch_ftrace_update_code+0x14/0x28 [<ffffffff803e0324>] ftrace_startup+0x14c/0x2a0 [<ffffffff803e133c>] ftrace_startup_subops+0x584/0x1050 [<ffffffff804500e6>] register_ftrace_graph+0x4e6/0x1018 [<ffffffff804cf9f6>] register_fprobe_ips+0xc66/0x12f8 [<ffffffff8049abe8>] bpf_kprobe_multi_link_attach+0x5d8/0xe68 [<ffffffff8050fcaa>] __sys_bpf+0x3d5a/0x47f0 [<ffffffff805107ee>] __riscv_sys_bpf+0xae/0x168 [<ffffffff80034d78>] syscall_handler+0x60/0x100 [<ffffffff8228b4f4>] do_trap_ecall_u+0x174/0x208 [<ffffffff822b69c4>] handle_exception+0x16c/0x178 After debugging, it can be triggered by similar commands below: ``` echo do_nanosleep > set_ftrace_filter echo function > current_tracer echo 'p do_nanosleep' > kprobe_events echo 1 > events/kprobes/enable echo 'f do_nanosleep' > dynamic_events echo 1 > events/fprobes/enable ``` The reason is that attaching a kprobe to an ftrace-traced function entry replaces its initial auipc insn with ebreak. When ftrace_modify_call later runs, it expects auipc insn, so verification fails and triggers ftrace_bug. The expected auipc logic remains conceptually unchanged, and kprobe single-stepping ensures normal execution. Therefore, if the first insn is ebreak, bypassing the check to continue patching the jalr insn is safe and avoids ftrace failures. Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Signed-off-by: Pu Lehui <[email protected]> Link: https://patch.msgid.link/[email protected] [[email protected]: fixed reproducer in commit message] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rui Qi <[email protected]> Date: Tue Jul 21 23:05:09 2026 +0800 riscv: hwprobe: Register unaligned probes before usermode commit 994dad686e755477e2b2700cca4e6e1a90a58bdc upstream. The hwprobe vDSO data is populated by the first riscv_hwprobe syscall. Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async vector unaligned access speed probe registered by check_unaligned_access_all_cpus(). That initcall currently runs at late_initcall level. However, rootfs_initcall enables usermode helpers before late initcalls run, so an early helper can execute userspace and call riscv_hwprobe first. In that case complete_hwprobe_vdso_data() consumes the initial pending_boot_probes reference, populates the vDSO cache, and marks it ready before the later async probe is registered. The eventual probe result then cannot update the already-ready cache. Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns() benchmark uses a stable clocksource, but it runs before rootfs_initcall enables usermode helpers. Any async hwprobe probe is therefore registered before userspace can trigger the one-time vDSO cache population. Cc: [email protected] Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe") Signed-off-by: Rui Qi <[email protected]> Reviewed-by: Nam Cao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Neuling <[email protected]> Date: Mon Apr 13 01:07:38 2026 +0000 riscv: lib: Fix ZBB strnlen reading past count boundary [ Upstream commit 5d588c684833e678a0008eb69c33190f01a65f4b ] The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary: REG_L t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults. Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit. Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results. The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word. Fixes: 5ba15d419fab ("riscv: lib: add strnlen() implementation") Signed-off-by: Michael Neuling <[email protected]> Assisted-by: Claude Opus4.6 High Thinking Link: https://patch.msgid.link/[email protected] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niels Pressel <[email protected]> Date: Sun Aug 2 14:44:23 2026 +0200 rseq: Prevent hard lockup on granted time slice extension [ Upstream commit ada54c2ba652348c590d1ace6a2f4ff77cbbf809 ] __exit_to_user_mode_loop() invokes rseq_grant_timeslice_extension() with interrupts enabled. If the extension is granted it invokes hrtimer_rearm_deferred_tif() to ensure that a pending deferred hrtimer rearm is handled before exiting to user space. Though this invokes __hrtimer_rearm_deferred() which expects to be invoked with interrupts disabled as it takes hrtimer_cpu_base::lock with raw_spin_lock(). That's a livelock waiting to happen and caught by lockdep: WARNING: ./include/linux/hrtimer_rearm.h:17 at irqentry_exit, CPU#1: slice_test WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. Prevent this by disabling interrupts around the invocation of hrtimer_rearm_deferred_tif() in rseq_grant_timeslice_extension(). [ tglx: Massaged change log ] Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path") Signed-off-by: Niels Pressel <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hidayath Khan <[email protected]> Date: Thu Jul 30 16:22:16 2026 +0200 s390/qeth: validate user buffer length in SNMP and ARP query ioctls commit d141f087b1af656f055d7c5793a3e87817ba0bbe upstream. qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow. Fixes: 4a71df50047f ("qeth: new qeth device driver") Cc: [email protected] Reviewed-by: Alexandra Winter <[email protected]> Signed-off-by: Hidayath Khan <[email protected]> Reviewed-by: Joe Damato <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:17 2026 +0200 s390/vfio_ccw: Calculate idal length based on idaw type commit 4f6fdc6e1a7fbfa36b945af33c65a417948feac0 upstream. Sashiko pointed out that get_guest_idal() unconditionally calculates the length of the IDAL presuming everything is a Format-2 IDAW. The output of vfio-ccw is always Format-2, but the input can be either Format-1 (31-bit addresses) or Format-2 (64-bit addresses). As a result, the size of the guest IDAL may be incorrect and should be trimmed down. Reported-by: sashiko-bot <[email protected]> Link: https://lore.kernel.org/r/[email protected]/ Fixes: 1b676fe3d9d3 ("vfio/ccw: handle a guest Format-1 IDAL") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:19 2026 +0200 s390/vfio_ccw: Cancel existing workqueues commit 79c60b2c61105368dcc8444eb45847e21734f7c4 upstream. The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd. Suggested-by: Matthew Rosato <[email protected]> Fixes: e5f84dbaea59 ("vfio: ccw: return I/O results asynchronously") Fixes: 3f02cb2fd9d2 ("vfio-ccw: Wire up the CRW irq and CRW region") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:16 2026 +0200 s390/vfio_ccw: Ensure first IDAW remains constant commit 565bef268d75bf7df665bce6923a88cd0eb74592 upstream. The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with. Fixes: 01aa26c672c0 ("s390/cio: Combine direct and indirect CCW paths") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:18 2026 +0200 s390/vfio_ccw: Ensure index for read/write regions are within range commit 9f5f9a78fedc45bc29d6a0a64e3a3472361afae5 upstream. The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced. Fixes: db8e5d17ac03 ("vfio-ccw: add capabilities chain") Cc: [email protected] Cc: Cornelia Huck <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:15 2026 +0200 s390/vfio_ccw: Fix out of bounds check on CCW array commit a005b7f1a491ffda61bff0fd0f6548f8986fb977 upstream. The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is "do..while (count < 257)", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:13 2026 +0200 s390/vfio_ccw: Free all memory if cp_init() fails commit 74186c2968f8f756ac3226b545b598457c910c75 upstream. The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic. Fixes: 8b515be512a2 ("vfio-ccw: Fix memory leak and don't call cp_free in cp_init") Cc: [email protected] Reviewed-by: Farhan Ali <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:22 2026 +0200 s390/vfio_ccw: Implement a crw lock commit 16b0798024c0e9117e395829ddbbe70981c79d9c upstream. Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively. Fixes: 3f02cb2fd9d2 ("vfio-ccw: Wire up the CRW irq and CRW region") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Reviewed-by: Farhan Ali <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:14 2026 +0200 s390/vfio_ccw: Limit the number of channel program segments commit 5405c90d6a47b3014e74ee0618a162449abbbc93 upstream. The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive. Fixes: 0a19e61e6d4c ("vfio: ccw: introduce channel program interfaces") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Eric Farman <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:20 2026 +0200 s390/vfio_ccw: Move cp cleanup out of not operational commit 0c11f61a876ed6fcca53d442ed3f33ea8362a0f9 upstream. The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements. Fixes: 204b394a23ad ("vfio/ccw: Move FSM open/close to MDEV open/close") Cc: [email protected] Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Farman <[email protected]> Date: Tue Jul 28 05:30:21 2026 +0200 s390/vfio_ccw: Selectively expand io_mutex commit 34f4feff3e90bd09308fad0974e97113b23b812a upstream. The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself. Fixes: 4f76617378ee ("vfio-ccw: protect the I/O region") Cc: [email protected] Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Mon Aug 3 10:33:34 2026 +0200 s390/zcrypt: Fix CPRB memory allocation in zcrypt misc code commit 5004889551dfaf7f4b2cda8ed213d234bb8ebf82 upstream. Both CPRB alloc functions in zcrypt_ccamisc.c and zcrypt_ep11misc.c did not round up the memory allocation to a multiple of 4 bytes as it is needed by the zcrypt layer to process the CPRBs. Now the alloc_and_prep_cprbmem() and alloc_cprbmem() functions guarantee that the base CPRB struct and a possible parameter block are aligned to a 4-byte boundary and the backing memory allocation is rounded up to the next multiple of 4 byte. Also the free_cprbmem() is updated and scrubs the rounded up amount of memory. Fixes: 9bdb5f7e8369 ("s390/zcrypt: Introduce cprb mempool for cca misc functions") Signed-off-by: Harald Freudenberger <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Cc: [email protected] # 6.16+ Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Mon Aug 3 10:33:35 2026 +0200 s390/zcrypt: Improve CCA CPRB length and overflow checks commit 35ac6754ba6da45fd193f5ce3f665f7490b830d5 upstream. The xcrb_msg_to_type6cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Integer overflow after CEIL4 alignment: Signed int variables could overflow during 4-byte boundary alignment, causing undersized buffer allocations or incorrect bounds checking. 2. Missing minimum size validation: The CPRBX structure is copied from userspace without verifying sufficient buffer length. Undersized buffers cause uninitialized memory access when reading structure fields like cprbx.cprb_len and cprbx.domain. 3. Arithmetic overflow in sum calculations: Adding control block and data block sizes could overflow, bypassing size checks and enabling buffer overflows. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, validating minimum control block size before copying from userspace, and detecting sum calculation overflows. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Cc: [email protected] # 7.1+ Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Mon Aug 3 10:33:37 2026 +0200 s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing commit 0864a163783bff109b548266921829ea794edc93 upstream. The zcrypt_msgtype6_send_ep11_cprb() function uses fragile struct overlays to access and modify the domain field in the EP11 CPRB payload, creating maintainability and security concerns: 1. Struct overlay approach (pld_hdr) assumes fixed payload structure and doesn't validate the actual ASN.1 encoding. 2. Complex length format detection logic is error-prone and doesn't properly validate bounds at each parsing step. 3. Direct struct member access bypasses proper ASN.1 validation. Fix by replacing struct overlays with explicit ASN.1 parsing that validates each field (payload tag/length, function tag/length/value, optional domain tag/length/value) with proper bounds checking at every step. Add asn1_int_encode() helper function to safely write integer values with correct endianness conversion. This makes the code consistent with the validation pattern introduced with the rework of the xcrb_msg_to_type6_ep11cprb_msgx() function. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <[email protected]> Cc: [email protected] # 7.1+ Reviewed-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Mon Aug 3 10:33:36 2026 +0200 s390/zcrypt: Improve EP11 CPRB length and overflow checks commit 17ac0bc866fc624cd05f022dcd8b730c0af11bb1 upstream. The xcrb_msg_to_type6_ep11cprb_msgx() function lacks proper input validation, creating security vulnerabilities: 1. Missing minimum size validation: The ep11_cprb structure and subsequent payload fields (pld_tag, pld_lenfmt) are copied from userspace without verifying sufficient buffer length. 2. Arithmetic overflow in length calculations: CEIL4 alignment could overflow, bypassing size checks and enabling buffer overflows. 3. The payload is asn1 encoded but the function just uses a simple c struct overlay to access some fields of the payload. Fix by using size_t for length calculations, adding U32_MAX boundary checks after alignment, and validating minimum request size and minimum reply size before copying from userspace. Do a very simple asn1 parsing of the payload up to the function value field. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <[email protected]> Cc: [email protected] # 7.1+ Reviewed-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harald Freudenberger <[email protected]> Date: Mon Aug 3 10:33:38 2026 +0200 s390/zcrypt: Pad trailing CCA or EP11 message with zeros commit eb363254472493e3458156fc11fd56dca92f4333 upstream. The both functions xcrb_msg_to_type6cprb_msgx() and xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a kernel buffer based on the message length. But on further processing the message is supposed to be 4 byte length adjusted. Thus up to 3 bytes of uninitialized kernel memory are forwarded to further processing steps and may unwanted expose kernel memory to the crypto card firmware. This patch contains code to pad the gap between user space copied message and message buffer length sent down to further processing of the CCA or EP11 message to zeros. Fixes: e2c6d91eb8b1 ("s390/zcrypt: Rework domain processing within zcrypt device driver") Signed-off-by: Harald Freudenberger <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Cc: [email protected] # 7.1+ Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hongjie Fang <[email protected]> Date: Wed Jul 29 19:16:14 2026 +0800 scsi: core: pair EH runtime PM get and put [ Upstream commit 872f486259ae0bc6b73ca4735a15d013241f73e9 ] shost->eh_noresume is currently consulted twice in one error handling iteration: once before scsi_autopm_get_host() and once again before scsi_autopm_put_host(). That is racy when a PM-triggered error path flips shost->eh_noresume while the SCSI EH thread is still running. The problem flow looks like this: PM path ufshcd_set_dev_pwr_mode() shost->eh_noresume = 1 ufshcd_execute_start_stop <-- trigger EH ... shost->eh_noresume = 0 EH path scsi_error_handler() if (!shost->eh_noresume) scsi_autopm_get_host() <-- skipped ... if (!shost->eh_noresume) scsi_autopm_put_host() <-- executed later In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow. Fix this by making eh_noresume a regular bool so it can be accessed with READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions. Fixes: ae0751ffc77e ("[SCSI] add flag to skip the runtime PM calls on the host") Signed-off-by: Hongjie Fang <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Peter Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jérémy Jean <[email protected]> Date: Tue Aug 4 20:00:42 2026 +0000 sctp: validate cookie AUTH state before use [ Upstream commit 3dbb44d88b1e94dd31fe43588af7437b34b44d56 ] When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: Jérémy Jean <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rui Qi <[email protected]> Date: Fri Aug 7 16:15:12 2026 +0800 selftests/ftrace: Convert ELF entry point to file offset in uprobe test commit 24aa630f6259e6a2107936c06fed72063f712b64 upstream. The add_remove_uprobe test uses readelf -h to obtain the ELF entry point (e_entry) and passes it directly as the offset to uprobe_events. However, uprobe_events expects a file offset, not a virtual address. For PIE binaries, the virtual address happens to equal the file offset because the first LOAD segment has p_vaddr == p_offset, so the test works by coincidence. But for non-PIE executables, e_entry is an absolute virtual address that can far exceed the file size. When the probe is enabled, uprobe_register() checks offset > i_size_read(inode) and rejects it with -EINVAL. Fix this by converting the virtual address to a file offset using the ELF program headers: scan readelf -lW output for the LOAD segment containing the entry point, then compute file_offset = e_entry - p_vaddr + p_offset. For PIE binaries the result is unchanged; for non-PIE binaries the offset is correctly translated. The conversion uses only POSIX shell primitives, with no dependency on gawk or perl. Link: https://lore.kernel.org/all/[email protected]/ Fixes: dc4b165855f2 ("selftests/ftrace: Use readelf to find entry point in uprobe test") Cc: [email protected] Signed-off-by: Rui Qi <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gang Yan <[email protected]> Date: Mon Aug 3 18:16:37 2026 +0200 selftests: mptcp: join: mark tests with data corruption as failed commit ca318e7bbb7723f57bcd9e69a2873b5884435552 upstream. check_transfer() compares the input and output files byte-by-byte using `cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs in a subshell (the script sets neither lastpipe nor pipefail), the fail_test call inside it -- which sets the global ret/last_test_failed -- and the `return 1` both act on the subshell, not on check_transfer(). check_transfer() thus always falls through to `return 0`, and any data corruption affecting only the payload (leaving the subflow/PM counters untouched) is silently reported as PASS. Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer") Cc: [email protected] Signed-off-by: Gang Yan <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-5-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Jul 31 12:44:09 2026 -0500 selinux: do not cancel a policy conversion that never started commit e5c0235a3c4e9eb047a16cd02323fe4ecf2f570e upstream. sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts. Cc: [email protected] Fixes: 02a52c5c8c3b ("selinux: move policy commit after updating selinuxfs") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Mon Jul 27 20:30:59 2026 -0500 selinux: reject a class permission count below its inherited common commit 9a82dcd98b6e6e11cfd162410967951f12152528 upstream. security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected. Cc: [email protected] Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Mon Jul 27 20:30:58 2026 -0500 selinux: reject a permission value exceeding the class permission count commit d14b5d0e97fccd27974fedc03b903408872907fd upstream. perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. Cc: [email protected] Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> [PM: tweak comment for line length] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Jul 31 12:44:11 2026 -0500 selinux: reject an unclaimed class value in security_get_classes() commit 22b05fec62c0fe9864cfceb52f7d0f3a34d9b1dd upstream. security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected. Cc: [email protected] Fixes: 55fcf09b3fe4 ("selinux: add support for querying object classes and permissions from the running policy") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri Jul 31 12:44:12 2026 -0500 selinux: require every boolean value to be defined commit a93d37a09b863810653f93d371fb197457d59deb upstream. p_bools.nprim comes from the policy image independently of how many booleans follow it, and cond_index_bool() fills bool_val_to_struct[] at value - 1, so a count larger than the values present leaves NULL entries. Every user of that array then walks it by index and dereferences each entry: cond_evaluate_expr() on the access-vector path, security_get_bools() and security_get_bool_value() behind selinuxfs, and security_set_bools(). A sparse class value is absorbed by policydb_class_isvalid() and its siblings; booleans have no such predicate, and no consumer that could use one. Reject a boolean value that no boolean defines, once, where the array is built. Conforming policies define every boolean they declare and are unaffected. Cc: [email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bryam Vargas <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jasper Wise <[email protected]> Date: Thu Aug 13 08:46:18 2026 +0000 spi: virtio: mark device ready before registering the controller [ Upstream commit 11058bd3d47d57eb3473935feae53868d6d168b7 ] virtio_spi_probe() registers the SPI controller with devm_spi_register_controller(). spi_register_controller() binds a child inline unless its driver has asked for asynchronous probing, so a peripheral that performs a transfer during its own probe reaches virtio_spi_transfer_one(), which kicks the virtqueue before probe has returned. The driver never calls virtio_device_ready(), so DRIVER_OK is set on its behalf by virtio_dev_probe(), only once probe has returned. The virtio spec is explicit about that ordering in 3.1 Device Initialization: | The driver MUST NOT send any buffer available notifications to the | device before setting DRIVER_OK. A device that waits for DRIVER_OK before servicing the queue therefore leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its completion with no timeout, so probe never returns. Mark the device ready before registering the controller, as done for the same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and commit 1d774589f924 ("i2c: virtio: mark device ready before registering the adapter"). Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Signed-off-by: Jasper Wise <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Fri Aug 7 09:44:36 2026 +0800 tcp: fix icsk_ack.ato bitfield overflow [ Upstream commit 60837e4b840a9c3f7ec826e3584df0bc6542a2c2 ] On cross-region connections we observed delayed ACKs suddenly turning into immediate ACKs plus a TCP_MAX_QUICKACKS burst, as if the connection had just received its first data segment. Commit 95b9a87c6a6b ("tcp: record last received ipv6 flowlabel") squeezed icsk_ack.ato into 8 bits, sized for TCP_DELACK_MAX. But both writers still bound ato by icsk_rto, which can be well above 255 jiffies, so the bitfield assignment silently wraps mod 256: repeated delack timer misses double ato up to icsk_rto, storing 320 as 64 and 256 as 0, and ato == 0 is the "first data packet" sentinel in tcp_event_data_recv(). Clamp both writers to TCP_DELACK_MAX, which the static_assert already guarantees to fit and tcp_send_delayed_ack() effectively caps ato at anyway. Fixes: 95b9a87c6a6b ("tcp: record last received ipv6 flowlabel") Signed-off-by: Jiayuan Chen <[email protected]> Reviewed-by: Neal Cardwell <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karl Mehltretter <[email protected]> Date: Wed Jul 22 08:21:41 2026 +0200 tick: Include ktime.h and jiffies.h in linux/tick.h [ Upstream commit 45f8dffc0714c3ef49c83e5bba4c56a4499bd5fc ] The !CONFIG_NO_HZ_COMMON stubs use ktime_add(), ktime_get() and TICK_NSEC, but tick.h includes neither <linux/ktime.h> nor <linux/jiffies.h>. Most configurations build only because those declarations arrive transitively. Commit 6440966067dc ("cpuset: Remove cpuset_cpu_is_isolated()") removed <linux/cpuset.h> from <linux/sched/isolation.h>. The <linux/cpuset.h> include chain had been satisfying these declarations before <linux/tick.h> was parsed. Commit 8aa76aa41589 ("ring-buffer: Use a housekeeping CPU to wake up waiters") then added <linux/sched/isolation.h> to ring_buffer.c ahead of any header which provides them. Neither change is wrong on its own: the failure requires both and appeared in v7.0. ARM rpc_defconfig + CONFIG_FUNCTION_TRACER fails to build: $ make ARCH=arm rpc_defconfig $ ./scripts/config -e FTRACE -e FUNCTION_TRACER $ make ARCH=arm olddefconfig $ make ARCH=arm kernel/trace/ring_buffer.o In file included from include/linux/sched/isolation.h:6, from kernel/trace/ring_buffer.c:8: include/linux/tick.h: In function 'tick_nohz_get_next_hrtimer': include/linux/tick.h:156:9: error: implicit declaration of function 'ktime_add'; did you mean 'size_add'? include/linux/tick.h:156:19: error: implicit declaration of function 'ktime_get'; did you mean 'time_init'? include/linux/tick.h:156:32: error: 'TICK_NSEC' undeclared Include the headers the file actually uses. Fixes: 8aa76aa41589 ("ring-buffer: Use a housekeeping CPU to wake up waiters") Signed-off-by: Karl Mehltretter <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Assisted-by: Codex:gpt-5.6-sol Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Köppeler <[email protected]> Date: Thu Aug 6 13:43:49 2026 +0200 veth: fix queue index used to wake the peer txq in veth_poll [ Upstream commit 60db47f02bfa2aa688938aa199117ec4f8e31d23 ] veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Signed-off-by: Jonas Köppeler <[email protected]> Tested-by: Jesper Dangaard Brouer <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:24:17 2026 -0700 xfs: avoid UAF on sc->tempip in xrep_tempfile_create commit 0c88e10d12de9ca7cbed1467bb1b52310101bff8 upstream. LOLLM noticed a potential UAF if the tempfile creation code fails after it set sc->tempip. Fix that. Cc: [email protected] # v6.10 Fixes: 84c14ee39dd388 ("xfs: create temporary files and directories for online repair") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ibrahim Hashimov <[email protected]> Date: Wed Jul 15 09:17:23 2026 +0200 xfs: bounds-check buffer log item's dirty bitmap commit 813f8136a2ce1fee266d02a7df73db6e8a541604 upstream. xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base, nbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Ibrahim Hashimov <[email protected]> Reviewed-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Mon Jul 20 20:23:46 2026 -0700 xfs: check cowextsize in xrep_inode_cowextsize commit 270ffcd9b0a46254fbf3079d0e3341db7d7ec0e6 upstream. LOLLM points out that the function that corrects cowextsize should check i_cowextsize, not i_extsize. Cc: [email protected] # v6.14 Fixes: a9600db96f74af ("xfs: detect and repair misaligned rtinherit directory cowextsize hints") Signed-off-by: "Darrick J. Wong" <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Wed Jul 29 15:00:58 2026 +0200 xfs: check v5 superblock features early commit eb6b2cc1fc8ad566d746d128a559989ff0bba5cc upstream. When working on a new features that reuses the existing pad in the superblock, I noticed that mounting such a file system on an old kernel logs a rather confusing warning: XFS (vdc): Metadir superblock padding fields must be zero. This is because we only validate the various feature fields in v5 superblocks after the common superblock validation helper is called. Fix this by calling the feature validation first. Fixes: eca383fcd63b ("xfs: refactor superblock verifiers") Cc: <[email protected]> # v4.19 Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:25:50 2026 -0700 xfs: check xfarray iteration errors when committing unlinked inode lists commit 2daf3ed5d059dec79c123aec42eb8d28e0c016d4 upstream. LOLLM noticed that we neglect to check for xfarray_iter itself returning errors when writing a new AGI. Fix that. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qiang Ma <[email protected]> Date: Thu Jul 16 17:22:45 2026 +0800 xfs: clear zapped attr fork state when bmap repair finds no attr fork commit 87b2a82e135ba81e49d82b59e3d72468cb66ea98 upstream. xfstests xfs/377 can make xfs_scrub repeatedly check and repair the attr block map after inode repair zaps an attr fork. When inode repair zaps an attr fork, it records XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork block map. If the fork has been reset to an empty state and removed, BMBTA repair has no attr fork mappings to rebuild and can return success. The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means xchk_file_looks_zapped() deliberately ignores the stale zapped health bit and asks xchk_bmap() to check the current attr fork. For an absent attr fork, xchk_bmap() returns -ENOENT. Returning that error prevents xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving the zapped health state behind even though there are no attr fork mappings left to check. Treat -ENOENT during post-repair BMBTA revalidation as a clean result for the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success. Keep the existing -ENOENT behavior for ordinary scrubs of absent attr forks. Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork") Cc: [email protected] # v6.8 Reviewed-by: "Darrick J. Wong" <[email protected]> Signed-off-by: Qiang Ma <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:23:15 2026 -0700 xfs: don't double-lock when deleting a self-referential directory commit 5fc643fb86599e29b38e7b2c2680b4b15bf8f772 upstream. LOLLM notices that the dirtree scrubber can detect a directory that refers to itself. In this case, it's not correct for the directory tree repair code to try to iolock/ilock both sc->ip and dp, because they're the same inode. Fix this by detecting that corner case and handling it appropriately. Cc: [email protected] # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:26:52 2026 -0700 xfs: don't ignore runtime errors in xrep_iunlink_reload_next commit 0052633527158b49762ab427e73924e4f8d25e6c upstream. LOLLM complained that this function ignores runtime errors being returned by xrep_iunlink_store_*. Rework the function signature so that we can return runtime errors to abort the repair. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:23:31 2026 -0700 xfs: don't return EFSCORRUPTED when scrubbing corrupt parent pointers commit 8af9cd79cdf6ee96ec610d707db22244fa21eb40 upstream. LOLLM noticed that scrub sets the CORRUPT flag when xfs_parent_from_attr thinks it's been given a corrupt parent pointer. This eliminates the potential to repair the filesystem because that error code is bubbled up the call stack. Fix this by collapsing them all to ECANCELED in xchk_parent_pptr, which doesn't have that trait. Cc: [email protected] # v6.10 Fixes: 0d29a20fbdba89 ("xfs: scrub parent pointers") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Long Li <[email protected]> Date: Mon Jul 27 10:38:49 2026 +0800 xfs: don't swallow dquot recovery verification errors commit e2b4a856085e9bd939bde2dee0d08b1d41babde9 upstream. xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk. Fixes: 9c235dfc3d3f ("xfs: dquot recovery does not validate the recovered dquot") Cc: [email protected] # v6.8 Signed-off-by: Long Li <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:25:04 2026 -0700 xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair commit 1e96a00e0d3a00be6e4f368b2f18e2d345f813ce upstream. LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket tries to walk ragi->sc->sa.agi_bp to rebuild the unlinked inode lists. Unfortunately, it's possible for agi_bp to be null if the buffer verifier fails, so we have to use ragi->agi_bp (which skips verifier checks) instead. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:23:46 2026 -0700 xfs: don't zap the attr fork on repair when there are queued pptr updates commit 5ee37132ea81abd36213b31a72140660c2aac54b upstream. LOLLM noticed that xrep_xattr_rebuild_tree doesn't check for queued parent pointer updates when it decides that it's going to zap the attr fork. This is obviously incorrect, so fix that. We hold the IOLOCK and the ILOCK of sc->ip at that point in time, so we can't race with any /new/ operations. Cc: [email protected] # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:26:06 2026 -0700 xfs: fix allocated inodes that show up in the unlinked list commit 68ab37650ce5195b4f4f8466444a36a78207840c upstream. If an allocated inode shows up in the unlinked list, we need to get it completely off the list. Set the corrected next/prev pointers such that the inode will not look like it should be on an unlinked list at all. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:26:21 2026 -0700 xfs: fix another iunlink infinite loop bug in online fsck commit 6d67c6b99f1fc07c64b97fcbc974c6f1ada7f622 upstream. xrep_iunlink_resolve_bucket is supposed to reconstruct as much of the incore prev and next unlinked list pointers based on what it finds on disk and in memory before we move on to relinking the truly lost inodes back into the unlinked list. However, it's still vulnerable to infinite loops that come in via the next_unlinked pointers. Fix this problem by remembering which inodes we've already seen and checking new agino pointers against that. If a bit is already set, either this is a loop or the inode has nonzero link count. We'll deal with the second case in a subsequent patch. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lin Jiapeng <[email protected]> Date: Tue Jul 28 15:19:10 2026 +0800 xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN commit b2d5a81dae385333f9734910277fbf94c78bd17f upstream. When exchanging two full-file ranges, xmi_can_exchange_reflink_flags() can move the reflink inode flag from the file that currently has it to the other file, as long as exactly one side is marked. This assumes that the file contents, and therefore all shared extents, are exchanged. That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set. xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings from file1, so an exchange can complete without moving every mapping that the earlier flag-swap decision accounted for. In that case the post-operation cleanup can clear the reflink flag from an inode that still owns shared written extents. Later writes then take the non-reflink write path and may update blocks that should still have been protected by CoW, which shows up as data corruption between reflink-related files. Fix this by disabling the reflink flag exchange whenever XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still proceed; the conservative outcome is that both inodes keep the reflink flag. The regular reflink flag cleanup path can drop the extra flag later once the inode no longer has shared extents. Reported-by: Lin Jiapeng (TencentOS Red Team) <[email protected]> Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: [email protected] # v6.10 Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Lin Jiapeng <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Long Li <[email protected]> Date: Mon Jul 27 10:38:48 2026 +0800 xfs: fix ilock leak on error in xfs_dq_get_next_id commit 63320a0f70f66f311f4bccff3af0719c2119f46c upstream. xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly. Fixes: bda250dbaf39f ("xfs: rewrite xfs_dq_get_next_id using xfs_iext_lookup_extent") Cc: [email protected] # v4.12 Signed-off-by: Long Li <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiang Mei <[email protected]> Date: Tue Jul 14 14:56:12 2026 -0700 xfs: fix off-by-one in rtrefcount btree root level validation commit cc3144da377de5fb422d44a2311f978623f7c900 upstream. xfs_rtrefcountbt_compute_maxlevels() sets mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing "+ 1" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the ">=" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception Cc: [email protected] # v6.14 Fixes: 9abe03a0e4f978 ("xfs: introduce realtime refcount btree ondisk definitions") Reported-by: Weiming Shi <[email protected]> Signed-off-by: Xiang Mei <[email protected]> Reviewed-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Mon Jul 20 20:24:02 2026 -0700 xfs: fix transaction block reservation in xrep_rtbitmap commit 61606f8846a9da8ab7d2d36ff4617134c9d6df1b upstream. LOLLM pointed out an inconsistency in the block reservation code in xrep_rtbitmap. The first is that the reservation computation is not consistent between the code that sets up the repair and the code that tries to avoid exceeding the transaction reservation once we know how big the rtbitmap really must be. As a result, the logic doesn't work. In fixing that, a second problem emerges: if we do readjust, we ask for the entire reservation all over again. We really only need the delta, so ask only for that. Fix all these problems by hoisting the computation to a trivial helper so that it gets used in both places. Cc: [email protected] # v6.14 Fixes: 8defee8dff2b20 ("xfs: online repair of realtime bitmaps for a realtime group") Signed-off-by: "Darrick J. Wong" <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:25:19 2026 -0700 xfs: load next_agino from the correct xfarray in xrep_iunlink_relink_prev commit 6b9cd540138a06660a843a519facc147060acbef upstream. LOLLM notices that xrep_iunlink_relink_prev has the comment "set the forward pointer..." but then loads the value from the xfarray that stores pointers to the previous inode in the unlinked list. That's wrong, so fix the variable access. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Mon Jul 20 20:24:48 2026 -0700 xfs: mark nonzero sb_gquotino as corrupt on metadir filesystems commit b28d23c51635b646784a2a62c71ba99458c07d5e upstream. On a metadir filesystem, the superblock gquotino field is always zero because we find the quota inodes through the metadata directory tree. A nonzero value is therefore a corruption (as pointed out by LOLLM) so mark the failure as such. Cc: [email protected] # v6.13 Fixes: 06b20ef09ba163 ("xfs: check pre-metadir fields correctly") Signed-off-by: "Darrick J. Wong" <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:24:02 2026 -0700 xfs: nlink scrub must take IOLOCK before determining ILOCK state commit b1a296fc2241f724ef8f14da6a4efa800d444dac upstream. In xchk_nlinks_ilock_dir, take the IOLOCK before accessing internal inode state to figure out if we need to take ILOCK shared or exclusive. That way we can't race with directory updates. LOLLM pointed out that the code was initially correct w.r.t. the IOLOCK, but then I broke it. Cc: [email protected] # v6.18 Fixes: f477af0cfa0487 ("xfs: fix locking in xchk_nlinks_collect_dir") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:22:59 2026 -0700 xfs: only check mergeability of bnobt records commit 97efed1091a50e4dbf31307015138b43a972d2e4 upstream. In the cntbt (free space by block count) btree, records are not supposed to be in startblock order. Hence the mergeability check is pointless. Remove it, since it does nothing, as LOLLM points out. Cc: [email protected] # v6.4 Fixes: d5784ae82778d9 ("xfs: flag free space btree records that could be merged") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:25:35 2026 -0700 xfs: pass runtime errors from xrep_iunlink_mark_ondisk_rec up to callers commit 5644fab990fc72406dddc91cbb8304659d77f3f1 upstream. LOLLM points out that the only error that xrep_iunlink_mark_ondisk_rec returns is ENOMEM, but we ignore that, and can end up writing a garbage AGI based on incomplete information. We shouldn't do that, though here we must be screen out EFSCORRUPTED/EFSBASDCRC because we haven't checked the inobt yet. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guanghui Yang <[email protected]> Date: Sun Jul 12 03:42:56 2026 +0000 xfs: propagate errors from xfs_rtginode_load commit b7e53968cb8882c2d276429ea8550848a4940874 upstream. xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than -ENOENT as success. This can leave the realtime group inode unset after an I/O, allocation, or corruption error. Growfs then continues as though the inode had been loaded. Only -ENOENT means that the inode needs to be created. Return all other errors to the growfs caller. Fixes: ae897e0bed0f ("xfs: support creating per-RTG files in growfs") Cc: [email protected] Signed-off-by: Guanghui Yang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: "Darrick J. Wong" <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Sun Jul 26 22:26:37 2026 -0700 xfs: set the prev pointer when reinserting an inode on the unlinked list commit af146cb7ff8ff5c54162f35c238f3ff1d5ad110f upstream. If we find a rogue free inode and decide to reinsert it into the unlinked list, we need to set the prev pointer to NULLAGINO so that the incore list gets updated. Cc: [email protected] # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Mon Jul 20 20:24:33 2026 -0700 xfs: zero i_nlink before repair puts inode on unlinked list commit 49933254ba8d421ed706cbe6ed0fbc264e572cab upstream. LOLLM observes that we don't reset i_nlink if we encounter a file with no parent that isn't on the unlinked list. This causes unnecessary assertion trips on debugging kernels and an inconsistent file, so let's fix that. Cc: [email protected] # v6.10 Fixes: 669dfe883c8e20 ("xfs: update the unlinked list when repairing link counts") Signed-off-by: "Darrick J. Wong" <[email protected]> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>