Author: Jhonraushan <[email protected]> Date: Fri Jul 24 11:23:40 2026 +0530 accel/ivpu: Reject firmware log with size smaller than header commit ddb44baed257560f192b145ed36cf8c0a412de47 upstream. fw_log_from_bo() validates the tracing buffer header_size and that the log fits within the BO, but never checks that log->size is at least log->header_size. fw_log_print_buffer() then computes: u32 data_size = log->size - log->header_size; which underflows to a near-U32_MAX value when firmware reports a log whose size is smaller than its header. That huge data_size defeats the log_start/log_end bounds clamps added by commit dd1311bcf0e6 ("accel/ivpu: Add bounds checks for firmware log indices"), so fw_log_print_lines() reads far past the small real data region of the BO. A size of 0 also makes fw_log_from_bo() advance the offset by 0, causing the callers to loop forever on the same header. Reject logs whose size is smaller than the header (which also rejects size == 0). Fixes: d4e4257afa6e ("accel/ivpu: Add firmware tracing support") Cc: [email protected] Signed-off-by: Jhonraushan <[email protected]> Reviewed-by: Karol Wachowski <[email protected]> Signed-off-by: Karol Wachowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Raushan Patel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Wed Jul 22 10:48:33 2026 -0400 afs: Annotate struct afs_addr_list with __counted_by [ Upstream commit 2d26302bdff1300029a67931739f5770eac22493 ] Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct afs_addr_list. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: David Howells <[email protected]> Cc: Marc Dionne <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Stable-dep-of: dc175389b18c ("rxrpc: serialize kernel accept preallocation with socket teardown") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Jul 22 10:48:34 2026 -0400 afs: Turn the afs_addr_list address array into an array of structs [ Upstream commit 07f3502b33a260f873e35708d2fa693eb52225cb ] Turn the afs_addr_list address array into an array of structs, thereby allowing per-address (such as RTT) info to be added. Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: [email protected] Stable-dep-of: dc175389b18c ("rxrpc: serialize kernel accept preallocation with socket teardown") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Heng <[email protected]> Date: Wed Jul 22 07:01:17 2026 -0400 ALSA: hda: conexant: Remove mic bias threshold override [ Upstream commit f52524da7084c1a54683ae9fbc73e93fff19dd64 ] Remove the mic bias current comparator threshold override (NID 0x1c, verb 0x320, value 0x010) from Conexant codec driver. This override was originally intended to support volume up/down controls on headsets with inline remote controls, but it causes microphone detection failures on some headsets with impedance less than 1k ohm. After consulting with the vendor's engineers, it was confirmed that this setting is board-specific and should be handled by BIOS/firmware rather than the generic codec driver, especially since inline remote support is not currently implemented. Fixes: 7aeb25908648 ("ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140") Cc: [email protected] Signed-off-by: Zhang Heng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xu Rao <[email protected]> Date: Wed Jul 22 07:24:21 2026 -0400 ALSA: hda: Fix cached processing coefficient verbs [ Upstream commit f67be28fdf8b5d31ac1cc1152bb17250f9f8f513 ] Intel HD Audio defines Coefficient Index and Processing Coefficient as separate audio widget controls in the Audio Widget Verb Definitions: Coefficient Index selects the coefficient slot, while Processing Coefficient accesses the value at the selected slot. hda_reg_read_coef() selects the slot with AC_VERB_SET_COEF_INDEX, but then uses AC_VERB_GET_COEF_INDEX for the value read. That reads back the selected index instead of the coefficient value. hda_reg_write_coef() has the same issue and builds the value write from AC_VERB_GET_COEF_INDEX instead of AC_VERB_SET_PROC_COEF. This only affects the regmap coefficient cache path used by codecs that set codec->cache_coef. Direct coefficient helpers already use the normal SET_COEF_INDEX followed by GET_PROC_COEF or SET_PROC_COEF sequence, which is likely why this has not been noticed widely. Use AC_VERB_GET_PROC_COEF for cached coefficient reads and AC_VERB_SET_PROC_COEF for cached coefficient writes. Fixes: 40ba66a702b8 ("ALSA: hda - Add cache support for COEF read/write") Cc: [email protected] Signed-off-by: Xu Rao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Norbert Szetei <[email protected]> Date: Tue Jul 14 10:29:23 2026 +0200 ALSA: seq: close a re-opened queue timer in the destructor commit 2c4dc0ed50b05cd847a4b34b8cebf0775f19aeb9 upstream. queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Jul 9 11:56:06 2026 +0200 ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC [ Upstream commit 93b47e66cc6d6c6382d44b44f5e7f6fc3a7b38c3 ] Salvador reported that the recent fix for applying the DSD quirk to Musical Fidelity devices broke for his M6s DAC model (2772:0502). Although this is basically a firmware bug, the model in question is fairly old, and no further firmware update can be expected, so it'd be better to address in the driver side. As an ad hoc workaround, skip the DSD quirk for this device by adding an empty quirk entry of 2772:0502; this essentially skips the later DSD quirk entry by the match with the vendor 2772. Fixes: da3a7efff64e ("ALSA: usb-audio: Update for native DSD support quirks") Reported-by: Salvador Blaya <[email protected]> Closes: https://lore.kernel.org/CAOdyq+qFaqCh=tK_wNnA64hv5pQuA1Y09ANxQ=xK8yR-t4mf9Q@mail.gmail.com Tested-by: Salvador Blaya <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Prashanth Kumar KR <[email protected]> Date: Thu Jul 9 15:20:06 2026 +0530 amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN [ Upstream commit 4bf22afe53a1de4b44b04cf677fd5199089cbdff ] MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed mode switching after CL37 auto-negotiation and is only meaningful in SGMII MAC mode. The original code unconditionally set this bit on every call to xgbe_an37_set(), including when called from xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after AN was disabled, causing the XPCS to autonomously switch speed from stale AN state during subsequent mode changes, breaking SGMII speed negotiation on 1G copper SFP modules. Patrick: This was breaking negotiation for all 1G SFP modules, not just copper modules. Fixes: 42fd432fe6d3 ("amd-xgbe: align CL37 AN sequence as per databook") Reported-by: Patrick Oppenlander <[email protected]> Link: https://lore.kernel.org/netdev/CAEg67GmFS0Q4oSZkz8zWdOzckSth9_vBPiOy6a7-d697C2w2Xg@mail.gmail.com Signed-off-by: Prashanth Kumar KR <[email protected]> Tested-by: Patrick Oppenlander <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Sat Jul 11 11:19:34 2026 -0400 amt: make the head writable before rewriting the L2 header [ Upstream commit 53969d704fa5b7c1751e277fac96bfc22b435eac ] amt_multicast_data_handler(), amt_membership_query_handler() and amt_update_handler() rewrite the ethernet header of the decapsulated skb in place (eth->h_proto, eth->h_dest and, for the query, also eth->h_source) before handing it up the stack. The skb head may be shared, for example when a packet tap has cloned it on the underlay interface, so writing through it corrupts the other reader's copy. Call skb_cow_head() before the rewrite so the head is private. It is placed before the pointers into the head are (re-)derived, so a reallocation caused by the copy is picked up by those derivations. Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Signed-off-by: Michael Bommarito <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Taehee Yoo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Sat Jul 11 11:19:33 2026 -0400 amt: re-read skb header pointers after every pull [ Upstream commit 3656a79f94c471827a08f2cacce5f94ad5e52c24 ] Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived. Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Signed-off-by: Michael Bommarito <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Taehee Yoo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Will Deacon <[email protected]> Date: Thu Jul 16 13:06:39 2026 +0100 arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates commit e057b94772328221405b067c3a85fe479b915dc8 upstream. When seccomp support was originally added to arm64 in a1ae65b21941 ("arm64: add seccomp support"), seccomp was erroneously called _before_ the ptrace syscall-enter-stop and therefore the tracer could trivially manipulate the syscall register state after the seccomp check had passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") by moving the seccomp check after the tracer has run. Unfortunately, a decade later, that fix has been reported to be incomplete. On arm64, both the first argument to a syscall and its eventual return value are allocated to register x0. In order to facilitate syscall restarting and querying of syscall arguments on the syscall exit path, the original value of x0 is stashed in 'struct pt_regs::orig_x0' early during the syscall entry path and is returned for the first argument by syscall_get_arguments(). Unlike 32-bit Arm, this stashed value is not directly exposed via ptrace() and so changes to register x0 made by the tracer on a syscall-enter-stop are not reflected in 'orig_x0'. This means that seccomp, syscall tracepoints and audit can observe a stale value for the register compared to the argument that will be observed by the actual syscall. Re-sync 'orig_x0' from x0 on the syscall entry path following a potential ptrace stop (i.e. PTRACE_EVENTMSG_SYSCALL_ENTRY or SECCOMP_RET_TRACE). This behaviour is limited to native tasks (because compat tasks expose 'orig_r0' to ptrace) where the syscall is not being skipped (because x0 is updated to hold the return value of -ENOSYS in that case). Cc: Kees Cook <[email protected]> Cc: Jinjie Ruan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Reported-by: Yiqi Sun <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Suggested-by: Catalin Marinas <[email protected]> Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Reviewed-by: Jinjie Ruan <[email protected]> Tested-by: Jinjie Ruan <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sumit Gupta <[email protected]> Date: Wed Jan 21 16:15:34 2026 +0530 arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234 [ Upstream commit 0dfa1e960f86e032007882b032c5cc7d14ebe73e ] The Tegra234 SoC uses Cortex-A78AE cores, not Cortex-A78. Update the compatible string for all CPU nodes to match the actual hardware. Tegra234 hardware reports: # head /proc/cpuinfo | egrep 'implementer|part' CPU implementer : 0x41 CPU part : 0xd42 Which maps to (from arch/arm64/include/asm/cputype.h): #define ARM_CPU_IMP_ARM 0x41 #define ARM_CPU_PART_CORTEX_A78AE 0xD42 Fixes: a12cf5c339b08 ("arm64: tegra: Describe Tegra234 CPU hierarchy") Signed-off-by: Sumit Gupta <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vijendar Mukunda <[email protected]> Date: Tue Jul 7 11:29:37 2026 +0530 ASoC: amd: ps: fix wrong ACP version string in pci_request_regions() [ Upstream commit f7697ecf6eab9d4887dd731038b3dc405c7e755e ] The driver handles ACP6.3/7.0/7.1/7.2 platforms but the region was claimed with the stale name "AMD ACP6.2 audio" left over from the original ACP6.2 driver. Correct it to "AMD ACP6.3 audio". Fixes: 95e43a170bb1 ("ASoC: amd: add Pink Sardine ACP PCI driver") Signed-off-by: Vijendar Mukunda <[email protected]> Reviewed-by: Mario Limonciello (AMD) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Wed Jul 15 18:06:20 2026 +0800 ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI [ Upstream commit 0b604e886ece11b71c4daaeccc512c784b89b014 ] The bt-sco-pcm-wb DAI uses the same stream_name strings as bt-sco-pcm ("Playback" and "Capture"). This causes duplicate DAPM AIF widget names within the same component, leading to debugfs warnings: debugfs: 'Playback' already exists in 'dapm' debugfs: 'Capture' already exists in 'dapm' Give the wideband DAI distinct stream names ("WB Playback" and "WB Capture") and add corresponding DAPM AIF widgets and routes for them. Fixes: 5947e1b4992e ("ASoC: bt-sco: extend rate and add a general compatible string") Assisted-by: VeroCoder:claude-sonnet-4-5 Signed-off-by: Shengjiu Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Fitzgerald <[email protected]> Date: Tue May 5 17:11:23 2026 +0100 ASoC: cs35l56: Don't use devres to unregister component [ Upstream commit bee87cf0f1248c0f20710d7a79df41fe892d9f88 ] Manually call snd_soc_unregister_component() from cs35l56_remove() instead of using devres cleanup. This ensures that the component is destroyed before cs35l56_remove() starts cleanup of anything the component code could be using. Devres cleanup happens after the driver remove() callback, so if snd_soc_register_component() is used, it will not be destroyed until after cs35l56_remove() has returned. But there is some cleanup that must be done in cs35l56_remove(), or wrapped in a custom devres cleanup handler to ensure correct ordering. The simplest option is to call snd_soc_unregister_component() at the start of cs35l56_remove(). Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Closes: https://sashiko.dev/#/patchset/20260501103002.2843735-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: 93c2a8ea2454 ("ASoC: cs35l56: Fix potential probe() deadlock") Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Fitzgerald <[email protected]> Date: Thu Jul 16 14:20:44 2026 +0100 ASoC: cs35l56: Fix potential probe() deadlock [ Upstream commit 93c2a8ea2454b7b14eb378a58cad8a83c0ffc903 ] On I2C/SPI call cs35l56_init() before calling snd_soc_register_component() to prevent the potential for a deadlock on init_completion. For most buses all the hardware would be ready when probe() returns, but on SoundWire, probe() must return before the SoundWire bus driver will enumerate the device. All access to the registers must be deferred until the driver receives an ATTACHED notification. But anything that could return -EPROBE_DEFER must be called during probe, and that includes snd_soc_register_component(). Because of that, on SoundWire the ASoC component can be created before the registers are accssible, so cs35l56_component_probe() waits for init_completion to signal that the registers are accessible. On I2C/SPI this 2-stage startup isn't required so their probe() functions simply called cs35l56_common_probe() and then cs35l56_init(). The problem with this was that snd_soc_register_component() was still called early. If this triggered ASoC to create the card, ASoC would call cs35l56_component_probe() which waits on init_completion - but this would be running inside the cs35l56 driver probe() so blocking it from reaching the code that signals init_completion, causing a deadlock. Fixes: e496112529006 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Reported-by: Salman S. Tahir <[email protected]> Closes: https://lore.kernel.org/linux-sound/[email protected]/T/#u Tested-by: Salman S. Tahir <[email protected]> Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Fitzgerald <[email protected]> Date: Thu Jul 16 14:20:45 2026 +0100 ASoC: cs35l56: Use complete_all() to signal init_completion [ Upstream commit e0bffb63a2eda0af82ed7e6357ac67c2db990c21 ] In cs35l56_init() use complete_all() to signal init_completion instead of complete(). cs35l56_init() was signaling init_completion using the complete() function. This only releases ONE waiter. If cs35l56_component_probe() was called multiple times the first time would consume that one signal, then future calls would timeout waiting for the completion. This could happen if: - The component is probed, removed, then probed again without the cs35l56 module being removed. - A call to component_probe() returns an error and ASoC calls it again later. It should use complete_all() so that after it has been signaled it will allow any code that waits on it to continue immediately. The one case where the driver must wait for initialization to run again is when waiting for a reboot after firmware download, and here the code correctly calls reinit_completion() first. Fixes: e496112529006 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald <[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: Wed Jul 8 11:34:30 2026 +0100 ASoC: cs42l43: Correct report for forced microphone jack [ Upstream commit f74e6e15485b68b92b2807071e822db6309b7e38 ] Currently if the jack is forced to the microphone mode, it will report as line in. Correct the report to microphone. Fixes: fc918cbe874e ("ASoC: cs42l43: Add support for the cs42l43") 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: Cássio Gabriel <[email protected]> Date: Wed Jul 22 22:53:02 2026 -0400 ASoC: mediatek: mt8183: Check runtime resume during probe [ Upstream commit f0334fbfd107682d0c95f3f71e25f6127038e2b9 ] The MT8183 AFE probe uses pm_runtime_get_sync() before reading hardware defaults into the regmap cache, but does not check whether runtime resume failed. If regmap_reinit_cache() then fails, the temporary runtime PM usage count is also not released. Use pm_runtime_resume_and_get() so resume failures abort probe without leaking a usage count, and release the temporary reference before handling the regmap cache result. Fixes: a94aec035a12 ("ASoC: mediatek: mt8183: add platform driver") Cc: [email protected] Signed-off-by: Cássio Gabriel <[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: AngeloGioacchino Del Regno <[email protected]> Date: Wed Jul 22 22:29:11 2026 -0400 ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable() [ Upstream commit 7aaaa22de56ce0dae15fd9f42a69a1d1a7a6e078 ] Switch from pm_runtime_enable() to devm_pm_runtime_enable(), allowing to remove all gotos from the probe function. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: e24d5dde56a5 ("ASoC: mediatek: mt8192: Check runtime resume during probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tang Bin <[email protected]> Date: Wed Jul 22 22:29:14 2026 -0400 ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable [ Upstream commit 01981565c764c554cc96e2d30a71c42975171416 ] Simplify the function mt8192_afe_pcm_dev_probe() by using local 'dev' instead of '&pdev->dev'. Signed-off-by: Tang Bin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: e24d5dde56a5 ("ASoC: mediatek: mt8192: Check runtime resume during probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Wed Jul 22 22:29:12 2026 -0400 ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe() [ Upstream commit 324c603a4efca7d1045e0bf3477ca54970eac72c ] Simplify the probe function by switching error prints to return dev_err_probe(), lowering the lines count; while at it, also beautify some messages and change some others' level from warn to error. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: e24d5dde56a5 ("ASoC: mediatek: mt8192: Check runtime resume during probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Wed Jul 22 22:29:15 2026 -0400 ASoC: mediatek: mt8192: Check runtime resume during probe [ Upstream commit e24d5dde56a50946020b134fa8448869093db76a ] The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes. Fixes: 125ab5d588b0 ("ASoC: mediatek: mt8192: add platform driver") Cc: [email protected] Signed-off-by: Cássio Gabriel <[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: Chen-Yu Tsai <[email protected]> Date: Mon Jun 24 14:12:56 2024 +0800 ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link commit 282a4482e198e03781c152c88aac8aa382ef9a55 upstream. Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link") removed the codec entry for the ETDM1_OUT_BE dai link entirely instead of replacing it with COMP_EMPTY(). This worked by accident as the remaining COMP_EMPTY() platform entry became the codec entry, and the platform entry became completely empty, effectively the same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything for platform entries. This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe() in sound/soc/mediatek/common/mtk-soundcard-driver.c: for_each_card_prelinks(card, i, dai_link) { if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF"))) dai_link->platforms->of_node = adsp_node; else if (!dai_link->platforms->name && !dai_link->platforms->of_node) dai_link->platforms->of_node = platform_node; } where the code expects the platforms array to have space for at least one entry. Add an COMP_EMPTY() entry so that dai_link->platforms has space. Fixes: e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[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: AngeloGioacchino Del Regno <[email protected]> Date: Wed Jul 22 22:29:10 2026 -0400 ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link [ Upstream commit e70b8dd26711704b1ff1f1b4eb3d048ba69e29da ] Remove the extra 'mt8195-afe-pcm-dai' component, register the DAI drivers to the main AFE component, and rework the DAI linking between the headset codec (RT5682/RT5682S) and the TDM interface in the probe function to stop assigning name, relying on the of_node of the codec. Also replace the COMP_DUMMY codec entry with a COMP_EMPTY for the ETDM2_IN and remove it entirely from ETDM1_OUT to fix the registration flow for this sound card. While at it, since we also need to swap the codec init function from ETDM2_IN to ETDM1_OUT, remove the static assignment of both `ops` and `init` for both, as we now assign these dynamically during probe. Fixes: 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: e24d5dde56a5 ("ASoC: mediatek: mt8192: Check runtime resume during probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Julien Massot <[email protected]> Date: Thu Apr 17 10:44:33 2025 +0200 ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY() commit 7af317f7faaab09d5a78f24605057d11f5955115 upstream. ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(), in the case the codec dai_name will be null. Avoid a crash if the device tree is not assigning a codec to these links. [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 1.181065] Mem abort info: [ 1.181420] ESR = 0x0000000096000004 [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.182576] SET = 0, FnV = 0 [ 1.182964] EA = 0, S1PTW = 0 [ 1.183367] FSC = 0x04: level 0 translation fault [ 1.183983] Data abort info: [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.186439] [0000000000000000] user address but active_mm is swapper [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1.188029] Modules linked in: [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85 [ 1.189515] Hardware name: Radxa NIO 12L (DT) [ 1.190065] Workqueue: events_unbound deferred_probe_work_func [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.191683] pc : __pi_strcmp+0x24/0x140 [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0 [ 1.192854] sp : ffff800083473970 [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002 [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88 [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8 [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006 [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374 [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018 [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000 [ 1.202236] Call trace: [ 1.202545] __pi_strcmp+0x24/0x140 (P) [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8 [ 1.203644] platform_probe+0x70/0xe8 [ 1.204106] really_probe+0xc8/0x3a0 [ 1.204556] __driver_probe_device+0x84/0x160 [ 1.205104] driver_probe_device+0x44/0x130 [ 1.205630] __device_attach_driver+0xc4/0x170 [ 1.206189] bus_for_each_drv+0x8c/0xf8 [ 1.206672] __device_attach+0xa8/0x1c8 [ 1.207155] device_initial_probe+0x1c/0x30 [ 1.207681] bus_probe_device+0xb0/0xc0 [ 1.208165] deferred_probe_work_func+0xa4/0x100 [ 1.208747] process_one_work+0x158/0x3e0 [ 1.209254] worker_thread+0x2c4/0x3e8 [ 1.209727] kthread+0x134/0x1f0 [ 1.210136] ret_from_fork+0x10/0x20 [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402) [ 1.211355] ---[ end trace 0000000000000000 ]--- Signed-off-by: Julien Massot <[email protected]> Fixes: e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link") Reviewed-by: AngeloGioacchino Del Regno <[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: AngeloGioacchino Del Regno <[email protected]> Date: Wed Jul 22 22:29:13 2026 -0400 ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb [ Upstream commit 1d2a6b3b5189b6c3e51f29e050aa9b2337b774e8 ] Since the mtk-afe-platform-driver generic mtk_afe_pcm_platform now has a common .probe() callback, there is no reason to keep duplicating this function over and over in the SoC specific AFE-PCM drivers: switch over to register with the common bits instead. Note that MT8186 was left out of this because it is registering some extra sinegen controls in the AFE-PCM probe callback and needs extra cleanups to be able to use the common bits. Reviewed-by: Alexandre Mergnat <[email protected]> Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: e24d5dde56a5 ("ASoC: mediatek: mt8192: Check runtime resume during probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Hewitt <[email protected]> Date: Sat Jun 27 13:12:05 2026 +0000 ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop [ Upstream commit 6b59c53c8adc2b522327407af5e1793a65b67e4b ] The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 + AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent: it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed, producing the "machine gun noise" buffer underrun - on start when switching outputs, and on stop when playback ends. The latter is audible on devices with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2). The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on both enable and disable (audio_hw_958_enable), and when reconfiguring (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same: reset before enabling the DCU on start, and before disabling on stop. Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support") Signed-off-by: Christian Hewitt <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uday Khare <[email protected]> Date: Mon Jul 6 21:01:09 2026 +0530 ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after lookup [ Upstream commit 3238c634725afbb2a137fdda762208510828f71d ] In tas2562_parse_dt(), the fallback lookup for the deprecated "shut-down" GPIO property is broken due to a missing pair of braces. The code intends to reset sdz_gpio to NULL only when the lookup returns an error that is not -EPROBE_DEFER (so the driver gracefully continues without a GPIO). However, without braces the statement: tas2562->sdz_gpio = NULL; falls outside the IS_ERR() check and is executed unconditionally for every path through the if block, including a successful GPIO lookup. This means any device using the deprecated 'shut-down' DT property will always have sdz_gpio == NULL after probe, making the GPIO completely non-functional. Fix this by adding the missing braces to scope the NULL assignment inside the IS_ERR() branch, matching the pattern already used for the primary 'shutdown' GPIO lookup above. Fixes: f78a97003b8b ("ASoC: tas2562: Update shutdown GPIO property") Signed-off-by: Uday Khare <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Mon Jul 6 22:45:39 2026 +0800 ASoC: tas2781: bound firmware description string parsing [ Upstream commit bc889dfcea9294a1eae7f8e2f3573a90764ae4d0 ] The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string. Fixes: 915f5eadebd2 ("ASoC: tas2781: firmware lib") Signed-off-by: Pengpeng Hou <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Tue Jul 28 22:40:07 2026 -0400 ata: libata-core: Reject an invalid concurrent positioning ranges count [ Upstream commit 533a0b940f901c15e5cbbd4b5d66e871c209e8ce ] ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there. Suggested-by: Damien Le Moal <[email protected]> Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log") Fixes: c745dfc541e7 ("libata: fix reading concurrent positioning ranges log") Cc: [email protected] Signed-off-by: Bryam Vargas <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> [ adapted `kzalloc_flex()` allocation to `kzalloc(struct_size(...), GFP_KERNEL)` and adjusted context offsets. ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rosen Penev <[email protected]> Date: Sun Jul 12 14:37:26 2026 -0700 ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered [ Upstream commit 4bbc16a353a98023e5ddfca7c1fc0e49971cf4d0 ] sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rosen Penev <[email protected]> Date: Sun Jul 12 14:37:27 2026 -0700 ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending interrupts [ Upstream commit 66c4e310ad71f41e41736d33dd8a1fb5eaaec7f3 ] clear_interrupt_bit() ignores the bit argument and performs a read-write-back of the entire INTPR register. If INTPR uses standard Write-1-to-Clear semantics, this clears every pending interrupt bit, not just the intended one. Coalesced interrupts (e.g. DMAT + NEWFP) would be cleared together, silently losing the second event. Write only the specific bit to clear so that other pending interrupts are preserved. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rosen Penev <[email protected]> Date: Sun Jul 12 14:37:28 2026 -0700 ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning [ Upstream commit c2130f6553f4a5cbdc259de069600117a995f197 ] The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rosen Penev <[email protected]> Date: Sun Jul 12 14:37:25 2026 -0700 ata: sata_dwc_460ex: use platform_get_irq() [ Upstream commit a4af122106f73ea510bb35a9ea1dedd980fc0db7 ] Replace irq_of_parse_and_map() with platform_get_irq() in both sata_dwc_dma_init_old() and sata_dwc_probe(). This is the preferred way to obtain IRQs for platform devices and provides better error reporting. Remove the now-unnecessary #include <linux/of_irq.h>. irq_of_parse_and_map() requires irq_dispose_mapping(), which is missing. Also fix unused variable when CONFIG_SATA_DWC_OLD_DMA is disabled. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Robaina <[email protected]> Date: Tue Jul 21 20:51:15 2026 -0400 audit: fix recursive locking deadlock in audit_dupe_exe() [ Upstream commit 81905b5acbe77284734438df3fbec1158e6429a3 ] A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c </TASK> The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resolution entirely, safely avoiding the recursive lock. Furthermore, it explicitly allows duplicate fsnotify marks (allow_dups = 1) during the rename update, allowing the new rule's mark to safely coexist with the old rule's mark until the old rule is freed. P.S.: This issue was identified and reproduced during a comprehensive code coverage analysis of the audit subsystem. The full report is available at the link below: https://people.redhat.com/rrobaina/audit-code-coverage-analysis.pdf P.P.S: With the permission of both Ricardo and Nathan, I've squashed a fixup patch from Nathan that addresses a compile time error when CONFIG_AUDITSYSCALL=n. Cc: [email protected] Fixes: 34d99af52ad4 ("audit: implement audit by executable") Acked-by: Waiman Long <[email protected]> Acked-by: Richard Guy Briggs <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Ricardo Robaina <[email protected]> [PM: move link metadata into the msg, apply fix from NC] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Robaina <[email protected]> Date: Tue Jul 21 20:51:14 2026 -0400 audit: use 'unsigned int' instead of 'unsigned' [ Upstream commit 8b226771014beab1292081151a99530886ce54b4 ] Address checkpatch.pl warning below, across the audit subsystem: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Minor cleanup, no functional changes. Signed-off-by: Ricardo Robaina <[email protected]> Signed-off-by: Paul Moore <[email protected]> Stable-dep-of: 81905b5acbe7 ("audit: fix recursive locking deadlock in audit_dupe_exe()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Layton <[email protected]> Date: Tue Jul 21 20:51:13 2026 -0400 audit: widen ino fields to u64 [ Upstream commit 125dfa218134df7cc112667e92984de9d8cd0bf6 ] inode->i_ino is being widened from unsigned long to u64. The audit subsystem uses unsigned long ino in struct fields, function parameters, and local variables that store inode numbers from arbitrary filesystems. On 32-bit platforms this truncates inode numbers that exceed 32 bits, which will cause incorrect audit log entries and broken watch/mark comparisons. Widen all audit ino fields, parameters, and locals to u64, and update the inode format string from %lu to %llu to match. Signed-off-by: Jeff Layton <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Paul Moore <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Stable-dep-of: 81905b5acbe7 ("audit: fix recursive locking deadlock in audit_dupe_exe()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Tue Jul 21 13:20:45 2026 +0200 binfmt_elf_fdpic: only honour the first PT_INTERP commit 3349ef6a366a61d631f6a263d12cea240957719d upstream. The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF binary format driver"). Link: https://patch.msgid.link/20260721-gezittert-medium-kreide-b41fc1f0277e@brauner Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reviewed-by: Jori Koolstra <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Mon Jul 20 14:36:49 2026 +0200 binfmt_misc: set have_execfd only once the interpreter is opened commit bbf5f639918dc011aaf60aab8480218758ee68c5 upstream. load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting. Link: https://patch.msgid.link/20260720-beglichen-kognitiv-organismus-5e1e55326c56@brauner Fixes: bc2bf338d54b ("exec: Remove recursion from search_binary_handler") Cc: [email protected] Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Mon Jul 20 19:47:17 2026 +0800 Bluetooth: btusb: validate Realtek vendor event length [ Upstream commit df541cd485ff80a5ddc579d99687bc7506df9851 ] btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation. Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Pengpeng Hou <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Thu Jul 9 14:22:50 2026 +0800 Bluetooth: hci_qca: Clear memdump state on invalid dump size [ Upstream commit bf587a10c33e5571a299742e45bc18960b9912e7 ] qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path. Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support") Signed-off-by: Ruoyu Wang <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Zijun Hu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Mon Jul 20 00:24:27 2026 +0800 Bluetooth: hci_sync: Protect UUID list traversal commit e9027ffbf5a0f3c12ca8900822e884eae9f0821b upstream. The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion. Fixes: 161510ccf91c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 1") Cc: [email protected] Signed-off-by: Chengfeng Ye <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Fri Jul 10 11:23:41 2026 +0300 Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync [ Upstream commit 16cd66443957e4ad42155c6fec401012f600c6f8 ] Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point. Fixes: 227a0cdf4a028 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Fri Jul 10 11:23:42 2026 +0300 Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds [ Upstream commit da55f570191d5d72f10c607a7043b947eb05ea46 ] Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race. Fixes: 7b445e220db9 ("Bluetooth: MGMT: Fix holding hci_conn reference while command is queued") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei <[email protected]> Date: Sat Jul 4 16:10:30 2026 -0700 Bluetooth: qca: fix NVM tag length underflow in TLV parser [ Upstream commit c90164ca0f7036942ba088eb7ea8d3f6c2352020 ] In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is "while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so "length" is converted to size_t and any firmware-supplied "length" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both operands are non-negative, so it no longer underflows and a "length" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Fixes: 2e4edfa1e2bd ("Bluetooth: qca: add missing firmware sanity checks") Reported-by: Weiming Shi <[email protected]> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <[email protected]> Reported-by: Weiming Shi <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Mon Jul 20 00:03:11 2026 +0800 Bluetooth: RFCOMM: Fix session UAF in set_termios commit c783399efc22d035443f1dfbf2a09bf9562aaa5e upstream. rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send. Fixes: 3a5e903c09ae ("[Bluetooth]: Implement RFCOMM remote port negotiation") Cc: [email protected] Signed-off-by: Chengfeng Ye <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhaolong Zhang <[email protected]> Date: Tue Jul 7 09:06:22 2026 +0800 bonding: fix devconf_all NULL dereference when IPv6 is disabled [ Upstream commit 1c975de3343cdef506f2eecc833cc1f14b0401c4 ] When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: <TASK> ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Fix this by adding ipv6_mod_enabled() condition check in the caller. Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Qianheng Peng <[email protected]> Signed-off-by: Zhaolong Zhang <[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: Rasmus Villemoes <[email protected]> Date: Tue Jul 28 14:06:41 2026 -0400 bootconfig: do not put quotes on cmdline items unless necessary [ Upstream commit 212f863fa8811c780abacc1d0404c573fdc0a2de ] When trying to migrate to using bootconfig to embed the kernel's and PID1's command line with the kernel image itself, and so allowing changing that without modifying the bootloader, I noticed that /proc/cmdline changed from e.g. console=ttymxc0,115200n8 cma=128M quiet -- --log-level=notice to console="ttymxc0,115200n8" cma="128M" quiet -- --log-level="notice" The kernel parameters are parsed just fine, and the quotes are indeed stripped from the actual argv[] given to PID1. However, the quoting doesn't really serve any purpose and looks excessive, and might confuse some (naive) userspace tool trying to parse /proc/cmdline. So do not quote the value unless it contains whitespace. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Rasmus Villemoes <[email protected]> Cc: Masami Hiramatsu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: dec4d8118c17 ("bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Tue Jul 28 14:06:43 2026 -0400 bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline() [ Upstream commit dec4d8118c179b3d12bca7e609054c6011c4f2ce ] xbc_snprint_cmdline() is meant to be called twice: first with buf=NULL, size=0 to probe the rendered length, then with a real buffer to fill it (the standard snprintf() two-pass pattern). The probe call makes the function compute "buf + size" (NULL + 0) and, on every iteration, advance "buf += ret" from that NULL base and pass the result back into snprintf(). Pointer arithmetic on a NULL pointer is undefined behavior. It is harmless in the in-kernel callers today, but the follow-up patches run this same code in the userspace tools/bootconfig parser at kernel build time, where host UBSan / FORTIFY_SOURCE abort the build. Track a running written length (size_t) instead of mutating @buf, and only form "buf + len" when @buf is non-NULL. snprintf(NULL, 0, ...) is itself well defined and returns the would-be length, so the two-pass "probe then fill" usage returns identical byte counts. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line") Cc: [email protected] Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Tue Jul 28 14:06:42 2026 -0400 bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c [ Upstream commit 5a643e4623238e14b03d75ca0d4eda0645720cee ] Move xbc_snprint_cmdline() from init/main.c to lib/bootconfig.c so the function (and its xbc_namebuf scratch buffer) becomes part of the shared parser library. tools/bootconfig already compiles lib/bootconfig.c directly, which lets a follow-up patch reuse the same renderer in the userspace tool to convert a bootconfig file into a flat cmdline string at build time. No functional change. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Stable-dep-of: dec4d8118c17 ("bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Fri Jul 24 18:38:56 2026 +0800 bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() [ Upstream commit 2d66a033864e27ab8d5e44cb36f31d9d2413bee4 ] tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Chengfeng Ye <[email protected]> Reviewed-by: Emil Tsalapatis <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/87fr18lmzo.fsf%40cloudflare.com/ Link: https://lore.kernel.org/netdev/20260719161630.2901208-1-nicoyip.dev%40gmail.com/ [v1] Link: https://patch.msgid.link/[email protected] Signed-off-by: Eduard Zingerman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Luczaj <[email protected]> Date: Tue Jul 7 06:23:57 2026 +0200 bpf, sockmap: Reject unhashed UDP sockets on sockmap update [ Upstream commit 66efd3368ae10d05e08fbe6425b50fdec7186ac7 ] UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm "test_progs", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject unhashed sockets in bpf_sk_assign"). Fixes: 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets") Suggested-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Michal Luczaj <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Reviewed-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Guan <[email protected]> Date: Wed Jul 29 22:51:57 2026 +0800 bpf: drop bpf_lsm_getselfattr from hook list Backport ("bpf, lsm: Add disabled BPF LSM hook list") for v6.6.y bring the warning "WARN: resolve_btfids: unresolved symbol bpf_lsm_getselfattr". The lsm_getselfattr from commit a04a1198088a ("LSM: syscalls for current process attributes"), no need to backport the huge patch, simply drop the entry to fix the noise. This is a fix for stable v6.6.145 backport commit, so no upstream commit. Fixes: b3b4719429d5 ("bpf, lsm: Add disabled BPF LSM hook list") Link: https://lore.kernel.org/stable/[email protected]/ Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Wed Jul 22 15:39:07 2026 +0800 bpf: Fix ld_{abs,ind} failure path analysis in subprogs commit ee861486e377edc55361c08dcbceab3f6b6577bd upstream. Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side. Fixes: 09b28d76eac4 ("bpf: Add abnormal return checks.") Reported-by: STAR Labs SG <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> [ Dropped visit_abnormal_return_insn changes: depends on 7.0 symbols from e40f5a6bf88a ("bpf: correct stack liveness for tail calls"); Hunk1: adapted IS_ERR/PTR_ERR to !branch/-EFAULT to match push_stack() NULL-on-failure convention. ] Signed-off-by: Philo Lu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matt Bobrowski <[email protected]> Date: Tue Jul 21 11:48:28 2026 -0400 bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized [ Upstream commit a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4 ] When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM. Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more). When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic. Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM. Gate map allocation in inode_storage_map_alloc() on this flag, returning -EOPNOTSUPP if the BPF LSM is in turn uninitialized. This fail-fast approach prevents userspace from allocating inode storage maps when the supporting BPF LSM infrastructure is absent, avoiding zombie map states. Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes") Reported-by: oxsignal <[email protected]> Signed-off-by: Matt Bobrowski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Emil Tsalapatis <[email protected]> Reviewed-by: Amery Hung <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: You-Kai Zheng <[email protected]> Date: Tue Jun 16 18:39:07 2026 +0800 btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8 [ Upstream commit b95181f3929ff98949fa9460ca93eccebbf2d7fc ] The variable-sized buffer buf in struct btrfs_ioctl_search_args_v2 is declared as __u64[], but it holds a packed byte stream of search results, where all offsets into the buffer are in bytes. Declaring buf as __u64[] makes it easy for user space to write incorrect pointer arithmetic: adding a byte offset directly to a __u64 pointer scales the offset by 8, landing at byte position offset*8 instead of offset. This recently caused an infinite loop in btrfs-progs: the accessor read all-zero data from misaddressed items, which fed zeroed search keys back into the ioctl loop and spun forever. The issue was worked around at the time by disabling TREE_SEARCH_V2 entirely in btrfs-progs (d73e69824854: "btrfs-progs: temporarily disable usage of v2 of search tree ioctl"). The kernel side already treats buf as a byte buffer, so change the declaration to __u8[] to match the actual semantics and prevent similar misuse in user space. The change is ABI compatible: both the structure size and alignment are unchanged. Fixes: cc68a8a5a433 ("btrfs: new ioctl TREE_SEARCH_V2") Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: You-Kai Zheng <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Thu Jun 11 15:16:21 2026 +0100 btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() [ Upstream commit ce6050bafb4e33377dc17fcc357736bfc351180c ] If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call. Fixes: 24213fa46c70 ("btrfs: do proper error handling in merge_reloc_roots") Reviewed-by: Qu Wenruo <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guanghui Yang <[email protected]> Date: Sun Jul 12 03:17:28 2026 +0000 btrfs: free mapping node on duplicate reloc root insert [ Upstream commit 6a8269b6459ed870a8156c106a0f597383907872 ] __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released. Fixes: 57a304cfd43b ("btrfs: do not panic in __add_reloc_root") Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Guanghui Yang <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei <[email protected]> Date: Wed Jun 10 10:29:26 2026 -0700 btrfs: reject free space cache with more entries than pages [ Upstream commit a2d8d5647ed854e38f941741aea45b9eb15a6350 ] When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = <N> here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected. Reported-by: Weiming Shi <[email protected]> Fixes: 5b0e95bf607d ("Btrfs: inline checksums into the disk free space cache") Link: https://lore.kernel.org/linux-btrfs/CAPpSM+RMPByMCKXvM5QFKToxsyNccfuFLWMdD0mfd0wh2Ja62w@mail.gmail.com/ Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Xiang Mei <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:03 2026 +0200 can: bcm: add locking when updating filter and timer values commit 749179c2e25b95d22499ed29096b3e02d6dfd2b4 upstream. KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:07 2026 +0200 can: bcm: add missing device refcount for CAN filter removal commit d59948293ea34b6337ce2b5febab8510de70048c upstream. sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 ("can: raw: add missing refcount for memory leak fix") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex. Reported-by: [email protected] Closes: https://sashiko.dev/#/patchset/[email protected] Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:05 2026 +0200 can: bcm: extend bcm_tx_lock usage for data and timer updates commit 12ce799f7ab1e05bd8fbf79e46f403bfe5597ebc upstream. Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:04 2026 +0200 can: bcm: fix CAN frame rx/tx statistics commit e6c24ba95fc3f1b5e1dcd28b1c6e59ef61a9daa5 upstream. KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:09 2026 +0200 can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() commit 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 upstream. For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:08 2026 +0200 can: bcm: fix stale rx/tx ops after device removal commit 3b762c0d950383ab7a002686c9136b9aa55d2d70 upstream. RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match. Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Closes: https://lore.kernel.org/linux-can/[email protected]/ Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:10 2026 +0200 can: bcm: track a single source interface for ANYDEV timeout/throttle ops commit 2f5976f54a04e9f18b25283036ac3136be453b17 upstream. An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net(). Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:24:06 2026 +0200 can: bcm: validate frame length in bcm_rx_setup() for RTR replies commit 62ec41f364648be79d54d94d0d240ee326948afd upstream. bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:34:08 2026 +0200 can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER commit 20bab8b88baac140ca3701116e1d486c7f51e311 upstream. isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Hartkopp <[email protected]> Date: Fri Jul 24 12:34:09 2026 +0200 can: isotp: serialize TX state transitions under so->rx_lock commit cf070fe33bfbd1a4c21236078fadb35dd223a157 upstream. The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Reported-by: [email protected] Closes: https://lore.kernel.org/linux-can/[email protected]/ Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuhao Fu <[email protected]> Date: Thu May 7 10:22:26 2026 +0200 can: j1939: fix lockless local-destination check [ Upstream commit e4e8af62adab2fdcca230006f829407a953070cd ] j1939_priv.ents[].nusers is documented as protected by priv->lock, and its updates already happen under that lock. j1939_can_recv() also reads it under read_lock_bh(). However, j1939_session_skb_queue() and j1939_tp_send() still read priv->ents[da].nusers without taking the lock. Those transport-side checks decide whether to set J1939_ECU_LOCAL_DST, so they can race with j1939_local_ecu_get() and j1939_local_ecu_put() while userspace is binding or releasing sockets concurrently with TP traffic. This can misclassify TP/ETP sessions as local or remote and take the wrong transport path. Fix both transport paths by routing the destination-locality check through a helper that reads ents[].nusers under read_lock_bh(&priv->lock). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Shuhao Fu <[email protected]> Tested-by: Oleksij Rempel <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Link: https://patch.msgid.link/20260419140614.GA4041240@chcpu16 Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Rao <[email protected]> Date: Mon Jul 20 20:44:21 2026 +0100 cdrom: fix stack out-of-bounds read in CDROMVOLCTRL commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream. mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Xu Rao <[email protected]> Signed-off-by: Phillip Potter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Fri May 29 00:37:24 2026 +0000 ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 upstream. ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: [email protected] Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ian Abbott <[email protected]> Date: Wed May 27 13:51:03 2026 +0100 comedi: comedi_parport: deal with premature interrupt commit 17221216ae8ce6a24e8a4e787382e3ebc81b88a8 upstream. Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the "comedi_parport" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi "attach" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't. Fixes: 241ab6ad7108e ("Staging: comedi: add comedi_parport driver") Reported-by: [email protected] Cc: stable <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qian Zuo <[email protected]> Date: Tue Jul 7 03:46:08 2026 +0000 coredump: fix pidfs file refcount leak in umh_coredump_setup The backport of upstream commit b5325b2a270f introduced a reference count leak for pidfs_file. In the upstream implementation, pidfs_file is declared with __free(fput), which automatically drops the initial file reference when leaving the scope. During the backport, the code was rewritten to manage the file pointer manually, but after a successful replace_fd(), pidfs_file was simply cleared without dropping the initial reference. As a result, the pidfs file keeps an extra reference and is never released after the usermode helper exits, leaving associated objects, such as struct pid, permanently allocated and triggering kmemleak reports. Fix this by explicitly calling fput(pidfs_file) after replace_fd(). Fixes: cdb61a705f5f ("coredump: hand a pidfd to the usermode coredump helper") Signed-off-by: Qian Zuo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Doruk Tan Ozturk <[email protected]> Date: Mon Jul 20 21:15:25 2026 +0200 crypto: rsa-pkcs1pad: Don't WARN on an empty digest KEYCTL_PKEY_VERIFY lets an unprivileged caller supply a zero-length digest (in_len == 0). keyctl_pkey_params_get_2() accepts the zero length and the request reaches pkcs1pad_verify(), where the empty digest is rejected but only after being passed through WARN_ON(!digest_size). The warning is therefore directly user-triggerable, and on kernels built with panic_on_warn=1 an unprivileged process can panic the machine -- a local denial of service. Reproduced as UID 65534 in a setuid sandbox. Keep rejecting the invalid request with -EINVAL, but do not emit a warning for the user-controlled length. Mainline does not contain this code path; commit 1e562deacecc ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") removed pkcs1pad_verify() in v6.13-rc1. This is a minimal fix for the affected stable branches. It applies as-is to 6.1.y, 6.6.y and 6.12.y (identical pkcs1pad_verify); the 5.10.y/5.15.y form is sent as a separate patch due to the older req->dst_len spelling. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: c7381b012872 ("crypto: akcipher - new verify API for public key algorithms") Cc: [email protected] Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 27 15:17:17 2026 -0400 dm-verity: avoid double increment of &use_bh_wq_enabled [ Upstream commit 72e9ec2fe32b00994f41719cf77423fca67d48b2 ] verity_parse_opt_args is called twice, first with the only_modifier_opts, first with only_modifier_opts == true and then with only_modifier_opts == false. Thus, the static branch &use_bh_wq_enabled was incremented twice and the destructor verity_dtr would only decrement it once. Fix tihs bug by only incrementing it on the first call, on the second call, when v->use_bh_wq is true, do nothing. Signed-off-by: Mikulas Patocka <[email protected]> Assisted-by: Claude:claude-opus-4-6 Cc: [email protected] Fixes: df326e7a0699 ("dm verity: allow optional args to alter primary args handling") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 27 15:22:11 2026 -0400 dm-verity: make error counter atomic [ Upstream commit 8ec4d9c5a5cf4b61fc087f871465b1f79b393325 ] The error counter "v->corrupted_errs" was not atomic, thus it could be subject to race conditions. The call to dm_audit_log_target("max-corrupted-errors") may be skipped due to the races. Signed-off-by: Mikulas Patocka <[email protected]> Assisted-by: Claude:claude-opus-4.6 Fixes: 65ff5b7ddf05 ("dm verity: add error handling modes for corrupted blocks") Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikhail Gavrilov <[email protected]> Date: Tue Jul 21 14:28:03 2026 -0400 dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning [ Upstream commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d ] When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: [email protected] Signed-off-by: Mikhail Gavrilov <[email protected]> Acked-by: Vivek Kasireddy <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Abinash Singh <[email protected]> Date: Sun Jul 26 09:35:15 2026 -0400 dma: dw-edma: Fix build warning in dw_edma_pcie_probe() [ Upstream commit 3df63fa8f2afd051848e37ef1b8299dee28d4f87 ] The function dw_edma_pcie_probe() in dw-edma-pcie.c triggered a frame size warning: ld.lld:warning: drivers/dma/dw-edma/dw-edma-pcie.c:162:0: stack frame size (1040) exceeds limit (1024) in function 'dw_edma_pcie_probe' This patch reduces the stack usage by dynamically allocating the `vsec_data` structure using kmalloc(), rather than placing it on the stack. This eliminates the overflow warning and improves kernel robustness. Signed-off-by: Abinash Singh <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Stable-dep-of: 11d7cfe0c119 ("dmaengine: dw-edma-pcie: Reject devices without driver data") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Koichiro Den <[email protected]> Date: Sun Jul 26 09:35:17 2026 -0400 dmaengine: dw-edma-pcie: Reject devices without driver data [ Upstream commit 11d7cfe0c119691b2dafbb699bbca90258c678aa ] dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device. Fixes: 41aaff2a2ac0 ("dmaengine: Add Synopsys eDMA IP PCIe glue-logic") Cc: [email protected] Signed-off-by: Koichiro Den <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun Jul 26 09:35:16 2026 -0400 dmaengine: dw-edma: Fix confusing cleanup.h syntax [ Upstream commit f9ef8dedee34e2d7828d5a6a0643cd969aaa8437 ] Initializing automatic __free variables to NULL without need (e.g. branches with different allocations), followed by actual allocation is in contrary to explicit coding rules guiding cleanup.h: "Given that the "__free(...) = NULL" pattern for variables defined at the top of the function poses this potential interdependency problem the recommendation is to always define and assign variables in one statement and not group variable definitions at the top of the function when __free() is used." Code does not have a bug, but is less readable and uses discouraged coding practice, so fix that by moving declaration to the place of assignment. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Stable-dep-of: 11d7cfe0c119 ("dmaengine: dw-edma-pcie: Reject devices without driver data") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Fri Jul 24 14:54:01 2026 +0200 dmaengine: sh: rz-dmac: Move interrupt request after everything is set up commit 731712403ddb39d1a76a11abf339a0615bc85de7 upstream. Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent(). Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: [email protected] Reviewed-by: Frank Li <[email protected]> Tested-by: John Madieu <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Tested-by: Tommaso Merciai <[email protected]> Link: https://patch.msgid.link/[email protected] [tm: Kept the channel->irq field in rz_dmac_chan_probe() instead of upstream's local `irq` variable, as commit 04e227718ab8 ("dmaengine: sh: rz-dmac: Make channel irq local") is not present in this tree. Likewise kept platform_get_irq_byname() instead of platform_get_irq_byname_optional() for the error IRQ in rz_dmac_probe(), as commit 6b3a6b6dc074 ("dmaengine: sh: rz_dmac: make error interrupt optional") is not present in this tree either; its early return on failure becomes a goto err jump to match the new call order.] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Tommaso Merciai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Jul 8 19:17:37 2026 +0800 dpaa2-eth: put MAC endpoint device on disconnect [ Upstream commit b4b201cc93ff70150853aba03e14d314d1980ca0 ] fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object. Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") Signed-off-by: Guangshuo Li <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Reviewed-by: Ioana Ciornei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Jul 8 19:10:25 2026 +0800 dpaa2-switch: put MAC endpoint device on disconnect [ Upstream commit 4c1eabbef7a1707635652e956e39db1269c3af2b ] fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Signed-off-by: Guangshuo Li <[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: WenTao Liang <[email protected]> Date: Fri Jun 26 20:45:55 2026 +0800 drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference commit a6e14b976be48eebd8769cb5b883a6af7fc5ade1 upstream. prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. Fixes: 54618888d1ea ("drm/amd/display: break down dc_link.c") Signed-off-by: WenTao Liang <[email protected]> Reviewed-by: Mario Limonciello (AMD) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harry Wentland <[email protected]> Date: Tue Jul 28 23:34:52 2026 -0700 drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate sources commit 76a2db58e95e328007043f54ac3c7336ccbee440 upstream. dcn32_update_clocks_update_dtb_dto() reprograms the DTB DTO of every timing generator in the context whenever the DTBCLK reference changes, passing a zeroed pixel rate and never setting is_hdmi. dccg32_set_dtbclk_dto() treats a zero pixel rate as a disable request, and that branch drives PIPE_DTO_SRC_SEL to the DP DTO source. A timing generator actively scanning out an HDMI stream therefore has its pixel rate source re-muxed out from under the live raster, and the OTG stops on the spot. Two displays where only one runs a 128b/132b link hit this reliably. is_dtbclk_required() holds the DTBCLK reference high while both are active, and the moment the 128b/132b stream is torn down (compositor switch, display disable, hot-unplug) the next safe_to_lower pass drops the reference to the lowest DPM level and the DTO walk freezes the surviving screen. On Navi31 the DAL mailbox then goes deaf on the DISPCLK hard-min that follows the walk in dcn32_update_clocks(), stranding both SMU mailboxes until reboot. Set is_hdmi for HDMI and DVI signals so the disable path leaves the pixel rate source selection on the HDMI path, and pass the real pixel rate for 128b/132b streams so a reference change rescales their DTO instead of disabling it. Fixes: 128c1ca0303f ("drm/amd/display: Update DTBCLK for DCN32") Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Fangzhi Zuo <[email protected]> Tested-by: Dan Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> [ mschwartz: dcn32 clk_mgr hunk only, as 6.6.y predates the dcn35 clk_mgr. The rest is HDMI FRL enablement, absent before 7.2, so the FRL conditions and the req_audio_dtbclk_khz assignment they guard are dropped and the FRL-centric changelog is rewritten. Added the pipe_ctx->stream check the new dereferences need. ] Signed-off-by: Matthew Schwartz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Wed Jun 10 17:18:17 2026 +0200 drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips commit ac11060c6d4959e2d4ceada037d2e1e1bfcf6645 upstream. The mode-setting pipeline can disabled damage clippings for a commit by setting ignore_damage_clips in struct drm_plane_state. The commit will then do a full display update. Test the flag in DCN code and do a full update in DCN code if it has been set. Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips") introduced ignore_damage_clips to selectively ignore damage clipping in certain framebuffer changes. This driver does not do that, but DRM's damage iterator will soon rely on the flag. Therefore supporting it here as well make sense for consistency. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips") Cc: Javier Martinez Canillas <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Zack Rusin <[email protected]> Cc: [email protected] Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit a24019f6480fad5c077b5956eed942c8960323d6) Cc: <[email protected]> # v6.8+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: WenTao Liang <[email protected]> Date: Sun Jun 28 15:27:40 2026 +0800 drm/amd/display: set new_stream to NULL after release commit 9fa26b9eed6195bf840f39ac183b9a6237548755 upstream. In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang <[email protected]> Reviewed-by: George Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon Jul 13 08:14:43 2026 +0200 drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) commit 85371c5ef502d10add72eab38711e191dccea981 upstream. The old radeon driver has a documented workaround in ci_dpm.c which claims that Bonaire 0x6658 with old memory controller firmware is unstable with MCLK DPM, so as a precaution I disabled MCLK DPM on this ASIC in amdgpu. Note that the old MC firmware is not actually used with amdgpu, but in theory it's possible that the VBIOS sets up the ASIC with an old MC firmware that is already running when amdgpu initializes (in which case amdgpu doesn't load its own firmware). What I expected to happen is that the GPU would simply use its maximum memory clock, and indeed this is what seemed to happen according to amdgpu_pm_info which reads the current MCLK value from the SMU. However, some users reported a huge perf regression and upon a closer look it seems that the GPU seems to not actually use the highest MCLK value, despite the SMU reporting that it does. Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X). Keep MCLK DPM disabled on R9 M380 in the 2015 iMac because that still hangs if we enable it. Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs") Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit d34acad064ee7d82bd18f5d87592c422d4d323ac) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Wang <[email protected]> Date: Fri Jun 12 10:55:09 2026 +0800 drm/amd/pm: make pp_features read-only when scpm is enabled commit 53c78ab388bfc1a4d72e756815d0db0a842c812e upstream. SCPM owns power feature control when enabled. Make pp_features read-only during sysfs setup by clearing its write bits and store callback. Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Asad Kamal <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 6a5786e191fdce36c5db170e5209cf609e8f0087) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:19:52 2026 -0400 drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() commit d06c4173a7c38c7a39e98859f839ce714c7af2c9 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:20:55 2026 -0400 drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() commit 0eebcab1ea2a77f086a04108f386f82ee3496022 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:17:59 2026 -0400 drm/amdgpu/gfx8: drop unecessary BUG_ON() commit 84a1a8a952ab4b8c23c5dd1f2eea4049cb4914f5 upstream. There's no need to crash the kernel for this case. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:42:35 2026 -0400 drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() commit 00f4050f7c367d7bdce347ca279ce467c434cf15 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:14:59 2026 -0400 drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() commit 6302be10b521f5106ce01eb5a724b9e7945a5061 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:44:11 2026 -0400 drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() commit 40cdbe9fa424cc6264a7aed93a04bd7d69109d9e upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:26:28 2026 -0400 drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() commit 9e98ed3113943257ad6e5c1e6beddbdb482a70ad upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:27:15 2026 -0400 drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() commit b9dd618a635d39fbb211454b6e8837b2a7f10fb0 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Mon Jun 15 18:27:54 2026 -0400 drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() commit ec42c96c322e5cc48099ab5e67b5cbe236cb1949 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon May 25 13:33:20 2026 +0200 drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2) commit 32bd35f068a3507a1b3922cd12ea2985fc58c85b upstream. UVD 4.x and older can only access MSG, FEEDBACK buffers from a specific 256M VRAM segment that the VCPU BO is also located in. We already modify all placements of the given BO to ensure the BO is placed within this segment. Previously, it always assumed that the VCPU segment is the first 256M of VRAM, even though under some conditions the VCPU BO could be allocated outside this segment, which made UVD non-functional as the BOs were not inside the same segment as the UVD VCPU BO. Solve that by using the segment where the VCPU BO actually is. This fixes an issue with UVD failing to initialize on SI/CIK when resizable BAR is enabled and the VCPU BO is allocated in a different segment. v2: - For other BOs, keep using the same UVD segment as before. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3851 Reviewed-by: Christian König <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit cbfd4d3fc2061a1ec8e9d36e65973ac3e813358a) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon May 25 13:33:19 2026 +0200 drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older commit 8002b744ad70055ef11ff7d0a7d685bfe8ffe6e4 upstream. These UVD versions don't fully support GPUVM and are only validated to work when their VCPU BO is placed in VRAM. Signed-off-by: Timur Kristóf <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 01b8dfc0660db5d6cdd62c22dc20f774a26ce853) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Boyuan Zhang <[email protected]> Date: Mon May 25 11:34:27 2026 -0400 drm/amdgpu/vce: fix integer overflow in image size commit 186bfdc4e26d019b2e7570cb121964a1d89b2e5b upstream. Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 Signed-off-by: Boyuan Zhang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Boyuan Zhang <[email protected]> Date: Thu May 21 09:59:37 2026 -0400 drm/amdgpu/vcn4: avoid rereading IB param length commit 3b4082fabc67c9780b06eb959e59dd92fa79c0f0 upstream. Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. Signed-off-by: Boyuan Zhang <[email protected]> Reviewed-by: David Rosca <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon May 25 13:33:18 2026 +0200 drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT commit ee94a65f192c05c543b4d3ad7137cd696b5c18fc upstream. The UVD code relies on GTT to GTT moves in order to ensure that its BOs don't cross 256M segments. Fixes: bfe5e585b44f ("drm/ttm: move last binding into the drivers.") Signed-off-by: Timur Kristóf <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 21fd45e5e2628d00b478590bcc3d14d3de5d45b6) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Asad Kamal <[email protected]> Date: Sun Jun 14 12:50:28 2026 +0800 drm/amdgpu: fix aperture mapping leak commit ea772a440d56b285f4d491affac50ecd41f6b402 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to always return false, so iounmap(aper_base_kaddr) never runs on normal driver unload, leaving an orphaned entry in the x86 PAT interval tree. On connected_to_cpu hardware, the aperture is mapped write-back (WB) via ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC) over the same range. The WC vs WB conflict causes: ioremap error for 0x..., requested 0x1, got 0x0 amdgpu: discovery failed: -2 Fix by switching to devres-managed mappings so cleanup is guaranteed regardless of drm_dev_enter() state: - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut, returning __va(offset) from the existing kernel direct map. No new ioremap VA or PAT entry is created, so there is nothing to orphan. - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action, guaranteeing cleanup at device_del() time. Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio() since the mapping is now devres-owned. v2: Remove redundant x86_64 guard (Lijo) Fixes: 9d0af8b4def0 ("drm/amdgpu: pre-map device buffer as cached for A+A config") Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhu Lingshan <[email protected]> Date: Wed Jul 1 18:53:21 2026 +0800 drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved commit a2f895f3c852063258d62e9f74b081de07ca95df upstream. amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. Signed-off-by: Zhu Lingshan <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Boyuan Zhang <[email protected]> Date: Tue May 12 10:29:36 2026 -0400 drm/amdgpu: fix division by zero with invalid uvd dimensions commit 0c01c811be47e6b146552dd59bfedbea8f09b8f4 upstream. When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. Signed-off-by: Boyuan Zhang <[email protected]> Reviewed-by: Leo Liu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Wed Jul 8 14:35:14 2026 -0500 drm/amdgpu: Fix VFCT bus number matching with soft filter commit db7e8108809a2245f0a17ba323f027cac0941ffb upstream. On systems where PCI bus renumbering occurs (e.g. pci=realloc, resource conflicts), the runtime bus number may differ from the BIOS POST bus number recorded in the VFCT table. This causes amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though the correct device entry exists. Introduce amdgpu_acpi_vfct_match() which treats the bus number as a soft filter: vendor/device/function identity is the hard requirement, while exact bus match is the preferred path. When bus numbers disagree but device identity matches, accept the VFCT entry and log a dev_notice for diagnostics. Reported-by: Oz Tiram <[email protected]> Closes: https://lore.kernel.org/amd-gfx/[email protected]/ Reviewed-by: Alex Deucher <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 11c141672045ffc0187aa604f2c0f597bc334fb2) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ce Sun <[email protected]> Date: Mon Jun 22 22:58:16 2026 +0800 drm/amdgpu: invoke pm_genpd_remove() before freeing genpd commit 28c9b3c5dc35cc790d11e26ca3fc6e068be63998 upstream. Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. Signed-off-by: Ce Sun <[email protected]> Reviewed-by: Tao Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Fri Jun 12 21:07:24 2026 -0500 drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 commit 84c4c36acd5c4b2558b5069f869a165b2c655c84 upstream. Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. Fixes: ac9287055ff1 ("drm/amdgpu: add gfx shadow CS IOCTL support") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Francis <[email protected]> Date: Thu May 21 09:18:59 2026 -0400 drm/amdkfd: Check bounds in allocate_event_notification_slot commit bb52249fbbe948875155ccd45cd8d74bf4ae747b upstream. The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist Signed-off-by: David Francis <[email protected]> Reviewed-by: David Yat Sin <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vitor Soares <[email protected]> Date: Tue May 5 14:47:05 2026 +0100 drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() commit 2d8b08844c0ecc6f2002fa68711e779aa18c8585 upstream. The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks. Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] # 6.1.x Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Vitor Soares <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ashutosh Desai <[email protected]> Date: Fri Apr 10 04:19:01 2026 +0000 drm/dp/mst: fix buffer overflows in sideband chunk accumulation commit 55bd5e685bda455b9b50c835f8c8442d52a344a3 upstream. drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: <[email protected]> # v3.17+ Signed-off-by: Ashutosh Desai <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ashutosh Desai <[email protected]> Date: Sun May 10 20:17:33 2026 +0000 drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers commit 1a8f537f5a1eeac941f262fe73078d6b08ba83c0 upstream. drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: <[email protected]> # v3.17+ Signed-off-by: Ashutosh Desai <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [added missing fixes tag] Signed-off-by: Lyude Paul <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ashutosh Desai <[email protected]> Date: Sun May 10 20:31:28 2026 +0000 drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers commit 6b89ba3dba2f583626fb693e47e951ffb8bf591f upstream. Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: <[email protected]> # v3.17+ Signed-off-by: Ashutosh Desai <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [added fixes tag] Signed-off-by: Lyude Paul <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Coelho <[email protected]> Date: Mon Jun 22 17:03:58 2026 +0300 drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() commit 613059875958e7b217b250ed14c3b189f9488421 upstream. A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost. Fixes: dbaeef363ea5 ("drm/dp_mst: Add a helper to queue a topology probe") Cc: Imre Deak <[email protected]> Cc: Lyude Paul <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Jonas Emilsson <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/all/[email protected] Acked-by: Imre Deak <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joonas Lahtinen <[email protected]> Date: Mon Jun 22 16:25:39 2026 +0300 drm/i915/gem: Add missing nospec on parallel submit slot commit 914a76a9f08366434bf595700f62026b7a19a9cc upstream. Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <[email protected]> Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Cc: Matthew Brost <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.16+ Link: https://patch.msgid.link/[email protected] (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643) Signed-off-by: Joonas Lahtinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joonas Lahtinen <[email protected]> Date: Wed Jul 1 10:30:30 2026 +0300 drm/i915/gem: Do not leak siblings[] on proto context error commit eed3de2acf6aa5154d49098b026710b646db67ee upstream. After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <[email protected]> Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: Faith Ekstrand <[email protected]> Cc: Simona Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: <[email protected]> # v5.15+ Signed-off-by: Joonas Lahtinen <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joonas Lahtinen <[email protected]> Date: Wed Jul 1 10:55:55 2026 +0300 drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU commit 2b56757a9a7456825eb668fde92299e01c5e2721 upstream. Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <[email protected]> Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: Faith Ekstrand <[email protected]> Cc: Simona Vetter <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: <[email protected]> # v5.15+ Signed-off-by: Joonas Lahtinen <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Sun Jul 5 16:02:25 2026 +0800 drm/i915/gt: use correct selftest config symbol [ Upstream commit a82f1bb8191aec98a971a2196136016ef70c0880 ] intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST, without the trailing "S", and the rest of i915 uses CONFIG_DRM_I915_SELFTEST. Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol, the IS_ENABLED() test is always false. Use the existing selftest symbol so the debug/selftest guarded path can be reached when selftests are enabled. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the Kconfig definition and the inconsistent guard in intel_engine_user.c. Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Pengpeng Hou <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 14a2012a490258f3f93857bc4f1b203405964be7) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emre Cecanpunar <[email protected]> Date: Wed Jul 15 01:04:30 2026 +0300 drm/i915/selftests: Fix GT PM sort comparators [ Upstream commit 612978b83f45bf7018815209db5395d759db6f26 ] Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 682ea2d28d18bb06f9fc663cb5ab7e80dc0e606a) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joonas Lahtinen <[email protected]> Date: Wed Jun 24 12:09:40 2026 +0300 drm/i915: Return NULL on error in active_instance commit 1e33f0de5fdcd09e51fdec1e5822448970b6420f upstream. Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <[email protected]> Fixes: bfaae47db3c0 ("drm/i915: make lockdep slightly happier about execbuf.") Cc: Maarten Lankhorst <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Simona Vetter <[email protected]> Cc: <[email protected]> # v5.13+ Signed-off-by: Joonas Lahtinen <[email protected]> Reviewed-by: Sebastian Brzezinka <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832) Signed-off-by: Joonas Lahtinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Sat Jun 6 15:56:06 2026 +0000 drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit() commit c3027973f692077a1b66a9fb26d6a7c46c0dc72c upstream. In nvkm_acr_oneinit(), nvkm_kmap(acr->wpr) is invoked unconditionally at line 309 to obtain a mapping reference. Additionally, when both acr->wpr_fw and acr->wpr_comp are present, a second nvkm_kmap() is called inside the conditional block. Both mappings are expected to be released by nvkm_done(acr->wpr) at line 320 before the function returns successfully. However, when a mismatch is detected during the loop within the conditional block, the function returns -EINVAL at line 318 without calling nvkm_done(). This results in a leak of the kmap reference(s) acquired earlier. Fix the issue by invoking nvkm_done(acr->wpr) prior to the early return to ensure proper release of the mapping references. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Wed Jun 10 18:01:28 2026 +0800 drm/nouveau: fix reversed error cleanup order in ucopy functions commit ab99ead646b1b833ecd57fe577a2816f2e848167 upstream. nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang <[email protected]> Cc: [email protected] Signed-off-by: Junrui Luo <[email protected]> Link: https://patch.msgid.link/SYBPR01MB7881484D91A6F80271415F71AF1A2@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Ondračka <[email protected]> Date: Wed Jun 10 10:32:45 2026 +0200 drm/radeon: fix r100_copy_blit for large BOs commit f896e86273dbbebb5eac966b4a201b5c62a02e9a upstream. r100_copy_blit() copies BOs as 1024-pixel-wide ARGB8888 blits, so one GPU page becomes one blit row. Large copies are split into chunks of at most 8191 rows. The kernel register header names the packet coordinate dwords SRC_Y_X and DST_Y_X. In the BITBLT_MULTI description in R5xx_Acceleration_v1.5.pdf docs, these correspond to [SRC_X1 | SRC_Y1] and [DST_X1 | DST_Y1], which are signed 13-bit coordinates in the -8192..8191 range. The old code kept SRC/DST_PITCH_OFFSET at the BO base and used SRC_Y_X/DST_Y_X as the chunk address, so large BO moves could exceed that coordinate range. Compute per-chunk SRC/DST_PITCH_OFFSET bases and emit zero source and destination coordinates. r100_copy_blit() already packs SRC/DST_PITCH_OFFSET as pitch plus base offset, so large chunk addresses belong there rather than in the coordinate fields. This fixes Prison Architect corruption with 4096x4096 mipped textures after they are evicted to GTT under memory pressure on RV530. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/6716 Acked-by: Christian König <[email protected]> Signed-off-by: Pavel Ondračka <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 87be26aee76239c6da03e599f238a426897f78ad) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergey Shtylyov <[email protected]> Date: Fri Jan 30 23:35:42 2026 +0300 drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video() commit 46c31e1604d121221167cb09380de8c7d53290b9 upstream. The result of cdn_dp_reg_write() is checked everywhere (with the error being logged by the callers) except one place in cdn_dp_config_video(). Add the missing result check, bailing out early on error... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Signed-off-by: Sergey Shtylyov <[email protected]> Cc: [email protected] Reviewed-by: Chaoyi Chen <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linmao Li <[email protected]> Date: Tue Jul 21 09:15:58 2026 +0800 drm/vc4: Prevent shader BO mappings from becoming writable commit 0c9e6367639548307d3f578f6943ce72c9d39087 upstream. vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.") Cc: [email protected] Reported-by: Sashiko <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Signed-off-by: Linmao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Sat Jun 20 21:43:34 2026 -0500 drm/virtio: bound EDID block reads to the response buffer commit 4e1a53892ba7f8a3e1da6bfc53c83ae7c812dccd upstream. virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. Fixes: b4b01b4995fb ("drm/virtio: add edid support") Cc: [email protected] Signed-off-by: Bryam Vargas <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ryosuke Yasuoka <[email protected]> Date: Mon Jul 13 22:01:00 2026 +0900 drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker [ Upstream commit d1b894c5bbb3fee0012bd14356286dc2384e8213 ] A probe-time deadlock can occur between the dequeue worker and drm_client_register(). During probe, drm_client_register() holds clientlist_mutex and calls the fbdev hotplug callback, which triggers an atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs() waiting for virtqueue space. The dequeue worker that would free that space calls virtio_gpu_cmd_get_display_info_cb(), which invokes drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting to acquire the same clientlist_mutex. Since wake_up() is only called after the resp_cb loop, the probe thread is never woken and both threads deadlock. Fix this by removing the hotplug notification from virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info) is still updated synchronously in the callback. For the init path, drm_client_register() already fires an initial hotplug when the client is registered, which picks up the connector state updated by display_info_cb. For the runtime config_changed path, add a wait_event_timeout() in config_changed_work_func() so that display_info_cb updates the connector data before the hotplug notification is sent. Also replace drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since virtio-gpu never calls drm_kms_helper_poll_init() and thus drm_helper_hpd_irq_event() always returns false without doing anything. Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client") Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224 Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e Suggested-by: Dmitry Osipenko <[email protected]> Signed-off-by: Ryosuke Yasuoka <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Tue Jun 23 14:33:14 2026 -0500 drm/vmwgfx: Validate vmw_surface_metadata::array_size commit a4f55260f7f7d4dc4d0ee55063dfb0c457b77991 upstream. This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata") Reported-by: Zero Day Initiative <[email protected]> Cc: [email protected] Signed-off-by: Ian Forbes <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christian Brauner <[email protected]> Date: Tue Jul 21 12:08:49 2026 +0200 exec: fix unsigned loop counter wrap in transfer_args_to_stack() commit 16cc4f5c1c4b9e45eca7f7deefa5410a292db599 upstream. The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 ("elf_fdpic_transfer_args_to_stack(): make it generic") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2. Link: https://patch.msgid.link/20260721-hochachtung-staumauer-pigmente-15d71f7d7d04@brauner Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reviewed-by: David Hildenbrand (Arm) <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Tue Jul 28 20:49:38 2026 +0000 exfat: validate cluster allocation bits of the allocation bitmap [ Upstream commit 79c1587b6cda74deb0c86fc7ba194b92958c793c ] syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use. Reported-by: [email protected] Tested-by: [email protected] Reviewed-by: Yuezhang Mo <[email protected]> Reviewed-by: Sungjong Seo <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> [Adapted to 6.6: replaced __le_long/lel_to_cpu word-level bitmap access with per-bit test_bit_le() calls, as __le_long and lel_to_cpu do not exist in 6.6. Uses same test_bit_le API as rest of exfat bitmap code.] Signed-off-by: Jay Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Wed Jul 22 12:07:57 2026 -0400 fbcon: Rename struct fbcon_ops to struct fbcon_par [ Upstream commit a6adbbc4c32a016146e117b1e9e5242724a75e10 ] The type struct fbcon_ops contains fbcon state and callbacks. As the callbacks will be removed from struct fbcon_ops, rename the data type to struct fbcon_par. Also rename the variables from ops to par. The _par postfix ("private access registers") is used throughout the fbdev subsystem for per-driver state. The fbcon pointer within struct fb_info is also named fbcon_par. Hence, the new naming fits existing practice. v2: - rename struct fbcon_ops to struct fbcon_par - fix build for CONFIG_FB_TILEBITTING=n (kernel test robot) - fix indention Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 84202754fb17 ("fbcon: Use correct type for vc_resize() return value") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiacheng Yu <[email protected]> Date: Wed Jul 22 12:07:58 2026 -0400 fbcon: Use correct type for vc_resize() return value [ Upstream commit 84202754fb1727dc3ee87f47104e4162ecc8ba3a ] The return value of vc_resize() is int, but fbcon_set_disp() stores it in an unsigned long variable. While the !ret check happens to work correctly by coincidence (negative values become large positive values), the types should match. Use int instead. Eliminates the following W=3 warning: drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_disp': drivers/video/fbdev/core/fbcon.c:1494:14: warning: implicit conversion from 'int' to 'unsigned long' [-Wconversion] Fixes: af0db3c1f898 ("fbdev: Fix vmalloc out-of-bounds write in fast_imageblit") Cc: [email protected] # v6.17+ Signed-off-by: Jiacheng Yu <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Wed Jul 22 19:47:08 2026 -0400 fbdev/efifb: Replace references to global screen_info by local pointer [ Upstream commit 8505e70821ade706f98f7114a2cbcd51326f7b82 ] Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <[email protected]> Tested-by: Sui Jingfeng <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Stable-dep-of: 9b6eaf101656 ("fbdev: efifb: fix memory leak in efifb_probe()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Wed Jul 22 19:47:09 2026 -0400 fbdev: efifb: fix memory leak in efifb_probe() [ Upstream commit 9b6eaf101656958397a6012bf43f6e2e42c9e5cb ] Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller, but the string is not freed in efifb_probe(). Fix that by freeing the option string after setup. Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") Cc: [email protected] Signed-off-by: Abdun Nihaal <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Tue Jul 7 23:04:54 2026 +0800 firewire: net: Fix fragmented datagram reassembly [ Upstream commit d52a13adbb8ccbab99cd3bad36804e87d8b5c052 ] fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: c76acec6d551 ("firewire: add IPv4 support") Signed-off-by: Ruoyu Wang <[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: Unnathi Chalicheemala <[email protected]> Date: Wed Jun 17 16:35:00 2026 -0700 firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() [ Upstream commit 8ae5f8e4836667fcaffdf2e3c6068b0a8b364dd8 ] ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input. Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Signed-off-by: Unnathi Chalicheemala <[email protected]> Link: https://patch.msgid.link/20260617-ffa_partition_nullptr_fix-v2-1-bc801b4ce34c@oss.qualcomm.com Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pushpendra Singh <[email protected]> Date: Wed Jul 8 12:53:39 2026 +0530 firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context [ Upstream commit a4447c0693830d5ecadd6e755cb7fdc55d86aacc ] The scmi_notify() function is called from interrupt context to queue received notification events onto a per-protocol kfifo. When the kfifo is full, it logs a warning via dev_warn() for every dropped event. Under conditions where the platform sends a burst of SCMI notifications faster than the deferred worker can drain the queue, this results in a flood of dev_warn() calls from IRQ context. Each call acquires the console lock and may execute blocking console writes, causing the CPU to be held in interrupt context for an extended period and leading to observable system stalls. Fix this by switching to dev_warn_ratelimited() to limit the frequency of log messages when the notification queue is full. This reduces console overhead in interrupt context and prevents CPU stalls caused by excessive logging, while still preserving diagnostic visibility. Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery") Signed-off-by: Pushpendra Singh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Mon Jul 27 19:34:36 2026 -0400 firmware_loader: introduce __free() cleanup hanler [ Upstream commit 8dde8fa0cc3edce73c050b9882d06c1a575f6402 ] Define cleanup handler using facilities from linux/cleanup.h to simplify error handling in code using firmware loader. This will allow writing code like this: int driver_update_firmware(...) { const struct firmware *fw_entry __free(firmware) = NULL; int error; ... error = request_firmware(&fw_entry, fw_name, dev); if (error) { dev_err(dev, "failed to request firmware %s: %d", fw_name, error); return error; } error = check_firmware_valid(fw_entry); if (error) return error; guard(mutex)(&instance->lock); error = use_firmware(instance, fw); if (error) return error; return 0; } Signed-off-by: Dmitry Torokhov <[email protected]> Acked-by: Luis Chamberalin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Stable-dep-of: d48795b5cd68 ("Input: ims-pcu - fix firmware leak in async update") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sebastian Alba Vives <[email protected]> Date: Tue Jul 21 14:59:09 2026 -0400 fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() [ Upstream commit fc3b071a7c8dc0f5d56defddf6e6fd5aaa3e1e27 ] afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX. Fixes: fa8dda1edef9 ("fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls support") Cc: [email protected] Signed-off-by: Sebastian Alba Vives <[email protected]> Reviewed-by: Xu Yilun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Reinette Chatre <[email protected]> Date: Wed Jul 29 12:57:53 2026 -0400 fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list [ Upstream commit b9f089723aee892efc77c349ae47a6b452b293c4 ] A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID. Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region") Signed-off-by: Reinette Chatre <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/551432dd7e624a862b8e58314c38aaba0afff3e9.1783377598.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amir Goldstein <[email protected]> Date: Tue Jul 14 00:09:31 2026 +0200 fs: preserve ACL_DONT_CACHE state in forget_cached_acl() commit 4b9a5458d02e214ef2b384124ca626e3e381d778 upstream. The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE. Fixes: facd61053cff1 ("fuse: fixes after adapting to new posix acl api") Cc: [email protected] Signed-off-by: Amir Goldstein <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Luis Henriques <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Sat Jul 18 20:31:20 2026 -0700 fscrypt: Add missing superblock check in find_or_insert_direct_key() commit b5fa40226e71c17847b9ff2816c6ca4133d0d994 upstream. The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block. Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references") Cc: [email protected] Reported-by: Sashiko <[email protected]> Closes: https://sashiko.dev/#/patchset/20260717044303.425265-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Wed Jul 29 08:25:39 2026 -0700 fscrypt: Avoid dynamic allocation in fscrypt_get_devices() commit 6fe4e4b8259e1330945b5f3c9476e08473b8e0e8 upstream. When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.) Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references") Cc: [email protected] Reported-by: Sashiko <[email protected]> Closes: https://sashiko.dev/#/patchset/20260713023708.9245-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tengda Wu <[email protected]> Date: Sat Jul 25 02:47:21 2026 +0000 ftrace: Add global mutex to serialize trace_parser access commit 7720b63bcef3f54c7fe288774b720a227d54a306 upstream. In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state. Fixes: e704eff3ff51 ("ftrace: Have set_graph_function handle multiple functions in one write") Fixes: 689fd8b65d66 ("tracing: trace parser support for function and graph") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Tengda Wu <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Doruk Tan Ozturk <[email protected]> Date: Thu Jul 16 22:35:00 2026 +0200 geneve: require CAP_NET_ADMIN in the device netns for changelink commit 8efb8f8bbb353b8f2fdf4f37534c6d96c9f69e01 upstream. A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5b861f6baa3a ("geneve: add rtnl changelink support") Cc: [email protected] Signed-off-by: Doruk Tan Ozturk <[email protected]> Reviewed-by: Fernando Fernandez Mancera <[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: Sergio Paracuellos <[email protected]> Date: Tue Jul 28 11:52:28 2026 -0400 gpio: mt7621: avoid corruption of shared interrupt trigger state [ Upstream commit 1781172526d1092323af443fa03f00e6de560401 ] The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks. Cc: [email protected] Reported-by: Sashiko <[email protected]> Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Sergio Paracuellos <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> [ Changed `guard(gpio_generic_lock_irqsave)(&rg->chip)` to `guard(spinlock_irqsave)(&rg->lock)` as the generic GPIO chip lock does not exist in this tree. ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Runyu Xiao <[email protected]> Date: Tue Jul 28 08:11:25 2026 -0400 gpio: tegra: do not call pinctrl for GPIO direction [ Upstream commit d3e91a95b2b0fc6336dbf3ec90d831a1654d2720 ] tegra_gpio_direction_input() and tegra_gpio_direction_output() already program the GPIO controller direction registers directly. The additional pinctrl_gpio_direction_input/output() calls do not add a Tegra pinctrl operation, because the Tegra pinmux ops provide GPIO request/free handling but no gpio_set_direction hook. The extra call still enters the pinctrl core and takes pctldev->mutex. Shared GPIO users can call the direction path while holding their per-line spinlock, so this otherwise redundant pinctrl direction call can sleep in an atomic context. This was found by our static analysis tool and then confirmed by manual review of tegra_gpio_probe(), the Tegra GPIO direction callbacks and the Tegra pinctrl ops. The reviewed path has a default non-sleeping struct gpio_chip while the direction callback still enters the pinctrl mutex path. A directed runtime validation kept the same non-sleeping chip registration and drove: gpio_shared_proxy_direction_output() gpiod_direction_output_raw_commit() tegra_gpio_direction_output() pinctrl_gpio_direction_output() Lockdep reported a sleep-in-atomic warning with the shared GPIO spinlock held and pinctrl_get_device_gpio_range() plus tegra_gpio_direction_output() on the stack. Do not mark the whole chip as can_sleep to paper over this: can_sleep describes whether get()/set() may sleep, and Tegra value access is MMIO. Remove the redundant pinctrl direction calls and keep pinctrl involvement in the existing request/free path. Fixes: 11da90541283 ("gpio: tegra: Fix offset of pinctrl calls") Cc: [email protected] Signed-off-by: Runyu Xiao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikko Perttunen <[email protected]> Date: Wed Jun 3 17:37:49 2026 +0900 gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings [ Upstream commit 266cddf7bd0f6c79b6c0633aef742a22bf70265b ] __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead. Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/linux-tegra/[email protected]/T/#u Signed-off-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Fri Jul 10 23:07:24 2026 +0000 gtp: check skb_pull_data() return in gtp1u_send_echo_resp() [ Upstream commit cd170f051dba9ac146fabcd1b91726487c0cb9fa ] gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9af41cc33471 ("gtp: Implement GTP echo response") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chenguang Zhao <[email protected]> Date: Wed Jul 22 10:53:53 2026 +0800 hinic: remove unused ethtool RSS user configuration buffers [ Upstream commit fe0c002928c6749b7f4a726f6f600f6dd70280ea ] rss_indir_user and rss_hkey_user are allocated and filled in __set_rss_rxfh() when the user configures RSS via ethtool, but nothing ever reads them. hinic_get_rxfh() fetches the state from the device, and the hardware is programmed from the original indir/key arguments. These buffers only leaked on driver unload. Drop the unused allocations, memcpys, and struct fields. Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool") Signed-off-by: Chenguang Zhao <[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: Sasha Levin <[email protected]>
Author: Eugene Shalygin <[email protected]> Date: Sun Jul 12 15:05:05 2026 +0200 hwmon: (asus-ec-sensors) add missed handle for ENOMEM [ Upstream commit 9813c1f49efeadbcb17e4a41972350ac783f9cac ] Add missing return value check in the setup function. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eugene Shalygin <[email protected]> Date: Sun Jul 12 13:05:03 2026 +0200 hwmon: (asus-ec-sensors) fix EC read intervals [ Upstream commit 60710b2af13b81da71b429d3f8b19dd70310729d ] Take INITIAL_JIFFIES into account when setting up next update time. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eugene Shalygin <[email protected]> Date: Sat Jul 11 09:42:07 2026 +0200 hwmon: (asus-ec-sensors) fix looping over banks while reading from EC [ Upstream commit e741d13cc2abfc6fccebe2008057aa52e285223e ] Do not assume there are only bank 0 and bank 1 available, just use '!=' for bank comparison. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guenter Roeck <[email protected]> Date: Tue Jul 7 17:52:54 2026 -0700 hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop [ Upstream commit 94c87871b051d7ad758828a805215a2ec194512a ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko <[email protected]> Fixes: 40c3a44542257 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Tue Apr 28 12:12:26 2026 +0800 hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop [ Upstream commit 9ab8656548cd737b98d0b19c4253aff8d68e97f4 ] hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after "io start" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0 CPU1 ==== ==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw) __hid_input_report() ... acquire driver_input_lock hid_report_raw_event() hidraw_report_event() ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guenter Roeck <[email protected]> Date: Tue Jul 7 18:00:32 2026 -0700 hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop [ Upstream commit 59d104b54b0b42e30fd2a68d24ee5c49dcc54d1e ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko <[email protected]> Fixes: 53e68c20aeb1e ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2") Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Mon Jul 20 19:58:26 2026 +0800 hwmon: occ: validate poll response sensor blocks [ Upstream commit 70e76e700fc6c46afb4e17aec099a1ea089b4a22 ] The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active. Fixes: aa195fe49b03 ("hwmon (occ): Parse OCC poll response") Signed-off-by: Pengpeng Hou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Tue Jul 21 15:48:28 2026 -0400 i2c: davinci: Unregister cpufreq notifier on probe failure [ Upstream commit e43f32816a1b1fe5a86279411626fe3a9be56d45 ] davinci_i2c_probe() registers a cpufreq transition notifier before adding the I2C adapter. If i2c_add_numbered_adapter() fails, the probe error path releases the device resources without unregistering the notifier. Add a dedicated error path to unregister the cpufreq notifier after i2c_add_numbered_adapter() fails. Fixes: 82c0de11b734 ("i2c: davinci: Add cpufreq support") Signed-off-by: Haoxiang Li <[email protected]> Cc: <[email protected]> # v2.6.36+ Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mingyu Wang <[email protected]> Date: Wed Jul 22 06:30:42 2026 -0400 i2c: i801: fix hardware state machine corruption in error path [ Upstream commit 10dd1a736d557e310a77117832874729a0175d57 ] A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired. Fixes: 1f760b87e54c ("i2c: i801: Call i801_check_pre() from i801_access()") Signed-off-by: Mingyu Wang <[email protected]> Cc: <[email protected]> # v6.3+ Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vincent Jardin <[email protected]> Date: Mon Jul 27 08:28:46 2026 -0400 i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) [ Upstream commit cb2fc37857693b55909fb77dc2c87cfbc1cdc476 ] SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support") Signed-off-by: Vincent Jardin <[email protected]> Cc: <[email protected]> # v3.16+ Acked-by: Oleksij Rempel <[email protected]> Acked-by: Carlos Song <[email protected]> Reviewed-by: Stefan Eichenberger <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-1-073ac9e103a5@free.fr Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stefan Eichenberger <[email protected]> Date: Mon Jul 27 08:28:45 2026 -0400 i2c: imx: separate atomic, dma and non-dma use case [ Upstream commit b460b15b3cc23ef3639cc51043bf8b2a70ca1878 ] Separate the atomic, dma and non-dma use case as a preparation step for moving the non-dma use case to the isr to avoid rescheduling while a transfer is in progress. Signed-off-by: Stefan Eichenberger <[email protected]> Reviewed-by: Frank Li <[email protected]> Acked-by: Oleksij Rempel <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Stable-dep-of: cb2fc3785769 ("i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jacob Keller <[email protected]> Date: Tue Jul 28 21:07:15 2026 +0000 i40e: remove read access to debugfs files [ Upstream commit 9fcdb1c3c4ba134434694c001dbff343f1ffa319 ] The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access. Fixes: 02e9c290814c ("i40e: debugfs interface") Reported-by: Kunwu Chan <[email protected]> Closes: https://lore.kernel.org/intel-wired-lan/[email protected]/ Reported-by: Wang Haoran <[email protected]> Closes: https://lore.kernel.org/all/CANZ3JQRRiOdtfQJoP9QM=6LS1Jto8PGBGw6y7-TL=BcnzHQn1Q@mail.gmail.com/ Reported-by: Amir Mohammad Jahangirzad <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jacob Keller <[email protected]> Reviewed-by: Dawid Osuchowski <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Kunwu Chan <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> [Adapted to 6.6: context conflict due to 6.6 using pf->vsi[pf->lan_vsi] vs i40e_pf_get_main_vsi(pf) in the removed read functions; resolution is simply to delete the 6.6 version of those functions.] Signed-off-by: Jay Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Sat Jun 6 16:01:55 2026 -0400 IB/mad: Drop unmatched RMPP responses before reassembly [ Upstream commit d2e52d610b9b09694261632340b801a421e0b0c5 ] Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request. Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation") Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito <[email protected]> Link: https://patch.msgid.link/3170ff3bc389a930bb1641f2caa394a0b2241579.1780774907.git.michael.bommarito@gmail.com Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marcin Szycik <[email protected]> Date: Fri Jul 17 11:53:28 2026 -0700 ice: fix LAG recipe to profile association [ Upstream commit d6da9b7d48599db078aea6144997a381f8d90d45 ] ice_init_lag() associates recipes to profiles, assuming that Link Aggregation-related profiles will always have profile ID lower than 70 (ICE_PROFID_IPV6_GTPU_IPV6_TCP_INNER). This value seems arbitrary and might not always be valid for some versions of DDP package, i.e. LAG profiles may have profile ID greater than 70. This would lead to misconfigured switch and LAG not working properly. Fix it by checking up to maximum profile ID. Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on bonded interface") Signed-off-by: Marcin Szycik <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Dave Ertman <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Temerkhanov <[email protected]> Date: Fri Jul 17 11:53:30 2026 -0700 ice: use READ_ONCE() to access cached PHC time commit 2915681b89f817677ab9f1166d95b595bc144f5f upstream. ptp.cached_phc_time is a 64-bit value updated by a periodic work item on one CPU and read locklessly on another. On 32-bit or non-atomic architectures this can result in a torn read. Use READ_ONCE() to enforce a single atomic load. Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: [email protected] Signed-off-by: Sergey Temerkhanov <[email protected]> Signed-off-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[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: Michael Bommarito <[email protected]> Date: Tue Jul 14 07:49:03 2026 -0400 ila: reload IPv6 header after pskb_may_pull in checksum adjust commit 92d3817649df2b0b6a008a686c8275c88d7ef594 upstream. ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers. Fixes: 33f11d16142b ("ila: Create net/ipv6/ila directory") Cc: [email protected] Signed-off-by: Michael Bommarito <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Antoine Tenart <[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: Dmitry Torokhov <[email protected]> Date: Mon Jul 27 19:34:37 2026 -0400 Input: ims-pcu - fix firmware leak in async update [ Upstream commit d48795b5cd6828d36b707e8d62fc9e5c90e004ab ] The firmware object was not being released if validation failed. Use __free(firmware) to ensure the firmware is always released. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: [email protected] Reported-by: Sashiko bot <[email protected]> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Seungjin Bae <[email protected]> Date: Wed Apr 8 09:03:59 2026 -0700 Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() [ Upstream commit 875115b82c295277b81b6dfee7debc725f44e854 ] The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver") Co-developed-by: Sanghoon Choi <[email protected]> Signed-off-by: Sanghoon Choi <[email protected]> Signed-off-by: Seungjin Bae <[email protected]> Link: https://patch.msgid.link/[email protected] [dtor: factor out resetting packet state, reset checksum as well] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Fri May 22 10:29:41 2026 -0700 Input: ims-pcu - fix logic error in packet reset [ Upstream commit 2c9b85a14abb4811e8d4773ccd13559e59792efb ] ims_pcu_reset_packet() incorrectly sets have_stx to true, which implies that the start-of-packet delimiter has already been received. This causes the protocol parser to skip waiting for the next STX byte and potentially process garbage data. Correctly set have_stx to false when resetting the packet state. Fixes: 875115b82c29 ("Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()") Cc: [email protected] Reported-by: Sashiko bot <[email protected]> Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Jul 15 15:08:51 2026 +0800 intel_th: fix MSC output device reference leak commit 761b785a0cfbce43761227bc42a7f984f31f8921 upstream. intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da ("intel_th: fix device leak on output open()") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops. Fixes: 95fc36a234da ("intel_th: fix device leak on output open()") Cc: stable <[email protected]> Signed-off-by: Guangshuo Li <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yitang Yang <[email protected]> Date: Wed Jul 22 20:45:51 2026 +0800 io_uring/rw: fix missing ERESTARTSYS conversion in read paths commit ab05caca123c6d0b41850b7c05b246e4dca4a770 upstream. Both read and write may receive internal restart error codes from the filesystem layer and should be converted to -EINTR. However, when multishot read support was added, the error code normalization was lost for both io_read() and io_read_mshot(). Extract the conversion into io_fixup_restart_res() and apply it in all three locations: io_rw_done(), io_read(), and io_read_mshot(). [ 6.6 doesn't have multishot read, drop the io_read_mshot() hunk and adapt io_rw_done() to the older calling convention ] Fixes: a08d195b586a ("io_uring/rw: split io_read() into a helper") Cc: [email protected] Signed-off-by: Yitang Yang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Yi <[email protected]> Date: Tue Jul 14 16:23:21 2026 +0800 iomap: correct the range of a partial dirty clear [ Upstream commit 88c26515313169806a412a362b32a1eca53d21bd ] The block range calculation in ifs_clear_range_dirty() is incorrect when partially clearing a range in a folio. We cannot clear the dirty bit of the first block or the last block if the start or end offset is not blocksize-aligned. This has not yet caused any issues since we always clear a whole folio in iomap_writeback_folio(). Fix this by rounding up the first block to blocksize alignment, and calculate the last block by rounding down (using truncation). Correct the nr_blks calculation accordingly. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance") Signed-off-by: Zhang Yi <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Joanne Koong <[email protected]> Reviewed-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Mon Jul 20 19:46:13 2026 +0800 iommu/amd: Bound the early ACPI HID map [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou <[email protected]> Reviewed-by: Ankit Soni <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Weinan Liu <[email protected]> Date: Tue Jul 21 13:12:57 2026 -0400 iommu/amd: Don't split flush for amd_iommu_domain_flush_all() [ Upstream commit 69fe699afe1afcb730164b86c228483c2da05f94 ] We have observed multiple full invalidations occurring during device detach when we are done using the vfio-device. blocked_domain_attach_device() -> detach_device() -> amd_iommu_domain_flush_all() -> amd_iommu_domain_flush_pages(..., CMD_INV_IOMMU_ALL_PAGES_ADDRESS) while (size != 0) { -> __domain_flush_pages( flush_size /* power of 2 flush_size */) -> domain_flush_pages_v1() -> build_inv_iommu_pages() -> build_inv_address() } build_inv_address() will trigger a full invalidation if the chunk size > (1 << 51). Consequently, the guest will issue multiple full invalidations for a single call to amd_iommu_domain_flush_all() Without this patch, we will see 10 time instead of 1 time full invalidations for every amd_iommu_domain_flush_all(). Cc: [email protected] Fixes: a270be1b3fdf ("iommu/amd: Use only natural aligned flushes in a VM") Suggested-by: Josef Bacik <[email protected]> Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Weinan Liu <[email protected]> Reviewed-by: Wei Wang <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Samiullah Khawaja <[email protected]> Reviewed-by: Suravee Suthikulpanit <[email protected]> Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guanghui Feng <[email protected]> Date: Thu Jul 16 22:16:22 2026 +0800 iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() [ Upstream commit 1e75a8255f11c81fb07e81e5029cfd75804350a0 ] need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued. Signed-off-by: Guanghui Feng <[email protected]> Fixes: 815b33fdc279 ("x86/amd-iommu: Cleanup completion-wait handling") Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li RongQing <[email protected]> Date: Tue Jul 21 17:34:10 2026 +0800 iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() [ Upstream commit 754f8efe45f87e3a9c6871b645b2f9d46d1b407b ] dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry. Fixes: 55ee5e67a59a ("iommu/vt-d: Add common code for dmar latency performance monitors") Signed-off-by: Li RongQing <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lu Baolu <[email protected]> Date: Thu Jul 16 13:35:53 2026 +0800 iommu/vt-d: Disallow SVA if page walk is not coherent commit 780dfed688622ea01be3c9c2c55eec2207f05e04 upstream. Hardware implementations report Scalable-Mode Page-walk Coherency Support via the SMPWCS field in the extended capability register. If the hardware does not support page-walk coherency, a clflush is required every time the page table entries (which are walked by the IOMMU hardware) are updated. In the SVA case, page tables are managed by the CPU mm core, not by the IOMMU driver. Because the IOMMU driver has no way of knowing whether the CPU page table management code has ensured coherency via clflush, the driver must deny SVA if the hardware does not support coherent paging. Fixes: ff3dc6521f78 ("iommu/vt-d: Fix CPU and IOMMU SVM feature matching checks") Cc: [email protected] Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Samiullah Khawaja <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Tue Jul 28 14:07:42 2026 -0400 ipmi: fix refcount leak in i_ipmi_request() [ Upstream commit a3f3859cecacb64f18fd446271ece9a3b3f2d4de ] When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref. Cc: [email protected] Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling") Signed-off-by: Wentao Liang <[email protected]> Message-ID: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> [ changed `free_ipmi_user` to `free_user` in the two added `kref_put()` calls ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Weiming Shi <[email protected]> Date: Sat Jul 4 10:14:21 2026 -0700 ipv4: fib: free fib_alias with kfree_rcu() on insert error path [ Upstream commit f2f152e94a67bc746afaf05a1b2702c195553112 ] fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie. Fixes: a6c76c17df02 ("ipv4: Notify route after insertion to the routing table") Reported-by: Xiang Mei <[email protected]> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 22 10:42:36 2026 +0000 ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup [ Upstream commit 853e164c2b321f0711361bc23505aaeb7dc432c3 ] When Linux forwards a packet and needs to generate an ICMP error, icmp_route_lookup() performs a reverse-path relookup. For non-local destinations, it performs a decoy lookup to find the expected egress interface (rt2->dst.dev) before validating the path with ip_route_input(). Currently, the decoy flow structure (fl4_2) only sets .daddr = fl4_dec.saddr, leaving .saddr, .flowi4_dscp, .flowi4_proto, .flowi4_mark, .flowi4_oif, .fl4_sport, .fl4_dport, and .flowi4_uid zeroed out. When policy routing rules (such as ip rule add from $SRC lookup 100, or dscp/fwmark/ipproto/port rules, or VRF bindings) are configured: 1. The decoy lookup fails to match the policy rule because saddr and other key flow selectors are missing in fl4_2. 2. It resolves a route using the default table instead, returning an incorrect egress netdev. 3. Passing the wrong netdev to ip_route_input() causes strict reverse-path filtering (rp_filter=1) to fail, logging false-positive "martian source" warnings and causing the relookup to fail. Fix this by initializing fl4_2 from fl4_dec and: - Swapping source/destination IP addresses. - Swapping L4 ports for transport protocols with ports (TCP, UDP, SCTP, DCCP) so port-based policy routing matches correctly. Non-port protocols (such as ICMP or GRE) leave the flowi_uli union fields intact to prevent corruption. - Setting .flowi4_oif = l3mdev_master_ifindex(route_lookup_dev) to ensure VRF routing tables are respected. - Setting .flowi4_flags |= FLOWI_FLAG_ANYSRC to allow output route lookups for non-local source IP addresses. - Using __ip_route_output_key() instead of ip_route_output_key() for fl4_2 so that raw FIB routing is used without triggering spurious XFRM policy lookups on the decoy flow (the actual XFRM lookup is performed later using fl4_dec). Fixes: 415b3334a21a ("icmp: Fix regression in nexthop resolution during replies.") Reported-by: Muhammad Ziad <[email protected]> Closes: https://lore.kernel.org/netdev/CAOAwikA60AYKdFr_UDLyja3oU4hqyAE7uFZWqum5uRdaQsgRYg@mail.gmail.com/ Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Weiming Shi <[email protected]> Date: Wed Jul 29 12:08:56 2026 +0300 ipv6: ndisc: fix NULL deref in accept_untracked_na() commit d186e942365acece7c56d39da05dd63bf95b280a upstream. accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev) and dereferences idev->cnf.accept_untracked_na without a NULL check, even though its only caller ndisc_recv_na() already fetched and NULL-checked idev for the same device. Both reads of dev->ip6_ptr run in the same RCU read-side critical section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown() without the synchronize_net() that orders the unregister path, so the re-fetch returns NULL and oopses: BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974) Read of size 4 at addr 0000000000000364 Call Trace: <IRQ> ndisc_recv_na (net/ipv6/ndisc.c:974) icmpv6_rcv (net/ipv6/icmp.c:1193) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479) ip6_input_finish (net/ipv6/ip6_input.c:534) ip6_input (net/ipv6/ip6_input.c:545) ip6_mc_input (net/ipv6/ip6_input.c:635) ipv6_rcv (net/ipv6/ip6_input.c:351) </IRQ> It is reachable by an unprivileged user via a network namespace. Pass the caller's already validated idev instead of re-fetching it; the idev stays alive for the whole RCU critical section, so it is safe even after dev->ip6_ptr has been cleared. Fixes: aaa5f515b16b ("net: ipv6: new accept_untracked_na option to accept na only if in-network") Reported-by: Xiang Mei <[email protected]> Signed-off-by: Weiming Shi <[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: Alexander Martyniuk <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Thu Jul 30 03:00:26 2026 +0800 ksmbd: bound DACL dedup walk to copied ACEs commit 58d97fcd0bf1aee694e244cc28635b9df95b543b upstream. set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original "input DACL had NT ACEs" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL. Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Montgomery <[email protected]> Date: Fri Jul 3 15:26:41 2026 -0400 ksmbd: defer destroy_previous_session() until after NTLM authentication commit c74801ee524f477c174a1899782b6c3b6918d407 upstream. In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Link: https://lore.kernel.org/linux-cifs/[email protected]/ Signed-off-by: James Montgomery <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qihang <[email protected]> Date: Thu Jul 9 22:49:55 2026 +0800 ksmbd: pin conn during async oplock break notification [ Upstream commit aa5d8f3f96aa11a4a54ce993c11ce8af11c546f9 ] smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern. Fixes: 3aa660c05924 ("ksmbd: prevent connection release during oplock break notification") Signed-off-by: Qihang <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Guan <[email protected]> Date: Thu Jul 30 03:00:24 2026 +0800 ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL commit bbf0a8e931204ecdab494a88d43b0a24a04285c5 upstream. check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c). Fixes: 299f962c0b02 ("ksmbd: use check_add_overflow() to prevent u16 DACL size overflow") Assisted-by: atomcode:glm-5.2 Assisted-by: Codex:gpt-5.5 Cc: [email protected] Signed-off-by: Wentao Guan <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Thu Jul 30 03:00:29 2026 +0800 ksmbd: validate ACE size against SID sub-authorities commit 5152c6d49e3fd4e9f2e857c57527aead752f1f87 upstream. set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths. Reported-by: LocalHost <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Mon Jul 13 21:55:10 2026 +0000 ksmbd: validate compound request size before reading StructureSize2 [ Upstream commit 15b38176fd1530372905c602fde51fe89ec8c877 ] When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haofeng Li <[email protected]> Date: Thu Jul 30 03:00:22 2026 +0800 ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl commit 47f0b34f6bc98ed85bfdc293e8f3e432ec24958d upstream. set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl(). Signed-off-by: Haofeng Li <[email protected]> Reviewed-by: ChenXiaoSong <[email protected]> Suggested-by: Namjae Jeon <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Wentao Guan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Matlack <[email protected]> Date: Thu Jul 30 08:15:40 2026 -0400 KVM: Introduce vcpu->wants_to_run [ Upstream commit a6816314af5749cd88944bfdceb270c627cdf348 ] Introduce vcpu->wants_to_run to indicate when a vCPU is in its core run loop, i.e. when the vCPU is running the KVM_RUN ioctl and immediate_exit was not set. Replace all references to vcpu->run->immediate_exit with !vcpu->wants_to_run to avoid TOCTOU races with userspace. For example, a malicious userspace could invoked KVM_RUN with immediate_exit=true and then after KVM reads it to set wants_to_run=false, flip it to false. This would result in the vCPU running in KVM_RUN with wants_to_run=false. This wouldn't cause any real bugs today but is a dangerous landmine. Signed-off-by: David Matlack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Stable-dep-of: e800decd9c0a ("KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hyunwoo Kim <[email protected]> Date: Fri Jul 17 12:30:11 2026 +0200 KVM: nVMX: Hide shadow VMCS right after VMCLEAR commit 622ebfac01ba4f9c0060cebd41257fe46fc4a0b3 upstream. free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed. Fixes: 355f4fb1405e ("kvm: nVMX: VMCLEAR an active shadow VMCS after last use") Cc: [email protected] Signed-off-by: Hyunwoo Kim <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nikunj A Dadhania <[email protected]> Date: Wed Jul 15 06:35:06 2026 +0000 KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug commit 25f744ffa0c8e799e06250ce2e618367b166b0d4 upstream. If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle. Fixes: 774c47f1d78e ("[PATCH] KVM: cpu hotplug support") Reported-by: Chandrakanth Silveru <[email protected]> Tested-by: Srikanth Aithal <[email protected]> Reviewed-by: K Prateek Nayak <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Signed-off-by: Nikunj A Dadhania <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Phil Rosenthal <[email protected]> Date: Sat Jul 18 12:50:23 2026 -0400 KVM: x86/mmu: Fix use-after-free on vendor module reload commit 52f2f7c30126037975389aa04d24c506a5177c35 upstream. mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report. Fixes: cb498ea2ce1d ("KVM: Portability: Combine kvm_init and kvm_init_x86") Cc: [email protected] Signed-off-by: Phil Rosenthal <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon Jul 13 08:15:33 2026 -0700 KVM: x86: Check for invalid/obsolete root *after* making MMU pages available commit 2abd5287f08319fa35764566b15c6e22cb1068db upstream. Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately. Reported-by: Hyunwoo Kim <[email protected]> Fixes: f95eec9bed76 ("KVM: x86/mmu: Don't put invalid SPs back on the list of active pages") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Venkatesh Srinivas <[email protected]> Date: Thu Jul 30 08:15:41 2026 -0400 KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN [ Upstream commit e800decd9c0ac4349bcd8f8f9b29fd21fe93165e ] On Intel platforms with a VMX preemption timer and APICv, if a VMM calls KVM_GET_LAPIC before KVM_GET_MSRS to save the vCPU state, it is possible to lose a pending timer interrupt. If the thread running these ioctls is migrated to another core after calling KVM_GET_LAPIC but before KVM_GET_MSRS and the guest is using their LAPIC timer in TSC-deadline mode, not only does the save LAPIC state not carry the pending interrupt, the TSCDEADLINE MSR will be zeroed. After migration across CPUs, KVM_GET_MSRS calls vcpu_load, posting the interrupt and clearing the MSR: vcpu_load() -> kvm_arch_vcpu_load() -> kvm_lapic_restart_hv_timer() -> start_hv_timer() -> apic_timer_expired() -> kvm_apic_inject_pending_timer_irqs() . post interrupt into the LAPIC state . clear IA32_TSCDEADLINE The saved LAPIC state will be missing the pending interrupt and the saved MSR will be zero. Oops. Fix by only posting an interrupt when we're attempting to enter the guest (vcpu->wants_to_run == true), not for vcpu_load from other paths. Assisted-by: gemini:gemini-3.1-pro-preview Debugged-by: David Matlack <[email protected]> Debugged-by: Sean Christopherson <[email protected]> Debugged-by: Jim Mattson <[email protected]> Debugged-by: James Houghton <[email protected]> Signed-off-by: Venkatesh Srinivas <[email protected]> Message-ID: <[email protected]> Reviewed-by: James Houghton <[email protected]> Reviewed-by: Chao Gao <[email protected]> Cc: [email protected] Fixes: ae95f566b3d2 ("KVM: X86: TSCDEADLINE MSR emulation fastpath", 2020-05-15) Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douya Le <[email protected]> Date: Sun Jun 7 17:35:49 2026 +0800 libceph: bound get_version reply decode to front len commit d3c32939fa0e3ee9b883b9a0fd1972c5c444e3d0 upstream. handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. Cc: [email protected] Fixes: 513a8243d67f ("libceph: mon_get_version request infrastructure") Reported-by: Yuan Tan <[email protected]> Reported-by: Zhengchuan Liang <[email protected]> Reported-by: Xin Liu <[email protected]> Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Raphael Zimmer <[email protected]> Date: Wed May 27 16:06:17 2026 +0200 libceph: Fix multiplication overflow in decode_new_up_state_weight() commit 98917a499ec7064c14fc56d180a4fd636fc2784c upstream. If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ] Cc: [email protected] Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals") Signed-off-by: Raphael Zimmer <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhao Zhang <[email protected]> Date: Fri Jun 19 15:40:03 2026 +0800 libceph: guard missing CRUSH type name lookup commit bbeae12fda3384a90fbebc8a19ba9d33f85b5361 upstream. Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to "not local". [ idryomov: add WARN_ON_ONCE ] Cc: [email protected] Fixes: 117d96a04f00 ("libceph: support for balanced and localized reads") Reported-by: Yuan Tan <[email protected]> Reported-by: Zhengchuan Liang <[email protected]> Reported-by: Xin Liu <[email protected]> Assisted-by: Codex:GPT-5.4 Signed-off-by: Zhao Zhang <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuangpeng Bai <[email protected]> Date: Mon Jun 29 13:14:22 2026 -0400 libceph: refresh auth->authorizer_buf{,_len} after authorizer update commit 937d61f86d377a3aa578adae7a3dfcecdddf9d89 upstream. ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer. Cc: [email protected] Fixes: 0bed9b5c523d ("libceph: add update_authorizer auth method") Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Shuangpeng Bai <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Raphael Zimmer <[email protected]> Date: Fri May 29 09:42:57 2026 +0200 libceph: Reject monmaps advertising zero monitors commit 40480eee361ed9676b3f844d532ac28b47251634 upstream. A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop "log output for unusual values of num_mon" part ] Cc: [email protected] 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: Douya Le <[email protected]> Date: Fri May 29 16:11:44 2026 +0800 libceph: reject zero bucket types in crush_decode commit 05f90284223381005d6bcddab3fda4a97f9c3401 upstream. CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper. Cc: [email protected] Fixes: f24e9980eb86 ("ceph: OSD client") Reported-by: Yuan Tan <[email protected]> Reported-by: Zhengchuan Liang <[email protected]> Reported-by: Xin Liu <[email protected]> Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douya Le <[email protected]> Date: Mon Jun 15 14:31:06 2026 +0800 libceph: remove debugfs files before client teardown commit e4c804726c4afce3ba648b982d564f6af2cfa328 upstream. ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown. Cc: [email protected] Fixes: 76aa844d5b2f ("ceph: debugfs") Reported-by: Yuan Tan <[email protected]> Reported-by: Zhengchuan Liang <[email protected]> Reported-by: Xin Liu <[email protected]> Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Aug 3 11:15:40 2026 +0200 Linux 6.6.148 Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Wentao Guan <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Ron Economos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Mon Jul 27 23:02:02 2026 -0400 locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() [ Upstream commit 89038cc87d80c77e7aa6f42a64b2573b74af339f ] rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1 T2 spin_lock(&p->lock); rcu_read_lock(); invalidate(p); p = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL); if (!p) return; spin_unlock(&p->lock); spin_lock(&p->lock) lock(&lock->lock); rcu_read_lock(); kfree_rcu(p); rcu_read_unlock(); .... spin_unlock(&p->lock) rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); UAF -> rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled. Fixes: 0f383b6dc96e ("locking/spinlock: Provide RT variant") Reported-by: [email protected] Decoded-by: Jann Horn <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Acked-by: Al Viro <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/87jyrud75z.ffs@fw13 Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haoran Jiang <[email protected]> Date: Thu Jul 23 22:27:30 2026 +0800 LoongArch: Fix oops during single-step debugging commit 73555fdab5e1e4f24ca000c41a616b34edf4b55d upstream. When entering KDB via a breakpoint and then performing single-step debugging, an oops is triggered. Now during single-step debugging, kdb_local() expects the reason to be KDB_REASON_SSTEP, but it is actually KDB_REASON_OOPS. In kdb_stub(), when determining the reason, the ex_vector for single-step should be 0, as already implemented on other architectures such as arm64 and riscv. Before the patch: [112]kdb> ss Entering kdb (current=0x900020009f520000, pid 10661) on processor 112 Oops: (null) due to oops @ 0x90000000005b57a4 Cc: [email protected] Signed-off-by: Haoran Jiang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Casey Schaufler <[email protected]> Date: Thu Jul 23 10:19:19 2026 -0400 lsm: infrastructure management of the sock security [ Upstream commit 2aff9d20d50ac45dd13a013ef5231f4fb8912356 ] Move management of the sock->sk_security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Acked-by: Paul Moore <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: John Johansen <[email protected]> Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Casey Schaufler <[email protected]> [PM: subject tweak] Signed-off-by: Paul Moore <[email protected]> Stable-dep-of: 56acfeb10019 ("selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ibrahim Hashimov <[email protected]> Date: Tue Jul 21 23:12:28 2026 +0200 mac802154: hold an interface reference across the scan worker commit 234e5e898b713bc0b3a631b6f002897f43d046c8 upstream. mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit. Fixes: 57588c71177f ("mac802154: Handle passive scanning") Cc: [email protected] Signed-off-by: Ibrahim Hashimov <[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: Doruk Tan Ozturk <[email protected]> Date: Thu Jul 16 21:34:23 2026 +0200 mac802154: llsec: reject frames shorter than the authentication tag commit fd3a3f28ed60c6af4b2a39933b151d6b27842c3b upstream. llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as assoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed. Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method") Cc: [email protected] Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Doruk Tan Ozturk <[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: Doruk Tan Ozturk <[email protected]> Date: Wed Jul 15 10:20:21 2026 +0200 mctp: serial: handle zero-length frames to prevent rx buffer overflow commit 793b9b729f1e8de57be8c8daf1a9838be96cabed upstream. The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: if (c > MCTP_SERIAL_FRAME_MTU) { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0; dev->rxstate = STATE_DATA; ... } A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is tested: dev->rxbuf[dev->rxpos] = c; dev->rxpos++; dev->rxstate = STATE_DATA; if (dev->rxpos == dev->rxlen) { dev->rxpos = 0; dev->rxstate = STATE_TRAILER; } With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding") Cc: [email protected] Suggested-by: Jeremy Kerr <[email protected]> Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk <[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: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Mon May 11 20:12:06 2026 +0300 media: airspy: Return queued buffers on start_streaming() failure commit 04344d0b4929caa94c0df72f767752aa0935ef5d upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Carlier <[email protected]> Date: Sat Mar 28 11:23:30 2026 +0000 media: aspeed: fix missing of_reserved_mem_device_release() on probe failure commit 253c8ef7d57da0c74db251f385324faaa5ae2257 upstream. aspeed_video_init() calls of_reserved_mem_device_init() to associate reserved memory regions with the device. When aspeed_video_setup_video() subsequently fails in aspeed_video_probe(), the error path frees the JPEG buffer and unprepares the clocks but does not release the reserved memory association, leaking the rmem_assigned_device entry on the global list. The normal remove path already calls of_reserved_mem_device_release() correctly; only the probe error path was missing it. Add the missing of_reserved_mem_device_release() call to the aspeed_video_setup_video() failure cleanup. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Cc: [email protected] Signed-off-by: David Carlier <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Fri Apr 24 23:36:01 2026 +0900 media: cec: seco: unregister adapter on IR probe failure commit c3a78691be8245e52ced489f268e413f18061ac2 upstream. If secocec_ir_probe() fails after cec_register_adapter() succeeds, probe returns an error and the driver remove callback is not called. The current unwind path unregisters the notifier and then falls through to cec_delete_adapter(), which violates the CEC adapter lifetime rules after a successful registration. Add a registered-adapter unwind path that unregisters the notifier and the adapter instead. Fixes: daef95769b3a ("media: seco-cec: add Consumer-IR support") Cc: [email protected] Signed-off-by: Myeonghun Pak <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Wed May 6 21:41:16 2026 +0900 media: cedrus: clean up media device on probe failure commit 2c869b6969f3061cbbdab587f4c0a88bd7fc3cc9 upstream. cedrus_probe() initializes the media device before registering the video device, the media controller, and the media device. If any of those later steps fails, probe returns without calling media_device_cleanup(), so the media device internals initialized by media_device_init() are left behind. Add a media-device cleanup label to the probe unwind path and route video registration failures through it as well. Fixes: 50e761516f2b8c ("media: platform: Add Cedrus VPU decoder driver") Cc: [email protected] Reviewed-by: Paul Kocialkowski <[email protected]> Co-developed-by: Ijae Kim <[email protected]> Signed-off-by: Ijae Kim <[email protected]> Signed-off-by: Myeonghun Pak <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Samuel Holland <[email protected]> Date: Tue Apr 7 01:14:02 2026 +0300 media: cedrus: Fix missing cleanup in error path commit d99732334aaf33b9f93926b70b6a11c2cef3de39 upstream. According to the documentation struct v4l2_fh has to be cleaned up with v4l2_fh_exit() before being freed. [1] Currently there is no actual bug here, when v4l2_fh_exit() isn't called. v4l2_fh_exit() in this case only destroys internal mutex. But it may change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced. 1. https://docs.kernel.org/driver-api/media/v4l2-fh.html Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Andrey Skvortsov <[email protected]> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: [email protected] Acked-by: Paul Kocialkowski <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Tue Mar 24 16:08:56 2026 +0800 media: cedrus: skip invalid H.264 reference list entries commit 10358ea986c3c85516d1c8206486464f79d36e76 upstream. Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries. Fixes: e000e1fa4bdbd ("media: uapi: h264: Update reference lists") Cc: [email protected] Signed-off-by: Pengpeng Hou <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Mon Mar 30 11:37:27 2026 +0200 media: cx231xx: fix devres lifetime commit 7d6358ab02866e5b7ed8d3a00805297617bbb0ec upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind. Fixes: 184a82784d50 ("[media] cx231xx: use devm_ functions to allocate memory") Cc: [email protected] # 3.17 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wang Jun <[email protected]> Date: Fri Mar 20 15:04:53 2026 +0800 media: cx23885: add ioremap return check and cleanup commit a0701e387b46e2481c05b47f1235b954bfc2af3e upstream. Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure. Fixes: d19770e5178a ("V4L/DVB (6150): Add CX23885/CX23887 PCIe bridge driver") Cc: [email protected] Signed-off-by: Wang Jun <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Fri Apr 17 14:53:30 2026 +0800 media: marvell-cam: fix missing pci_disable_device() on remove commit 033ff0420e4c9c240ae5523fff39770298efa964 upstream. During manual code audit, we found that cafe_pci_probe() enables the PCI device with pci_enable_device(), and its probe error path properly calls pci_disable_device() on failure. However, cafe_pci_remove() tears down the controller and frees the driver data without disabling the PCI device, leaving the remove path inconsistent with probe cleanup. Add the missing pci_disable_device() call to cafe_pci_remove(). Fixes: abfa3df36c01 ("[media] marvell-cam: Separate out the Marvell camera core") Cc: [email protected] Signed-off-by: Guangshuo Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anand Moon <[email protected]> Date: Wed May 20 10:10:41 2026 +0530 media: meson: vdec: Fix memory leak in error path of vdec_open commit 940f161f734b25f175a95d2684c2021f6323693a upstream. The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm "v4l_id", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70 Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: [email protected] Signed-off-by: Anand Moon <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Mon May 11 20:12:07 2026 +0300 media: msi2500: Return queued buffers on start_streaming() failure commit 7201c17786a498497bca57752883b90914d405ac upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 977e444f59ad ("[media] Mirics MSi3101 SDR Dongle driver") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Thu May 7 12:13:16 2026 +0800 media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe commit 567418eedd25b3d86d489807682030b4b98b73d9 upstream. Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm "(udev-worker)", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: [email protected] Signed-off-by: Xiaolei Wang <[email protected]> Reviewed-by: Frank Li <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Thu May 7 12:13:18 2026 +0800 media: nxp: imx8-isi: Clean up already-initialized pipes on probe failure commit d970b27cc48ec42f8a72bc3a4a4ad2e5c7a36395 upstream. When mxc_isi_pipe_init() fails partway through the channel loop or when mxc_isi_v4l2_init() fails, the already initialized pipes are not cleaned up. Fix this by calling mxc_isi_pipe_cleanup() for each already-initialized pipe in the err_xbar error path. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: [email protected] Signed-off-by: Xiaolei Wang <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Thu May 7 12:13:17 2026 +0800 media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init error path commit 8262de0663318124824aaafd97ddb5d7bb53bd77 upstream. After v4l2_subdev_init_finalize() succeeds in mxc_isi_pipe_init(), if platform_get_irq() or devm_request_irq() fails, the error path jumps to a label that only calls media_entity_cleanup() and mutex_destroy(), missing the v4l2_subdev_cleanup() call needed to free the subdev active state allocated by v4l2_subdev_init_finalize(). Add an error_subdev label that calls v4l2_subdev_cleanup() before falling through to the existing error cleanup. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: [email protected] Signed-off-by: Xiaolei Wang <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guoniu Zhou <[email protected]> Date: Mon Mar 23 16:33:30 2026 +0800 media: nxp: imx8-isi: Fix potential out-of-bounds issues commit 57a7ec5c9f38ce6c4d6209c4b75c8e57e1fea6cf upstream. The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: [email protected] Reviewed-by: Frank Li <[email protected]> Signed-off-by: Guoniu Zhou <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guoniu Zhou <[email protected]> Date: Mon Mar 23 16:33:31 2026 +0800 media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding commit 5eb54da3f874b44149556542d949909898865e29 upstream. The ISI hardware rounds the actual output size up to an integer, as described in i.MX93 Reference Manual section 57.7.8 (Channel 0 Scale Factor). The scale factor must be calculated to ensure the theoretical output value rounds up to exactly the desired size. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: [email protected] Signed-off-by: Guoniu Zhou <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Apr 28 16:50:08 2026 +0200 media: pci: dm1105: Free allocated workqueue commit 1a65db225b25bb8c8febf16974c060e0cc242eb9 upstream. Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak. Fixes: 519a4bdcf822 ("V4L/DVB (11984): Add support for yet another SDMC DM1105 based DVB-S card.") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Wed May 13 08:42:44 2026 +0300 media: pwc: Drain fill_buf on start_streaming() failure commit 906e410dcffbbd99fb4081abab817a830033aa28 upstream. pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 ("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 885fe18f5542 ("[media] pwc: Replace private buffer management code with videobuf2") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Mon May 11 20:12:08 2026 +0300 media: pwc: Return queued buffers on start_streaming() failure commit 975b2ee20e569d47821e4f6c9761b4664d48a6a4 upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: ceede9fa8939 ("[media] pwc: Fix locking") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Wed May 13 16:02:37 2026 +0900 media: radio-si476x: Unregister v4l2_device on probe failure commit 436a693af04ffb889aaf87cb69ec1f2b21d3569c upstream. si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls. Fixes: b879a9c2a755 ("[media] v4l2: Add a V4L2 driver for SI476X MFD") Cc: [email protected] Co-developed-by: Ijae Kim <[email protected]> Signed-off-by: Ijae Kim <[email protected]> Signed-off-by: Myeonghun Pak <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Wed Apr 22 20:17:34 2026 +0530 media: rtl2832: fix use-after-free in rtl2832_remove() commit 680daf40a82d483949f87f0d8f98639dc47e610c upstream. cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final. Fixes: cddcc40b1b15 ("[media] rtl2832: convert to use an explicit i2c mux core") Cc: [email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=019ced393ab913002b75 Signed-off-by: Deepanshu Kartikey <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Mon May 11 20:12:09 2026 +0300 media: rtl2832_sdr: Return queued buffers on start_streaming() failure commit 33ca0aab6f4bd90921fc1395478f38f72c4d19af upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here. Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ma Ke <[email protected]> Date: Thu Apr 2 15:35:29 2026 +0800 media: saa7134: Fix a possible memory leak in saa7134_video_init1 commit f86ed548386e3050e5f8f25b450d09dc009d9a88 upstream. In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review. Signed-off-by: Ma Ke <[email protected]> Cc: [email protected] Fixes: a00e68888d5d ("[media] saa7134: move saa7134_pgtable to saa7134_dmaqueue") Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Sun Apr 26 21:43:49 2026 +0900 media: stm32: dcmi: unregister notifier on probe failure commit 084973ebd67b28f0945c5d45408f86c58b540110 upstream. dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. Signed-off-by: Myeonghun Pak <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Cc: [email protected] [hverkuil: added Fixes tag] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Valery Borovsky <[email protected]> Date: Mon May 11 20:12:11 2026 +0300 media: sun4i-csi: Return queued buffers on start_streaming() failure commit bbba3e260a62810a717b4442a3bb96d0ec0f6309 upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Cc: [email protected] Signed-off-by: Valery Borovsky <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hungyu Lin <[email protected]> Date: Thu May 7 02:22:13 2026 +0000 media: tegra-video: vi: fix invalid u32 return value in format lookup commit d5b50055338e131a1a99f923ebb0361974a00f36 upstream. tegra_get_format_fourcc_by_idx() returns a u32 but uses -EINVAL to signal an out-of-bounds index. This results in a large unsigned value being returned, which may be interpreted as a valid fourcc. Returning 0 is not a valid fourcc either. This condition should never happen, so use WARN_ON_ONCE() to catch unexpected out-of-bounds access and return a valid fallback format instead. Suggested-by: Hans Verkuil <[email protected]> Fixes: 3d8a97eabef0 ("media: tegra-video: Add Tegra210 Video input driver") Cc: [email protected] Reviewed-by: Luca Ceresoli <[email protected]> Signed-off-by: Hungyu Lin <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Myeonghun Pak <[email protected]> Date: Sun Apr 26 22:16:31 2026 +0900 media: ti: vpe: unwind v4l2 device registration on probe error commit e0f1c9a90ef665f2587c274a8fed59f2dfc575a6 upstream. If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register(). Fixes: 4d59c7d45585 ("media: ti-vpe: vpe: Add missing null pointer checks") 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: Yemike Abhilash Chandra <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergey Shtylyov <[email protected]> Date: Fri May 1 23:28:31 2026 +0300 media: v4l2-ctrls-request: add NULL check in v4l2_ctrl_request_complete() commit caced3578bf9f104a4aaad8f46c4c719e705d9a6 upstream. If CONFIG_MEDIA_CONTROLLER is undefined, media_request_object_find() will always return NULL, so its 2nd call in v4l2_ctrl_request_complete() would fail as well as the 1st one and thus cause hdl to have a wrong value (at the top of memory) and list_for_each_entry() to iterate over the garbage data located there. Add NULL check for the 2nd call and place the error cleanup at the end of v4l2_ctrl_request_complete()... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: c3bf5129f339 ("media: v4l2-ctrls: always copy the controls on completion") Cc: [email protected] Signed-off-by: Sergey Shtylyov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Tue Mar 24 11:13:26 2026 +0800 media: v4l2-ctrls: validate HEVC active reference counts commit afbe4bc252d90a6f8fad869b06d5430f615f22f9 upstream. HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts. Fixes: d395a78db9eab ("media: hevc: Add decode params control") Cc: [email protected] Signed-off-by: Pengpeng Hou <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zile Xiong <[email protected]> Date: Fri Mar 20 14:54:45 2026 +0800 media: vb2: use ssize_t for vb2_read/vb2_write commit a562d6dc86bdfdd299e1b4734977a8d63e803583 upstream. vb2_read() and vb2_write() return size_t, but propagate negative errno values from __vb2_perform_fileio(). This relies on implicit signed/unsigned conversions in callers (e.g. vb2_fop_read()) to recover error codes: __vb2_perform_fileio() -> -EINVAL vb2_read() -> (size_t)-EINVAL vb2_fop_read() -> -EINVAL This relies on implicit conversions that are not obvious. These helpers are exported (EXPORT_SYMBOL_GPL) and part of the vb2 API, so changing their return type may affect existing users. However, they conceptually follow read/write semantics, where ssize_t is typically used to return either a byte count or a negative error code. Switch vb2_read() and vb2_write() to ssize_t, and update __vb2_perform_fileio() accordingly. Signed-off-by: Zile Xiong <[email protected]> Acked-by: Marek Szyprowski <[email protected]> Fixes: b25748fe6126 ("[media] v4l: videobuf2: add read() and write() emulator") Cc: [email protected] Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Apr 15 23:28:26 2026 +0800 media: vidtv: fix reference leak on failed device registration commit 9aa21e1549db8882ff77b691e7714153df21dff0 upstream. When platform_device_register() fails in vidtv_bridge_init(), the embedded struct device in vidtv_bridge_dev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: vidtv_bridge_init() -> platform_device_register(&vidtv_bridge_dev) -> device_initialize(&vidtv_bridge_dev.dev) -> setup_pdev_dma_masks(&vidtv_bridge_dev) -> platform_device_add(&vidtv_bridge_dev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: [email protected] Signed-off-by: Guangshuo Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Wed Apr 15 23:45:37 2026 +0800 media: vimc: fix reference leak on failed device registration commit 33e2b833c66b890a0d71c4fa82d4c97143f7f75f upstream. When platform_device_register() fails in vimc_init(), the embedded struct device in vimc_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: vimc_init() -> platform_device_register(&vimc_pdev) -> device_initialize(&vimc_pdev.dev) -> setup_pdev_dma_masks(&vimc_pdev) -> platform_device_add(&vimc_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically") Cc: [email protected] Signed-off-by: Guangshuo Li <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Wed May 20 09:30:44 2026 +0200 media: vivid: add vivid_update_reduced_fps() commit 1d793a29efb4260f90913f5287939bf95573b073 upstream. Don't call vivid_update_format_cap() when switching to/from reduced fps for HDMI inputs: that will also reset the format, which is overkill for this. Make a new vivid_update_reduced_fps() function that just updates the dev->timeperframe_vid_cap. Reviewed-by: Nicolas Dufresne <[email protected]> Fixes: c79aa6aeadb0 ("[media] vivid-capture: add control for reduced frame rate") Cc: [email protected] Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans Verkuil <[email protected]> Date: Wed May 20 09:22:41 2026 +0200 media: vivid: check for vb2_is_busy() when toggling caps commit c2d1a2130c93f6d758af58590b86b2254c7a1dec upstream. The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless. Reviewed-by: Nicolas Dufresne <[email protected]> Fixes: 73c3f48230cd ("[media] vivid: add the control handling code") Cc: [email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Apr 7 12:08:31 2026 +0200 media: vpif_capture: fix OF node reference imbalance commit 2282f979560af6bbc8ee2c1ee8663197312cee5b upstream. The driver reuses the OF node of the parent device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the parent and releasing the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when available") Cc: [email protected] # 4.13 Cc: Kevin Hilman <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Usyskin <[email protected]> Date: Sun Jul 5 18:12:59 2026 +0300 mei: bus: access mei_device under device_lock on cleanup commit f112ea910e554d58b4b39a4492b7d302f0f4204f upstream. Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too. Cc: stable <[email protected]> Fixes: 35e8a426b16a ("mei: bus: Check for still connected devices in mei_cl_bus_dev_release()") Reviewed-by: Menachem Adin <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SJ Park <[email protected]> Date: Fri Jul 3 09:56:08 2026 -0700 mm/damon/core: disallow overlapping input ranges for damon_set_regions() commit 954157679ec34661c2e87e7eb796104a797c32db upstream. damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") Signed-off-by: SJ Park <[email protected]> Cc: <[email protected]> # 5.19.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: SJ Park <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SJ Park <[email protected]> Date: Mon Jun 29 20:52:19 2026 -0700 mm/damon/core: validate ranges in damon_set_regions() commit 1292c0ecb1caefb8ca064a3639d5673991e8810c upstream. DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function. Link: https://lore.kernel.org/[email protected] Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RECLAIM)") Signed-off-by: SJ Park <[email protected]> Cc: Yang yingliang <[email protected]> Cc: <[email protected]> # 5.16.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: SJ Park <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Muchun Song <[email protected]> Date: Sat Jul 25 06:55:21 2026 -0400 mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages [ Upstream commit 94405c6136839f7c462249c8b4b957bcb9527a9d ] The memmap_init_zone_device() function only initializes the migratetype of the first pageblock of a compound page. If the compound page size exceeds pageblock_nr_pages (e.g., 1GB hugepages with 2MB pageblocks), subsequent pageblocks in the compound page remain uninitialized. Move the migratetype initialization out of __init_zone_device_page() and into a separate pageblock_migratetype_init_range() function. This iterates over the entire PFN range of the memory, ensuring that all pageblocks are correctly initialized. Also remove the stale confusing comment about MEMINIT_HOTPLUG above the migratetype setting since it is an obsolete relic from commit 966cf44f637e ("mm: defer ZONE_DEVICE page initialization to the point where we init pgmap") and no longer makes sense here. Link: https://lore.kernel.org/[email protected] Fixes: c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") Signed-off-by: Muchun Song <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Acked-by: Liam R. Howlett <[email protected]> Cc: "Aneesh Kumar K.V" <[email protected]> Cc: Joao Martins <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Weiming Shi <[email protected]> Date: Sat Jul 11 04:50:00 2026 -0700 mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n [ Upstream commit 56d96fededd61192cd7cc8d2b0f36adfd59036c3 ] On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does. Fixes: 196cfebf8972 ("net/mpls: Handle kernel side filtering of route dumps") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei <[email protected]> Signed-off-by: Weiming Shi <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chenguang Zhao <[email protected]> Date: Wed Jul 22 00:14:38 2026 +0200 mptcp: decrement subflows counter on failed passive join commit f3ca0ee2cc308e33896536789cbc5f3a12ca7b30 upstream. mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close") Cc: [email protected] Signed-off-by: Chenguang Zhao <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Thu Jul 9 15:19:25 2026 -0400 mptcp: only set DATA_FIN when a mapping is present commit b2ff91b752b0d85e8815e7f44fd85205c4268094 upstream. mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni <[email protected]> Cc: [email protected] Signed-off-by: Michael Bommarito <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[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: Xue Lei <[email protected]> Date: Wed Jul 1 20:10:42 2026 +0800 mtd: fix double free and WARN_ON in add_mtd_device() error paths [ Upstream commit 9d4af746af8ce27eefc2338b2feaa1e01f28b6c3 ] When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=e9c76b56dc05023b8117 Fixes: 19bfa9ebebb5 ("mtd: use refcount to prevent corruption") Signed-off-by: Xue Lei <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Tue Jun 23 09:53:17 2026 +0800 mtd: mtdswap: remove debugfs stats file on teardown [ Upstream commit 66fb31358108d10245b9e4ef0eef3e7d9747055e ] mtdswap_add_debugfs() creates an mtdswap_stats debugfs file under the per-MTD debugfs directory, but mtdswap_remove_dev() never removes it before freeing the mtdswap_dev. Store the returned dentry and remove it during device teardown before the driver-private state is freed. Fixes: a32159024620 ("mtd: Add mtdswap block driver") Signed-off-by: Pengpeng Hou <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Tue Jun 23 21:57:29 2026 +0800 mtd: nand: mtk-ecc: stop on ECC idle timeouts [ Upstream commit 16f7ec8d5dc100eafd2c8e06cd30340a30b104a1 ] mtk_ecc_wait_idle() logs when the encoder or decoder does not become idle, but returns void. Callers can therefore configure a non-idle ECC engine or read parity bytes after an unconfirmed encoder idle state. Return the idle poll result and propagate it from the enable and encode paths that require the engine to be idle before continuing. Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device") Signed-off-by: Pengpeng Hou <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Sun Jul 26 08:38:42 2026 -0400 mtd: rawnand: Add a helper for calculating a page index [ Upstream commit df9803bf5a91e3599f12b53c94722f2c4e144a86 ] For LUN crossing boundaries, it is handy to know what is the index of the last page in a LUN. This helper will soon be reused. At the same time I rename page_per_lun to ppl in the calling function to clarify the lines. Cc: [email protected] # v6.7 Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Stable-dep-of: 8e4531667d71 ("mtd: rawnand: Pause continuous reads at block boundaries") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Sun Jul 26 08:38:43 2026 -0400 mtd: rawnand: Ensure all continuous terms are always in sync [ Upstream commit 6fb075fca63c3486612986eeff84ed4179644038 ] While crossing a LUN boundary, it is probably safer (and clearer) to keep all members of the continuous read structure aligned, including the pause page (which is the last page of the lun or the last page of the continuous read). Once these members properly in sync, we can use the rawnand_cap_cont_reads() helper everywhere to "prepare" the next continuous read if there is one. Fixes: bbcd80f53a5e ("mtd: rawnand: Prevent crossing LUN boundaries during sequential reads") Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Stable-dep-of: 8e4531667d71 ("mtd: rawnand: Pause continuous reads at block boundaries") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Sun Jul 26 08:38:44 2026 -0400 mtd: rawnand: Pause continuous reads at block boundaries [ Upstream commit 8e4531667d718e2e9b193928cf9b2497fa0d01ef ] Some chips do not support sequential cached reads past block boundaries, like Winbond. In practice when using UBI, this should very rarely happen, but let's make sure it never happens. Cc: [email protected] Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hidayath Khan <[email protected]> Date: Thu Jul 9 21:17:32 2026 +0200 net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() commit 47a5116e56a6b6fe1e909f244e39cd0fc26ceee4 upstream. afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: [email protected] Reviewed-by: Alexandra Winter <[email protected]> Signed-off-by: Hidayath Khan <[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: Bryam Vargas <[email protected]> Date: Tue Jul 7 02:00:54 2026 -0500 net/iucv: fix use-after-free of a severed iucv_path commit be7cc4656eb1f54029610e82d1f0fdd3f9b5ec0a upstream. af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued. Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets") Closes: https://sashiko.dev/#/patchset/[email protected]?part=1 Cc: [email protected] Signed-off-by: Bryam Vargas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Sun Jul 5 22:24:36 2026 -0500 net/iucv: take a reference on the socket found in afiucv_hs_rcv() [ Upstream commit 4fa349156043dc119721d067329714179f501749 ] afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Signed-off-by: Bryam Vargas <[email protected]> Reviewed-by: Hidayath Khan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yael Chemla <[email protected]> Date: Fri Jul 17 10:33:06 2026 +0300 net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule [ Upstream commit d12956d083eb70f2c6d72711aebaf8c2ce21e170 ] esw_egress_acl_vlan_create() hardcodes num_dest=0 in its mlx5_add_flow_rules() call. When invoked from the non-bond path fwd_dest is NULL and num_dest=0 is correct. When invoked from esw_acl_egress_ofld_rules_create() during a bond event, fwd_dest is non-NULL and flow_act.action carries MLX5_FLOW_CONTEXT_ACTION_FWD_DEST, but _mlx5_add_flow_rules() rejects a non-NULL dest pointer paired with dest_num<=0 and returns -EINVAL. The error propagates as "configure slave vport egress fwd, err(-22)". The passive vport's egress ACL table ends up with its flow groups allocated but no FTEs, so prio-tagged packets are not popped and bond failover is broken on prio_tag_required devices. Fix by passing fwd_dest ? 1 : 0 as num_dest to match the actual number of destinations supplied. Fixes: bf773dc0e6d5 ("net/mlx5: E-Switch, Introduce APIs to enable egress acl forward-to-vport rule") Signed-off-by: Yael Chemla <[email protected]> Reviewed-by: Cosmin Ratiu <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Lazar <[email protected]> Date: Fri Jul 17 10:51:25 2026 +0300 net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation [ Upstream commit 9173e1d3c7c7d49a71eee813091f9e834ec7cee5 ] Credit Based (CB) TSA is not supported by the mlx5 driver, so reject any configurations that specify it. Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS") Signed-off-by: Alexei Lazar <[email protected]> Reviewed-by: Carolina Jubran <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexei Lazar <[email protected]> Date: Fri Jul 17 10:51:24 2026 +0300 net/mlx5e: Report zero bandwidth for non-ETS traffic classes [ Upstream commit ffb1873b2df11945b8c395e859169248675c91c5 ] The IEEE 802.1Qaz standard defines that bandwidth allocation percentages only apply to Enhanced Transmission Selection (ETS) traffic classes. For STRICT and VENDOR transmission selection algorithms, bandwidth percentage values are not applicable. Currently for non-ETS 100 bandwidth is being reported for all traffic classes in the get operation due to hardware limitation, regardless of their TSA type. Fix this by reporting 0 for non-ETS traffic classes. Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware") Signed-off-by: Alexei Lazar <[email protected]> Reviewed-by: Carolina Jubran <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Lee <[email protected]> Date: Tue Jul 7 10:44:37 2026 +0000 net/packet: avoid fanout hook re-registration after unregister [ Upstream commit 50aff80475abd3533eef4320477037e6fcc6b56e ] packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket. Fixes: dc99f600698d ("packet: Add fanout support.") Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: David Lee <[email protected]> Reviewed-by: Willem de Bruijn <[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: Sat Jul 11 11:05:37 2026 -0400 net/sched: act_tunnel_key: Defer dst_release to RCU callback [ Upstream commit f1f5c8a3955f8fda3f84ed883ac8daa1847e724c ] Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. [email protected] produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x4fff00000000240(workingset|head|node=1|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 raw: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 head: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9391, tgid 9378 (poc), ts 123227323196, free_ts 0 set_page_owner include/linux/page_owner.h:32 post_alloc_hook+0xfe/0x140 mm/page_alloc.c:1853 prep_new_page mm/page_alloc.c:1861 get_page_from_freelist+0x110c/0x2fc0 mm/page_alloc.c:3941 __alloc_frozen_pages_noprof+0x263/0x2bc0 mm/page_alloc.c:5221 alloc_slab_page mm/slub.c:3278 allocate_slab mm/slub.c:3467 new_slab+0xa6/0x690 mm/slub.c:3525 refill_objects+0x271/0x420 mm/slub.c:7272 refill_sheaf mm/slub.c:2816 __pcs_replace_empty_main+0x373/0x630 mm/slub.c:4652 alloc_from_pcs mm/slub.c:4750 slab_alloc_node mm/slub.c:4884 __do_kmalloc_node mm/slub.c:5295 __kmalloc_noprof+0x66d/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 metadata_dst_alloc+0x26/0x90 net/core/dst.c:298 tun_rx_dst include/net/dst_metadata.h:144 __ip_tun_set_dst include/net/dst_metadata.h:208 tunnel_key_init+0xb01/0x1b90 net/sched/act_tunnel_key.c:451 tcf_action_init_1+0x46b/0x6c0 net/sched/act_api.c:1428 tcf_action_init+0x448/0xa20 net/sched/act_api.c:1503 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] ================================================================== Fix by moving dst_release() into a custom RCU callback that runs after the grace period, matching the lifetime of the containing params struct. Readers in the datapath therefore always find a live rcuref when calling dst_clone(). Fixes: 9174c3df1cd18 ("net/sched: act_tunnel_key: fix memory leak in case of action replace") 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: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Lee <[email protected]> Date: Mon Jul 13 10:47:50 2026 +0000 net/x25: fix use-after-free in x25_kill_by_neigh() commit 5499e0602d2faafd42c580d25f615903c3fbe11b upstream. x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh(). Fixes: 7781607938c8 ("net/x25: Fix null-ptr-deref caused by x25_disconnect") Cc: [email protected] Signed-off-by: David Lee <[email protected]> Assisted-by: Codex:gpt-5.5 Acked-by: Martin Schiller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Tue Jul 21 17:09:21 2026 +0300 net: bridge: vlan: fix vlan range dumps starting with pvid [ Upstream commit 43171c97e4714bf601b468401b37732244639c21 ] There is a bug in all range dumps that rely on br_vlan_can_enter_range() when the PVID is a range starting VLAN, all following VLANs that match its flags can enter the range, but when the range is filled in only the PVID VLAN is dumped and the rest of the range is discarded because br_vlan_fill_vids() checks for the PVID flag. Since the PVID VLAN can be only one, we need to break ranges around it, the best way to do that consistently for all is to alter br_vlan_can_enter_range() to take into account the PVID and return false to break the range when it's matched. Before the fix: $ ip l add br0 type bridge vlan_filtering 1 $ ip l add dumdum type dummy $ ip l set dumdum master br0 $ ip l set br0 up $ ip l set dumdum up $ bridge vlan add dev dumdum vid 1 pvid untagged master $ bridge vlan add dev dumdum vid 2 untagged master $ bridge vlan show dev dumdum # use legacy dump to show all vlans port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 VLAN 2 is missing, and if there are more matching VLANs afterwards they'd be missing too. After the fix: [ same setup steps ] $ bridge vlan show dev dumdum port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 2 Egress Untagged state forwarding mcast_router 1 Fixes: 0ab558795184 ("net: bridge: vlan: add rtm range support") Signed-off-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Walle <[email protected]> Date: Fri Jul 17 15:20:29 2026 +0200 net: dpaa: fix mode setting [ Upstream commit da2c6bcc5e30b1496ac587785dcacf6e849eb6ef ] Before converting to the phylink interface, the init function would have set a non-reserved I/F mode in the maccfg2 register. After converting to phylink, 0 is written as mode, which is a reserved value (although it's the hardware default). Without a valid mode, a SGMII link is never established between the MAC and the PHY and thus .link_up() is never called which could set the correct mode according to the actual speed. Fix it by setting the maximum speed of the phy_interface_t in use in .mac_config() - just like the driver did before the phylink conversion. Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink") Suggested-by: Sean Anderson <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Reviewed-by: Sean Anderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fan Wu <[email protected]> Date: Sun Jul 12 14:27:29 2026 +0000 net: hip04: fix RX buffer leak on build_skb failure commit 14fa65d10f5696b063a7d8d26e8291ea84a2c6ed upstream. When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool. Fixes: 701a0fd52318 ("hip04_eth: fix missing error handle for build_skb failed") Cc: [email protected] Signed-off-by: Fan Wu <[email protected]> Reviewed-by: Jacob Keller <[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 Dumazet <[email protected]> Date: Tue Jul 21 10:12:40 2026 +0000 net: hsr: fix memory leak on slave unregistration by removing synced VLANs [ Upstream commit dcf15eaf5641812f1cfc5e96537380132a7da89d ] When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers. Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Fernando Fernandez Mancera <[email protected]> Reviewed-by: Felix Maurer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maoyi Xie <[email protected]> Date: Tue Jul 28 09:30:33 2026 -0400 net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink [ Upstream commit 2496fa0b7d180b3ad356b514e7ff93bb14e6140a ] ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang <[email protected]> Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 0bd8762824e7 ("ip6tnl: add x-netns support") Cc: [email protected] Signed-off-by: Maoyi Xie <[email protected]> Reviewed-by: Kuniyuki Iwashima <[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: Haoxiang Li <[email protected]> Date: Tue Jul 28 23:20:20 2026 -0400 net: ipa: fix SMEM state handle leaks in SMP2P init [ Upstream commit 96ca1e658ae459276292bd6d971ab5d8c7e0379a ] ipa_smp2p_init() acquires two Qualcomm SMEM state handles with qcom_smem_state_get(). However, neither the init error paths nor ipa_smp2p_exit() release them. Release both handles with qcom_smem_state_put() in the init error paths and in ipa_smp2p_exit(). Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Larysa Zaremba <[email protected]> Reviewed-by: Alex Elder <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ kzalloc_obj() context line kept as kzalloc(sizeof(*smp2p), GFP_KERNEL) since ipa_smp2p.c was not yet converted in this tree ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Li RongQing <[email protected]> Date: Fri Jul 17 22:32:30 2026 +0800 net: ipv6: fix dif and sdif mismatch in raw6_icmp_error [ Upstream commit 440e274da4d1b93c7df2cb0ce893c3009dd4db55 ] In raw6_icmp_error(), raw_v6_match() is called with inet6_iif(skb) passed to both the 'dif' and 'sdif' arguments. This is a copy-paste or typo error, as the last argument should represent the secondary interface index (sdif). This mismatch breaks ICMPv6 error handling for IPv6 raw sockets in VRF (Virtual Routing and Forwarding) environments. When a raw socket is bound to a VRF master device, raw_v6_match() fails to find a match because it is not given the correct sdif value, causing the socket to miss relevant ICMPv6 error notifications. Fix this by properly passing inet6_sdif(skb) as the last argument to raw_v6_match(). Fixes: 5108ab4bf446fa ("net: ipv6: add second dif to raw socket lookups") Signed-off-by: Li RongQing <[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: Sasha Levin <[email protected]>
Author: Théo Lebrun <[email protected]> Date: Tue Jul 28 22:40:09 2026 -0400 net: macb: drop in-flight Tx SKBs on close [ Upstream commit 27f575836cfebbf872dec020428742b10650a955 ] The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty. Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver") Cc: [email protected] Reviewed-by: Nicolai Buchwitz <[email protected]> Signed-off-by: Théo Lebrun <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> [ adjusted context to free each queue's Tx/Rx rings individually since 6.12 lacks the single-dma_alloc_coherent refactor ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dexuan Cui <[email protected]> Date: Mon Jul 27 23:25:58 2026 -0400 net: mana: Validate the packet length reported by the NIC [ Upstream commit 2e2a83b4998af4384e677d3b2ac08565274279bf ] Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted. Cc: [email protected] Reviewed-by: Haiyang Zhang <[email protected]> Signed-off-by: Dexuan Cui <[email protected]> Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Coia Prant <[email protected]> Date: Thu Jul 30 03:11:08 2026 +0800 net: pcs: xpcs: fix SGMII state reading commit def9a4745e105145133e442dd8a1c126caf0f553 upstream. Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") added a path in xpcs_get_state_c37_sgmii() that reads speed/duplex from BMCR after AN completes. However, BMCR does not reflect the negotiated result on the hardware where this has been tested: - On RK3568 (MAC side SGMII), BMCR returns a fixed hardware reset value - Wangxun engineer Jiawen Wu confirmed that on their side, "BMCR looks like it only wants to be return as 0" [0] The correct information is available in CL37_ANSGM_STS, which contains the actual link status and negotiated speed/duplex. This bug was previously masked by phylink core, which overrides the PCS link state with the PHY state when a PHY is present: /* If we have a phy, the "up" state is the union of both the * PHY and the MAC */ if (phy) link_state.link &= pl->phy_state.link; Thus, when the link is down, the PHY's link_down state is applied on top of whatever the PCS reports, hiding the broken PCS state reading path. Modify xpcs_get_state_c37_sgmii() to: 1. Read link state from CL37_ANSGM_STS 2. If link is up, report speed/duplex from CL37_ANSGM_STS 3. Remove the broken BMCR reading path entirely Also properly set state->an_complete to reflect the AN completion status, and clear CL37_ANCMPLT_INTR when link is down to avoid stale state. [0] https://lore.kernel.org/all/[email protected]/ Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") Cc: [email protected] Tested-by: Jiawen Wu <[email protected]> Signed-off-by: Coia Prant <[email protected]> Tested-by: Maxime Chevallier <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Youssef Samir <[email protected]> Date: Wed Jul 29 17:05:32 2026 +0200 net: qrtr: ns: Raise node count limit to 512 commit ff194cffd586cbd4cc49eccb002c65f2a902a277 upstream. The current node limit of 64 breaks the functionality for a number of AI200 deployments that have up to 384 nodes. Raise the limit to 512. Fixes: 27d5e84e810b ("net: qrtr: ns: Limit the total number of nodes") Cc: [email protected] Signed-off-by: Youssef Samir <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Youssef Samir <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aldo Ariel Panzardo <[email protected]> Date: Thu Jul 16 12:43:19 2026 -0300 net: qrtr: restrict socket creation to the initial network namespace [ Upstream commit 3b536db8fb32da9e9c62f2bb45e2e319331f0426 ] QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code). Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Aldo Ariel Panzardo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sungmin Kang <[email protected]> Date: Sat Jul 18 16:36:30 2026 +0900 net: slip: serialize receive against buffer reallocation commit ee7f9bb9320add61f7b367d7e6cd55e3a3a4d65d upstream. sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Sungmin Kang <[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: vadik likholetov <[email protected]> Date: Mon Jul 13 10:49:11 2026 +0300 net: stmmac: enable the MAC on link up for all supported speeds [ Upstream commit 9c99db3a2080b8c2cbbb1100369586a9bea43321 ] stmmac_mac_link_down() clears the MAC's transmit and receive enable bits. stmmac_mac_link_up() is expected to set them again through stmmac_mac_set(..., true), but it first switches on the negotiated speed and returns early for a speed the switch does not list. The MAC is then left gated off. The speed selection is split into three switches, keyed on the interface. The generic branch -- taken for everything that is neither USXGMII nor XLGMII, so including PHY_INTERFACE_MODE_10GBASER -- lists only SPEED_2500, SPEED_1000, SPEED_100 and SPEED_10. MGBE on Tegra234 runs 10GBASE-R into an Aquantia AQR113C. That PHY does rate matching, so phylink_link_up() replaces the media speed with the MAC-side interface speed before calling into the MAC: case RATE_MATCH_PAUSE: speed = phylink_interface_max_speed(link_state.interface); duplex = DUPLEX_FULL; The driver is therefore called as stmmac_mac_link_up(interface=10GBASER, speed=10000, duplex=1) which falls through to "default: return;". The interface stops passing traffic after the first link flap. The failure is easy to misread. The link still comes up, because the PHY is polled over MDIO and needs no MAC, so the interface reports carrier 1 at the media speed. The DMA is untouched, so its start bits stay set and descriptors are still consumed. Only the MAC itself is gated off: the receiver counts nothing (mmc_rx_framecount_gb stops advancing, RE is 0) and nothing reaches the wire (TE is 0). The interface survives boot only because stmmac_hw_setup(), called from ndo_open, enables the MAC unconditionally -- so the problem appears only once the cable has been unplugged and plugged back in, and "ip link set dev <ethX> down && ip link set dev <ethX> up" appears to fix it. The interface is not what the speed bits depend on: with the single exception of 2.5G, which is selected through the XGMII block on USXGMII and through the regular speed bits otherwise, each speed maps to one field of struct mac_link. The per-interface switches are speed validation, and phylink already validates the speed against priv->hw->link.caps. So collapse the three switches into one keyed on the speed alone, keeping the interface test only for the 2.5G case. This covers 10G on 10GBASE-R, and equally 5G, and 1G/100/10 on USXGMII, all of which hit "default: return;" today. A core that does not support a speed leaves the corresponding mac_link field at 0, and phylink will not offer it that speed in the first place. For dwxgmac2 at 10G, link.xgmii.speed10000 is XGMAC_CONFIG_SS_10000, which is 0 and is the correct speed selection for a 10GBASE-R MAC: ctrl then equals old_ctrl, the register write is skipped, and execution reaches stmmac_mac_set(..., true). Log an error in the default case, since a speed with no entry here leaves the MAC disabled and the symptom does not point at the cause. Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support") Suggested-by: Maxime Chevallier <[email protected]> Signed-off-by: vadik likholetov <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nazim Amirul <[email protected]> Date: Mon Jul 13 19:37:15 2026 -0700 net: stmmac: fix l3l4 filter rejecting unsupported offload requests [ Upstream commit 5536d7c843637e9430279b94935fcf7df98babb3 ] The basic flow parser in tc_add_basic_flow() does not validate match keys before proceeding. Unsupported offload configurations such as partial protocol masks, non-IPv4 network proto, or non-TCP/UDP transport proto are silently accepted instead of returning -EOPNOTSUPP. Add validation to return -EOPNOTSUPP early for: - No network or transport proto present in the key - Partial protocol mask (only full mask supported) - Network proto is not IPv4 - Transport proto is not TCP or UDP Each rejection includes an extack message so the user knows which part of the match is unsupported. Also propagate -EOPNOTSUPP from tc_add_basic_flow() in tc_add_flow() by returning it directly rather than using break. The break was silently discarding the error for FLOW_CLS_REPLACE operations where entry->in_use is already true, causing tc_add_flow() to return 0 (success) for unsupported replace requests. Fixes: 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Rohan G Thomas <[email protected]> Signed-off-by: Nazim Amirul <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Link: https://patch.msgid.link/20260714023716.29865-4-muhammad.nazim.amirul.nazle.asmade@altera.com Reviewed-by: Jakub Raczynski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nazim Amirul <[email protected]> Date: Mon Jul 13 19:37:16 2026 -0700 net: stmmac: reset residual action in L3L4 filters on delete [ Upstream commit a448f821289934b961dd9d8d0beb006cc8937ba2 ] When deleting an L3/L4 flower filter entry, the action field is not reset. If a filter was previously configured with a drop action, that action may persist and affect subsequent filter configurations unintentionally. Clear the action field when the filter entry is deleted. Fixes: 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Rohan G Thomas <[email protected]> Signed-off-by: Nazim Amirul <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Link: https://patch.msgid.link/20260714023716.29865-5-muhammad.nazim.amirul.nazle.asmade@altera.com Reviewed-by: Jakub Raczynski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:53:18 2026 -0400 netfilter: nf_conntrack_sip: remove net variable shadowing [ Upstream commit 7970d6aaf710db166de98c5356a260089896fae5 ] net is already set, derived from nf_conn. I don't see how the device could be living in a different netns than the conntrack entry. Remove the extra variable and re-use existing one. Signed-off-by: Florian Westphal <[email protected]> Stable-dep-of: e5e24a365a5e ("netfilter: nf_conntrack_sip: validate skb_dst() before accessing it") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pablo Neira Ayuso <[email protected]> Date: Thu Jul 23 10:53:19 2026 -0400 netfilter: nf_conntrack_sip: validate skb_dst() before accessing it [ Upstream commit e5e24a365a5e024efef63cc49abb345fbd4852c5 ] tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Cc: [email protected] Reported-by: Ren Wei <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 15:58:41 2026 -0400 netfilter: nf_tables: remove register tracking infrastructure [ Upstream commit 6b94d081f81dd524626f7aab2b98a9de335edb72 ] This facility was disabled in commit 9e539c5b6d9c ("netfilter: nf_tables: disable expression reduction infra"), because not all nft_exprs guarantee they will update the destination register: some may set NFT_BREAK instead to cancel evaluation of the rule. This has been dead code ever since. There are no plans to salvage this at this time, so remove this. Signed-off-by: Florian Westphal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: d07955dd34ec ("netfilter: nft_fib: reject fib expression on the netdev egress hook") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yue Haibing <[email protected]> Date: Thu Jul 23 15:58:40 2026 -0400 netfilter: nf_tables: Remove unused nft_reduce_is_readonly() [ Upstream commit bf6788742b8d6c73de441e088a71de7154f0d4aa ] Since commit 9e539c5b6d9c ("netfilter: nf_tables: disable expression reduction infra") this is unused. Signed-off-by: Yue Haibing <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: d07955dd34ec ("netfilter: nft_fib: reject fib expression on the netdev egress hook") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Theodor Arsenij Larionov-Trichkine <[email protected]> Date: Thu Jul 23 15:58:42 2026 -0400 netfilter: nft_fib: reject fib expression on the netdev egress hook [ Upstream commit d07955dd34ecae17d35d8c7d0a273a3fba653a8c ] A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks. Fixes: 42df6e1d221d ("netfilter: Introduce egress hook") Cc: [email protected] Link: https://lore.kernel.org/netfilter-devel/[email protected]/ Signed-off-by: Theodor Arsenij Larionov-Trichkine <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:55 2026 -0400 netfilter: nft_set_pipapo: don't leak bad clone into future transaction [ Upstream commit 47e65eff50691f0a5b79d325e28d83ec1da43bcf ] On memory allocation failure the cloned nft_pipapo_match can enter a bad state: - some fields can have their lookup tables resized while others did not - bits might have been toggled - scratch map can be undersized which also means m->bsize_max can be lower than what is required This means that the next insertion in the same batch can trigger out-of-bounds writes. Furthermore, a failure in the first can result in the bad clone to leak into the next transaction because the abort callback is never executed in this case (the upper layer saw an error and no attempt to allocate a transactional request was made). Record a state for the nft_pipapo_match structure: - NEW (pristine clone) - MOD (modified clone with good state) - ERR (potentially bogus content) Then make it so that deletes and insertions fail when the clone entered ERR state. In case the very first insert attempt results in an error, free the clone right away. Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Cc: [email protected] Reported-and-tested-by: Seesee <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:50 2026 -0400 netfilter: nft_set_pipapo: make pipapo_clone helper return NULL [ Upstream commit 80efd2997fb9343a0283cf3cac5524a4595c8ff4 ] Currently it returns an error pointer, but the only possible failure is ENOMEM. After a followup patch, we'd need to discard the errno code, i.e. x = pipapo_clone() if (IS_ERR(x)) return NULL or make more changes to fix up callers to expect IS_ERR() code from set->ops->deactivate(). So simplify this and make it return ptr-or-null. Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:52 2026 -0400 netfilter: nft_set_pipapo: merge deactivate helper into caller [ Upstream commit c5444786d0ea2417a5e2cee7bd67137fc8bad687 ] Its the only remaining call site so there is no need for this to be separated anymore. Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:54 2026 -0400 netfilter: nft_set_pipapo: move cloning of match info to insert/removal path [ Upstream commit 3f1d886cc7c3525d4dbeee24bfa9bb3fe0d48ddc ] This set type keeps two copies of the sets' content, priv->match (live version, used to match from packet path) priv->clone (work-in-progress version of the 'future' priv->match). All additions and removals are done on priv->clone. When transaction completes, priv->clone becomes priv->match and a new clone is allocated for use by next transaction. Problem is that the cloning requires GFP_KERNEL allocations but we cannot fail at either commit or abort time. This patch defers the clone until we get an insertion or removal request. This allows us to handle OOM situations correctly. This also allows to remove ->dirty in a followup change: If ->clone exists, ->dirty is always true If ->clone is NULL, ->dirty is always false, no elements were added or removed (except catchall elements which are external to the specific set backend). Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:49 2026 -0400 netfilter: nft_set_pipapo: move prove_locking helper around [ Upstream commit a590f4760922acaa2d2b55a88004a38eecdd6412 ] Preparation patch, the helper will soon get called from insert function too. Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:53 2026 -0400 netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone [ Upstream commit a238106703ab4ae1090b86eba128815b8626d8f1 ] The helper uses priv->clone unconditionally which will fail once we do the clone conditionally on first insert or removal. 'nft get element' from userspace needs to use priv->match since this runs from rcu read side lock section. Prepare for this by passing the match backend data as argument. Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:51 2026 -0400 netfilter: nft_set_pipapo: prepare walk function for on-demand clone [ Upstream commit 6c108d9bee448a850b03e682836bfe91fca645cb ] The existing code uses iter->type to figure out what data is needed, the live copy (READ) or clone (UPDATE). Without pending updates, priv->clone and priv->match will point to different memory locations, but they have identical content. Future patch will make priv->clone == NULL if there are no pending changes, in this case we must copy the live data for the UPDATE case. Currently this would require GFP_ATOMIC allocation. Split the walk function in two parts: one that does the walk and one that decides which data is needed. In the UPDATE case, callers hold the transaction mutex so we do not need the rcu read lock. This allows to use GFP_KERNEL allocation while cloning. Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Jul 23 10:18:48 2026 -0400 netfilter: nft_set_pipapo: use GFP_KERNEL for insertions [ Upstream commit 5b651783d80b97167ecd27dc6a4408c694873902 ] An earlier attempt changed this to GFP_KERNEL, but the get helper is also called for get requests from userspace, which uses rcu. Let the caller pass in the kmalloc flags to allow insertions to schedule if needed. Suggested-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Stable-dep-of: 47e65eff5069 ("netfilter: nft_set_pipapo: don't leak bad clone into future transaction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Mon Jul 13 22:15:51 2026 +0000 nexthop: initialize extack in nh_res_bucket_migrate() [ Upstream commit 6347c5314cee49f364aaf2e40ff15415a57a116e ] nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it. Fixes: 7c37c7e00411 ("nexthop: Implement notifiers for resilient nexthop groups") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Wed Jul 8 22:34:08 2026 +0800 nfp: Check resource mutex allocation [ Upstream commit a61b4db34a753bdf5c9e77a7f3d3dddd41dcfacc ] nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: f01a2161577d ("nfp: add support for resources") Signed-off-by: Ruoyu Wang <[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: Benjamin Coddington <[email protected]> Date: Mon Jul 27 11:40:54 2026 -0400 NFS: Charge unstable writes by request size, not folio size [ Upstream commit 27934d02cbeb8a957dd11c985a579e58d30c5270 ] nfs_folio_mark_unstable() and nfs_folio_clear_commit() charge and uncharge NR_WRITEBACK/WB_WRITEBACK by folio_nr_pages(folio) once per *request* added to or removed from a commit list. This is correct only when a folio has a single associated request. When pg_test splits a folio into N sub-folio requests (e.g. pNFS flexfiles striping with a stripe unit smaller than the folio size, or plain wsize-limited splitting), each of the N requests independently charges the whole folio's page count, inflating the accounting by a factor of N per folio. With large folios and small stripe units this reaches multiple orders of magnitude: a 2 MiB folio split into 512 4 KiB requests can charge up to 512x its real size, pushing global dirty+writeback accounting past the system's dirty threshold and forcing every buffered writer on the host into the hard-throttle path, including unrelated in-kernel NFS server threads sharing the box. Charge each request only for the pages it actually covers. Fixes: 0c493b5cf16e ("NFS: Convert buffered writes to use folios") Cc: [email protected] Signed-off-by: Benjamin Coddington <[email protected]> Assisted-By: Claude Sonnet 5 <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Jul 27 11:40:53 2026 -0400 nfs: remove dead code for the old swap over NFS implementation [ Upstream commit 7e8e78a0ba00c88f0ded86de64bdddc82e06b196 ] Remove the code testing folio_test_swapcache either explicitly or implicitly in pagemap.h headers, as is now handled using the direct I/O path and not the buffered I/O path that these helpers are located in. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Stable-dep-of: 27934d02cbeb ("NFS: Charge unstable writes by request size, not folio size") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mike Snitzer <[email protected]> Date: Thu Jul 23 21:25:11 2026 -0400 NFSD: pass nfsd_file to nfsd_iter_read() [ Upstream commit 803bc849f0039291f546ba0e2237faebeb5c073e ] Prepare for nfsd_iter_read() to use the DIO alignment stored in nfsd_file by passing the nfsd_file to nfsd_iter_read() rather than just the file which is associaed with the nfsd_file. This means nfsd4_encode_readv() now also needs the nfsd_file rather than the file. Instead of changing the file arg to be the nfsd_file, we discard the file arg as the nfsd_file (and indeed the file) is already available via the "read" argument. Signed-off-by: Mike Snitzer <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Reviewed-by: NeilBrown <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Tue Jul 28 12:10:46 2026 -0400 octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF [ Upstream commit 8cdcf3d2caacdee7ddd363705fb4d93b0c1a0915 ] rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block. Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions") Reported-by: Yuhao Jiang <[email protected]> Cc: [email protected] Signed-off-by: Junrui Luo <[email protected]> Link: https://patch.msgid.link/SYBPR01MB78811656934E713B77DA6CEDAFE62@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski <[email protected]> [ Dropped `rvu->pdev` argument from `rvu_get_pf()` calls and folded in the `is_pf_func_valid()` de-static plus its `rvu.h` declaration from commit 2156a29aecff. ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Runyu Xiao <[email protected]> Date: Wed Jul 22 19:21:19 2026 -0400 octeontx2-pf: clear stale mailbox IRQ state before request_irq() [ Upstream commit f918554fb7246e89b98ef90abe80801f038258b3 ] otx2_register_mbox_intr() currently installs the PF mailbox IRQ handler before clearing stale mailbox interrupt state. The function itself then comments that the local interrupt bits must be cleared first to avoid spurious interrupts, but that clear happens only after request_irq() has already exposed the handler to irq delivery. A running system can reach this during PF mailbox interrupt registration while stale or latched RVU_PF_INT state is still present. If delivery happens in the request_irq()-to-clear window, otx2_pfaf_mbox_intr_handler() can run before local quiesce and touch the same pf->mbox and pf->mbox_wq carrier that probe and teardown later reuse or destroy. Move the stale mailbox interrupt clear ahead of request_irq(), but keep interrupt enabling after the handler is installed. This closes the pre-clear early-IRQ window without creating a new enable-before-handler window. Fixes: 5a6d7c9daef3 ("octeontx2-pf: Mailbox communication with AF") Cc: [email protected] Signed-off-by: Runyu Xiao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Ratheesh Kannoth <[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: Dawei Feng <[email protected]> Date: Tue Jul 28 22:30:28 2026 -0400 octeontx2-pf: fix SQB pointer leak on init failure [ Upstream commit 62e7df6d042aeebd5efb581074e28865c04477be ] otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed. Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues") Cc: [email protected] Reviewed-by: Ratheesh Kannoth <[email protected]> Signed-off-by: Dawei Feng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Runyu Xiao <[email protected]> Date: Wed Jul 22 19:21:22 2026 -0400 octeontx2-vf: clear stale mailbox IRQ state before request_irq() [ Upstream commit 0b352f04b9be2c83c0240aa6dae7257fefa90464 ] otx2vf_register_mbox_intr() currently installs the VF mailbox IRQ handler before clearing stale mailbox interrupt state. The code then says that local interrupt bits should be cleared first to avoid spurious interrupts, but that clear still happens only after request_irq() has already made the handler reachable. A running system can reach this during VF mailbox interrupt registration while stale or latched RVU_VF_INT state is still present. If delivery happens in the request_irq()-to-clear window, otx2vf_vfaf_mbox_intr_handler() can run before local quiesce and touch the same vf->mbox and vf->mbox_wq carrier that probe and teardown later reuse or destroy. Move the stale mailbox interrupt clear ahead of request_irq(), but keep interrupt enabling after the handler is installed. This closes the pre-clear early-IRQ window without creating a new enable-before-handler window. Fixes: 3184fb5ba96e ("octeontx2-vf: Virtual function driver support") Cc: [email protected] Signed-off-by: Runyu Xiao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Ratheesh Kannoth <[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: Suman Ghosh <[email protected]> Date: Wed Jul 15 10:50:07 2026 +0530 octeontx2-vf: set TC flower flag on MCAM entry allocation [ Upstream commit 0d4d31e3cc5dd6204fa1495c4107f5075acce5ed ] When MCAM entries are allocated for a VF netdev via the devlink mcam_count parameter, only OTX2_FLAG_NTUPLE_SUPPORT was set. That enabled ethtool ntuple filters but not tc flower offload. Also set OTX2_FLAG_TC_FLOWER_SUPPORT when entries are successfully allocated. Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count") Signed-off-by: Suman Ghosh <[email protected]> Signed-off-by: Ratheesh Kannoth <[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: Subbaraya Sundeep <[email protected]> Date: Wed Jul 22 19:21:18 2026 -0400 octeontx2: Annotate mmio regions as __iomem [ Upstream commit d0976b43956ee8c8bd093223df9115bfcf63dfe5 ] This patch removes unnecessary typecasts by marking the mbox_regions array as __iomem since it is used to store pointers to memory-mapped I/O (MMIO) regions. Also simplified the call to readq() in PF driver by removing redundant type casts. Signed-off-by: Subbaraya Sundeep <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: f918554fb724 ("octeontx2-pf: clear stale mailbox IRQ state before request_irq()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Wed Jul 29 22:56:07 2026 +0200 openvswitch: fix GSO userspace truncation underflow [ Upstream commit 4032f8ed10fcb84d41c508dfb04be96589f78dfe ] OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it. Fixes: f2a4d086ed4c ("openvswitch: Add packet truncation support.") Cc: [email protected] Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng <[email protected]> Reviewed-by: Ilya Maximets <[email protected]> Reviewed-by: Aaron Conole <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> [6.6.y and older don't have OVS_ACTION_ATTR_PSAMPLE] Signed-off-by: Ilya Maximets <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Souvik Banerjee <[email protected]> Date: Mon Jul 27 11:41:17 2026 -0400 ovl: use linked upper dentry in copy-up tmpfile [ Upstream commit e348eecd4d8fa8d18a5157ff59f7be1dc59c5928 ] ovl_copy_up_tmpfile() stores the disconnected O_TMPFILE dentry as the overlay's upper dentry reference via ovl_inode_update(). vfs_tmpfile() allocated this dentry via d_alloc(parentpath->dentry, &slash_name), so d_name is "/" and d_parent is c->workdir. Local upper filesystems (ext4, btrfs, xfs, ...) immediately rename it to "#<inum>" via d_mark_tmpfile() inside their ->tmpfile() op; FUSE and virtiofs do not, so both fields stay that way. Neither identifies the destination directory and filename where ovl_do_link() actually linked the file. When the upper filesystem implements ->d_revalidate() (e.g. FUSE or virtiofs), ovl_revalidate_real() calls it with the dentry's parent inode and a snapshot of d_name. The server tries to look up "/" inside c->workdir, fails, and overlayfs reports -ESTALE. This causes persistent ESTALE errors for any file that was copied up via the tmpfile path, breaking dpkg, apt, and other tools that do rename-over-existing on overlayfs with a FUSE/virtiofs upper. Before commit 6b52243f633e ("ovl: fold copy-up helpers into callers"), the tmpfile copy-up path used a dedicated helper ovl_link_tmpfile() that captured the linked destination dentry returned by ovl_do_link(): err = ovl_do_link(temp, udir, upper); ... if (!err) *newdentry = dget(upper); and published it via ovl_inode_update(d_inode(c->dentry), newdentry). The fold inlined ovl_do_link() into ovl_copy_up_tmpfile() but dropped the dget(upper) capture, and rewrote the publish line as ovl_inode_update(d_inode(c->dentry), dget(temp)) — where temp is the disconnected O_TMPFILE dentry. Fix by keeping a reference to the linked destination dentry after ovl_do_link() succeeds, and publishing that dentry at the existing ovl_inode_update() call site. The non-tmpfile/workdir path continues to publish the renamed temporary dentry. Reproducer: - Mount overlayfs with virtiofs (or a FUSE fs whose server advertises FUSE_TMPFILE) as upper - Run: dpkg -i <any .deb> - Observe: "error installing new file '...': Stale file handle" Fixes: 6b52243f633e ("ovl: fold copy-up helpers into callers") Cc: [email protected] # v4.20+ Signed-off-by: Souvik Banerjee <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Amir Goldstein <[email protected]> Reviewed-by: Miklos Szeredi <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> [ adapted scoped credential and creation helpers to explicit credential, locking, lookup, and cleanup handling ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nikhil P. Rao <[email protected]> Date: Tue Jul 14 21:27:13 2026 +0000 pds_core: check for workqueue allocation failure [ Upstream commit 3a660ca49e2c3807bffe0519db3cff677a5906e0 ] pdsc_init_pf() does not check whether create_singlethread_workqueue() succeeded. Fail probe on failure. The workqueue is set up before the timer and mutexes, so its failure path must unwind only the earlier setup. Fixes: c2dbb0904310 ("pds_core: health timer and workqueue") Reported-by: sashiko-bot <[email protected]> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <[email protected]> Reviewed-by: Brett Creeley <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikhil P. Rao <[email protected]> Date: Tue Jul 14 21:07:45 2026 +0000 pds_core: fix auxiliary device add/del races [ Upstream commit bfa33cd513c7ceb93c5a4c30e5662acd73c0a916 ] Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths. Fixes: b699bdc720c0 ("pds_core: specify auxiliary_device to be created") Reported-by: [email protected] # Running on a local machine Signed-off-by: Nikhil P. Rao <[email protected]> Reviewed-by: Brett Creeley <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikhil P. Rao <[email protected]> Date: Tue Jul 14 20:41:45 2026 +0000 pds_core: order completion reads after the ownership check [ Upstream commit dd6b1cc748cd28147c113f9daa76393916ad9494 ] pdsc_process_adminq() and pdsc_process_notifyq() decide a completion is valid from its ownership field - the color bit for the adminq, the event id for the notifyq - then read the rest of the descriptor, with no barrier in between. On a weakly ordered architecture the CPU may read the payload first. Add dma_rmb() between the ownership read and the payload reads. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot <[email protected]> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <[email protected]> Reviewed-by: Eric Joyner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikhil P. Rao <[email protected]> Date: Wed Jul 8 16:36:49 2026 +0000 pds_core: reject component parameter in legacy firmware update [ Upstream commit 7be2552e601c247a328a5aba6fc06ac844b94a16 ] The legacy firmware update path does not support per-component updates. If a user specifies a component parameter with devlink flash, reject the request with -EOPNOTSUPP rather than silently ignoring the component parameter and flashing the entire firmware image. Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink") Signed-off-by: Nikhil P. Rao <[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: Nikhil P. Rao <[email protected]> Date: Tue Jul 14 20:14:56 2026 +0000 pds_core: yield the CPU while waiting for the adminq to drain [ Upstream commit a11f0b8a204296fe7db9eaec53441012222cb004 ] pdsc_adminq_wait_and_dec_once_unused() busy-waits for adminq_refcnt to drop to one: while (!refcount_dec_if_one(&pdsc->adminq_refcnt)) cpu_relax(); The refcount is held by pdsc_adminq_post() for the duration of an in-flight command, which can wait up to devcmd_timeout seconds (PDS_CORE_DEVCMD_TIMEOUT is 5) for the hardware to complete. cpu_relax() is not a reschedule point, so on a non-preemptible kernel this loop can spin on the CPU for several seconds, starving other tasks on that core. Add cond_resched() to the loop so the waiter yields to other runnable tasks while it polls, keeping cpu_relax() as the busy-wait hint between checks. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot <[email protected]> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <[email protected]> Reviewed-by: Eric Joyner <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Tue Jul 21 01:58:45 2026 -0700 phonet: pep: fix use-after-free in pep_get_sb() commit 0f71f852a96af9685858ce59fda34ecbf85c283d upstream. pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one. Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Cc: [email protected] Signed-off-by: Breno Leitao <[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: Bartosz Golaszewski <[email protected]> Date: Tue Jul 28 08:11:24 2026 -0400 pinctrl: remove pinctrl_gpio_direction_output() [ Upstream commit 45d2055b0067739253883dc541f37c86aad45c92 ] There are no more users of pinctrl_gpio_direction_output() so remove it. Signed-off-by: Bartosz Golaszewski <[email protected]> Acked-by: Linus Walleij <[email protected]> Stable-dep-of: d3e91a95b2b0 ("gpio: tegra: do not call pinctrl for GPIO direction") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zixing Liu <[email protected]> Date: Fri Jul 24 16:33:14 2026 +0800 platform/loongarch: laptop: Explicitly reset bl_powered state when suspend commit 91a70492c03040d51b36f595530d6491d5d6c541 upstream. On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a very high chance (>90%) of causing the EC to lose the previous backlight power state. When this happens, the laptop resumes normally from S3, but the backlight remains off (when shining on the screen with a flash light, we can see the screen contents are updating normally). Since there is no generic way to query the EC's backlight state on Loongson laptop platforms, assume the worst-case scenario and restart the backlight power inside the kernel each time the system resumes. Cc: [email protected] Fixes: 53c762b47f72 ("platform/loongarch: laptop: Add backlight power control support") Tested-by: Yao Zi <[email protected]> Tested-by: Xi Ruoyao <[email protected]> Signed-off-by: Zixing Liu <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Gibson <[email protected]> Date: Wed Jul 22 18:54:02 2026 +0200 platform/x86/amd/pmc: Avoid logging "(null)" for DMI values commit a0738abd042f7406edd2175a819cf2e66388ed97 upstream. dmi_get_system_info(...) can return NULL. Using that as %s arguments of dev_info() would log "(null)" (as part of a message like '... System Vendor: "(null)", Product Name: "(null)" ...'), which may be confusing for users. Use Elvis operator to print "(Unknown)" instead. Fixes: 428b9fd2dce5 ("platform/x86/amd/pmc: Add delay_suspend module parameter") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Suggested-by: Ilpo Järvinen <[email protected]> Signed-off-by: Daniel Gibson <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Gibson <[email protected]> Date: Wed Jul 22 18:54:01 2026 +0200 platform/x86/amd/pmc: Don't log during intermediate wakeups commit 037f0b03c663a247366673a807834389107995b7 upstream. The ECs in the IdeaPads that need the delay_suspend quirk send lots of messages when charging, which not only causes intermediate wakeups when suspended, but also prevents the device from reaching the deepest suspend state. Because of this amd_pmc_intermediate_wakeup_need_delay() returns false during intermediate wakeups and amd_pmc_want_suspend_delay() is called. So far it always logged its "Delaying suspend by 2.5s ..." messages then, which spams dmesg. This commit makes sure that those messages are only logged once per suspend. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221383 Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Daniel Gibson <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guixiong Wei <[email protected]> Date: Tue Jul 21 23:07:28 2026 +0800 platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug commit 6b63520ed14b17bbe9c2103debbd2152dde1fba3 upstream. When the last CPU of a legacy uncore die goes offline, uncore_freq_remove_die_entry() clears control_cpu. During CPU hotplug re-add, uncore_freq_add_entry() still populates sysfs attributes before assigning the new control CPU. As a result, the current frequency read returns -ENXIO and current_freq_khz is omitted from the recreated sysfs group. Assign control_cpu before the initial read paths and before create_attr_group() so sysfs recreation uses the new online CPU. If sysfs creation fails, restore control_cpu to -1 to keep the error path state consistent. Fixes: 4d73c6772ab7 ("platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency") Cc: [email protected] Acked-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> [weiguixiong: Adapt to legacy uncore_read() and instance_id naming.] Signed-off-by: Guixiong Wei <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Sun Jul 26 17:27:30 2026 -0400 platform/x86: dell-laptop: fix missing cleanups in init error path [ Upstream commit 6e9cab2247e5b243ae2d907ce7c948a8a9c8d61a ] dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill. Fixes: 9c656b07997f ("platform/x86: dell-*: Call new led hw_changed API on kbd brightness change") Fixes: 037accfa14b2 ("dell-laptop: Add debugfs support") Fixes: 2d8b90be4f1c ("dell-laptop: support Synaptics/Alps touchpad led") Fixes: 6cff8d60aa0a ("platform: x86: dell-laptop: Add support for keyboard backlight") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lyndon Sanche <[email protected]> Date: Sun Jul 26 17:27:29 2026 -0400 platform/x86: dell-smbios: Move request functions for reuse [ Upstream commit 33245680ae565aaa114d726bf407c8ff38e75e71 ] Move the dell_send_request and dell_fill_request symbols into smbios-base so that they can be used in multiple modules. Signed-off-by: Lyndon Sanche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Stable-dep-of: 6e9cab2247e5 ("platform/x86: dell-laptop: fix missing cleanups in init error path") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Frederic Weisbecker <[email protected]> Date: Fri May 8 15:16:37 2026 +0200 powerpc/time: Prepare to stop elapsing in dynticks-idle [ Upstream commit c8ba971cf8567d49eb5f43ee90c4e50424331c18 ] Currently the tick subsystem stores the idle cputime accounting in private fields, allowing cohabitation with architecture idle vtime accounting. The former is fetched on online CPUs, the latter on offline CPUs. For consolidation purpose, architecture vtime accounting will continue to account the cputime but will make a break when the idle tick is stopped. The dyntick cputime accounting will then be relayed by the tick subsystem so that the idle cputime is still seen advancing coherently even when the tick isn't there to flush the idle vtime. Prepare for that and introduce three new APIs which will be used in subsequent patches: - vtime_dynticks_start() is deemed to be called when idle enters in dyntick mode. The idle cputime that elapsed so far is accumulated. - vtime_dynticks_stop() is deemed to be called when idle exits from dyntick mode. The vtime entry clocks are fast-forward to current time so that idle accounting restarts elapsing from now. - vtime_reset() is deemed to be called from dynticks idle IRQ entry to fast-forward the clock to current time so that the IRQ time is still accounted by vtime while nohz cputime is paused. Also accumulated vtime won't be flushed from dyntick-idle ticks to avoid accounting twice the idle cputime, along with nohz accounting. Signed-off-by: Frederic Weisbecker <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Shrikanth Hegde <[email protected]> Reviewed-by: Shrikanth Hegde <[email protected]> Link: https://patch.msgid.link/[email protected] Stable-dep-of: c1c1ffa490fc ("powerpc/vtime: Initialize starttime at boot for native accounting") Signed-off-by: Sasha Levin <[email protected]>
Author: Shrikanth Hegde <[email protected]> Date: Fri Jun 5 18:13:29 2026 +0530 powerpc/vtime: Initialize starttime at boot for native accounting [ Upstream commit c1c1ffa490fc33591e90852ed0d38804dd20bc36 ] It was observed that /proc/stat had very large value for one ore more CPUs. It was more visible after recent code simplifications around cpustats. System has 240 CPUs. cat /proc/uptime; 194.18 46500.55 cat /proc/stat cpu 5966 39 837032887 4650070 164 185 100 0 0 0 cpu0 108 0 837030890 19109 24 4 23 0 0 0 Since uptime is 194s, system time of each CPU can't be more than 19400. Sum of system time of all CPUs can't be more than 19400*240 4656000. In fact huge value is close to mftb(). Note mftb doesn't reset on powerVM when the LPAR restart. It only resets when whole system resets. The same issue exists for kexec too. This happens since starttime is not setup at init time. Once it is set then subsequent vtime_delta will return the right delta. Fix it by initializing the starttime during CPU initialization. This fixes the large times seen. cat /proc/uptime; cat /proc/stat 15.78 3694.63 cpu 6035 35 1347 369479 23 144 49 0 0 0 cpu0 19 0 38 1508 0 1 14 0 0 0 Now, system time is reported as expected. Fixes: cf9efce0ce31 ("powerpc: Account time using timebase rather than PURR") Reviewed-by: Christophe Leroy (CS GROUP) <[email protected]> Suggested-by: Christophe Leroy (CS GROUP) <[email protected]> Signed-off-by: Shrikanth Hegde <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jul 22 10:16:05 2026 +0000 ppp: annotate data races in ppp_generic [ Upstream commit 543adf072165aaf2e3b635c0476204f9658ed3bf ] Several fields in struct ppp can be read or updated concurrently from multiple CPUs without synchronization, causing data races: 1. ppp->mru is read concurrently in ppp_receive_nonmp_frame() while being updated via PPPIOCSMRU ioctl. Protect ppp->mru updates in PPPIOCSMRU with ppp_recv_lock(ppp). 2. PPPIOCGFLAGS reads ppp->flags, ppp->xstate, and ppp->rstate unlocked. Wrap the read in ppp_lock(ppp) to get a consistent snapshot. 3. ppp->debug is updated via PPPIOCSDEBUG and read concurrently on fast paths. Annotate reads with READ_ONCE() and writes with WRITE_ONCE(). 4. ppp->last_xmit and ppp->last_recv are updated on TX/RX data paths and read via PPPIOCGIDLE32 / PPPIOCGIDLE64 ioctls. Annotate with WRITE_ONCE() / READ_ONCE() and use max() to handle jiffies subtraction. 5. ppp->npmode[] is updated via PPPIOCSNPMODE and read on TX/RX paths. Annotate with WRITE_ONCE() / READ_ONCE(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Tue Jun 10 16:32:10 2025 +0800 ppp: convert to percpu netstats [ Upstream commit 1a3e9b7a6b09e8ab3d2af019e4a392622685855e ] Convert to percpu netstats to avoid lock contention when reading them. Signed-off-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic") Signed-off-by: Sasha Levin <[email protected]>
Author: Norbert Szetei <[email protected]> Date: Mon Jul 6 11:01:59 2026 +0200 ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF [ Upstream commit ec4215683e47424c9c4762fd3c60f552a3119142 ] pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path. Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <[email protected]> Reviewed-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Thu Jan 29 09:29:02 2026 +0800 ppp: enable TX scatter-gather [ Upstream commit 42fcb213e58a7da33d5d2d7517b4e521025c68c3 ] PPP channels using chan->direct_xmit prepend the PPP header to a skb and call dev_queue_xmit() directly. In this mode the skb does not need to be linear, but the PPP netdevice currently does not advertise scatter-gather features, causing unnecessary linearization and preventing GSO. Enable NETIF_F_SG and NETIF_F_FRAGLIST on PPP devices. In case a linear buffer is required (PPP compression, multilink, and channels without direct_xmit), call skb_linearize() explicitly. Signed-off-by: Qingfang Deng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic") Signed-off-by: Sasha Levin <[email protected]>
Author: Qingfang Deng <[email protected]> Date: Sat Mar 1 21:55:16 2025 +0800 ppp: use IFF_NO_QUEUE in virtual interfaces [ Upstream commit 95d0d094ba26432ec467e2260f4bf553053f1f8f ] For PPPoE, PPTP, and PPPoL2TP, the start_xmit() function directly forwards packets to the underlying network stack and never returns anything other than 1. So these interfaces do not require a qdisc, and the IFF_NO_QUEUE flag should be set. Introduces a direct_xmit flag in struct ppp_channel to indicate when IFF_NO_QUEUE should be applied. The flag is set in ppp_connect_channel() for relevant protocols. While at it, remove the usused latency member from struct ppp_channel. Signed-off-by: Qingfang Deng <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: 543adf072165 ("ppp: annotate data races in ppp_generic") Signed-off-by: Sasha Levin <[email protected]>
Author: Asim Viladi Oglu Manizada <[email protected]> Date: Wed Jul 22 09:38:43 2026 +0000 pppoe: reload header pointer after dev_hard_header() commit e9c238f6fe42fb1b4dba3a578277de32cb487937 upstream. pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Asim Viladi Oglu Manizada <[email protected]> Reviewed-by: Vadim Fedorenko <[email protected]> Reviewed-by: Eric Dumazet <[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: Jann Horn <[email protected]> Date: Mon Jul 6 20:22:42 2026 +0200 proc: Fix broken error paths for namespace links commit 425224c2d700391729be7fe6929a88ef4e2d7a4e upstream. Don't return the return value of down_read_killable() (0) when a ptrace access check fails, return -EACCES as intended. Reported-by: Magnus Lindholm <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: [email protected] Signed-off-by: Jann Horn <[email protected]> Link: https://patch.msgid.link/[email protected] Tested-by: Magnus Lindholm <[email protected]> Signed-off-by: Christian Brauner (Amutable) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Raphael Zimmer <[email protected]> Date: Thu Jul 9 13:26:20 2026 +0200 rbd: Reset positive result codes to zero in object map update path commit a6c4250b81bd30beae94e1b7a4b26fa1193ad2e4 upstream. In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case. Cc: [email protected] Fixes: 22e8bd51bb04 ("rbd: support for object-map and fast-diff") 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: Or Gerlitz <[email protected]> Date: Wed Jun 17 14:21:05 2026 +0300 RDMA/cma: Fix hardware address comparison length in netevent callback [ Upstream commit 18313833e2c6de222a4f6c072da759d0d5888528 ] The cited commit hardcoded the hardware address comparison len to ETH_ALEN. This breaks IPoIB, which uses 20-byte addresses. By truncating the memcmp, the CMA may incorrectly assume the target address is unchanged and fails to abort the stalled connection. Fix this by replacing ETH_ALEN with the dynamic neigh->dev->addr_len to correctly evaluate the full address regardless of the link layer. Fixes: 925d046e7e52 ("RDMA/core: Add a netevent notifier to cma") Signed-off-by: Or Gerlitz <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Thu Jun 18 12:17:51 2026 +0800 RDMA/erdma: initialize ret for empty receive WR lists [ Upstream commit 2815a277c53e9a84784d6410cd55a9da5b33068d ] erdma_post_recv() returns ret after walking the receive work request list. If the caller passes an empty list, the loop is skipped and ret is not assigned. Initialize ret to 0 so an empty receive work request list returns success instead of stack data. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Ruoyu Wang <[email protected]> Reviewed-by: Cheng Xu <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danila Chernetsov <[email protected]> Date: Sat Jun 27 09:59:51 2026 +0000 RDMA/hns: Fix potential integer overflow in mhop hem cleanup [ Upstream commit 9f0f2d2121f16d420199a82ac5bbc242269133b3 ] In hns_roce_cleanup_mhop_hem_table(), the expression: obj = i * buf_chunk_size / table->obj_size; is evaluated using 32-bit unsigned arithmetic because 'buf_chunk_size' is u32 and the usual arithmetic conversions convert 'i' to unsigned int. The result is assigned to a u64 variable, but the multiplication may overflow before the assignment. For sufficiently large HEM tables, this produces an incorrect object index passed to hns_roce_table_mhop_put(). Cast 'i' to u64 before the multiplication so that the intermediate calculation is performed with 64-bit arithmetic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Danila Chernetsov <[email protected]> Reviewed-by: Junxian Huang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aleksandrova Alyona <[email protected]> Date: Wed Jun 24 17:48:46 2026 +0300 RDMA/irdma: Prevent overflows in memory contiguity checks [ Upstream commit 3cda0dfe8c651dcbb9e38977905d3d3b1750c4ab ] irdma_check_mem_contiguous() and irdma_check_mr_contiguous() verify that PBL entries describe physically contiguous memory ranges. Both functions calculate byte offsets using 32-bit operands. For example, with 4 KiB pages, pg_size * pg_idx overflows 32-bit arithmetic when pg_idx reaches 1048576. In the level-2 check, PBLE_PER_PAGE is 512, so i * pg_size * PBLE_PER_PAGE overflows when i reaches 2048. These values are reachable in the driver. For MRs, palloc->total_cnt comes from iwmr->page_cnt, which is calculated by ib_umem_num_dma_blocks(). The MR size is limited by IRDMA_MAX_MR_SIZE, so a 4 GiB MR with 4 KiB pages can reach page_cnt of 1048576. PBLE resources do not exclude this value either: for gen3, the limit is based on avail_sds * MAX_PBLE_PER_SD, and MAX_PBLE_PER_SD is 0x40000, so 4 SDs are enough for 1048576 PBLEs. Cast one operand to u64 before the multiplications so that the offset calculations are performed in 64-bit arithmetic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Aleksandrova Alyona <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Wed Jun 17 14:19:36 2026 +0000 RDMA/irdma: Prevent rereg_mr for non-mem regions [ Upstream commit a846aecb931b4d65d5eafa92a0623545af46d4f2 ] When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions. Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Signed-off-by: Jacob Moroni <[email protected]> Reviewed-by: David Hu <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guoqing Jiang <[email protected]> Date: Mon Nov 13 19:57:24 2023 +0800 RDMA/siw: Only check attrs->cap.max_send_wr in siw_create_qp [ Upstream commit 788bbf4c2fc6e0c35bae9ed5068f484272539d3e ] We can just check max_send_wr here given both max_send_wr and max_recv_wr are defined as u32 type, and we also need to ensure num_sqe (derived from max_send_wr) shouldn't be zero. Acked-by: Bernard Metzler <[email protected]> Signed-off-by: Guoqing Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: bb27fcc67c42 ("RDMA/siw: publish QP after initialization") Signed-off-by: Sasha Levin <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Tue Jun 30 14:00:40 2026 +0800 RDMA/siw: publish QP after initialization [ Upstream commit bb27fcc67c429d97f785c92c35a6c5adebb05d7f ] siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list. Fixes: f29dd55b0236 ("rdma/siw: queue pair methods") Link: https://patch.msgid.link/r/[email protected] Suggested-by: Bernard Metzler <[email protected]> Signed-off-by: Ruoyu Wang <[email protected]> Acked-by: Bernard Metzler <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Thu Mar 5 17:08:25 2026 +0000 RDMA/umem: Add helpers for umem dmabuf revoke lock [ Upstream commit 3a0b171302eea1732a168e26db3b8461f51cc1f9 ] Added helpers to acquire and release the umem dmabuf revoke lock. The intent is to avoid the need for drivers to peek into the ib_umem_dmabuf internals to get the dma_resv_lock and bring us one step closer to abstracting ib_umem_dmabuf away from drivers in general. Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Thu Mar 5 17:08:22 2026 +0000 RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper [ Upstream commit 553dfa8cbd0c6d36adae042d9738ddf8f8765ac7 ] Move the inner logic of ib_umem_dmabuf_get_pinned_with_dma_device() to a new static function that returns with the lock held upon success. The intent is to allow reuse for the future get_pinned_revocable_and_lock function. Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Thu Mar 5 17:08:24 2026 +0000 RDMA/umem: Add pinned revocable dmabuf import interface [ Upstream commit ff85a2ebacbdaec9f28c4660c991295ace93cd1c ] Added an interface for importing a pinned but revocable dmabuf. This interface can be used by drivers that are capable of revocation so that they can import dmabufs from exporters that may require it, such as VFIO. This interface implements a two step process, where drivers will first call ib_umem_dmabuf_get_pinned_revocable_and_lock() which will pin and map the dmabuf (and provide a functional move_notify/invalidate_mappings callback), but will return with the lock still held so that the driver can then populate the callback via ib_umem_dmabuf_set_revoke_locked() without races from concurrent revocations. This scheme also allows for easier integration with drivers that may not have actually allocated their internal MR objects at the time of the get_pinned_revocable* call. Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Yishai Hadas <[email protected]> Date: Thu Aug 1 15:05:13 2024 +0300 RDMA/umem: Add support for creating pinned DMABUF umem with a given dma device [ Upstream commit 682358fd35dece838e6ae2d9d6a69fc0b9a9d411 ] Add support for creating pinned DMABUF umem with a specified DMA device instead of the DMA device of the given IB device. This API will be utilized in the upcoming patches of the series when multiple path DMAs are implemented. Signed-off-by: Yishai Hadas <[email protected]> Link: https://patch.msgid.link/038aad36a43797e5591b20ba81051fc5758124f9.1722512548.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Yishai Hadas <[email protected]> Date: Thu Aug 1 15:05:14 2024 +0300 RDMA/umem: Introduce an option to revoke DMABUF umem [ Upstream commit 253c61dc256b3e6be65657f78b4a8452163ce00f ] Introduce an option to revoke DMABUF umem. This option will retain the umem allocation while revoking its DMA mapping. Furthermore, any subsequent attempts to map the pages should fail once the umem has been revoked. This functionality will be utilized in the upcoming patches in the series, where we aim to delay umem deallocation until the mkey deregistration. However, we must unmap its pages immediately. Signed-off-by: Yishai Hadas <[email protected]> Link: https://patch.msgid.link/a38270f2fe4a194868ca2312f4c1c760e51bcbff.1722512548.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Jacob Moroni <[email protected]> Date: Thu Mar 5 17:08:23 2026 +0000 RDMA/umem: Move umem dmabuf revoke logic into helper function [ Upstream commit 797291a66ce346c96114b72222fc290d402da005 ] This same logic will eventually be reused from within the invalidate_mappings callback which already has the dma_resv_lock held, so break it out into a separate function so it can be reused. Signed-off-by: Jacob Moroni <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin <[email protected]>
Author: Aldo Ariel Panzardo <[email protected]> Date: Tue Jul 7 19:43:14 2026 -0700 rds: drop incoming messages that cross network namespace boundaries [ Upstream commit 5521ae71e32a8069ed4ca6e792179dc57bc43ab2 ] rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison. Fixes: c809195f5523 ("rds: clean up loopback rds_connections on netns deletion") Signed-off-by: Aldo Ariel Panzardo <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Tested-by: Allison Henderson <[email protected]> Signed-off-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Will Deacon <[email protected]> Date: Fri Jul 17 17:25:58 2026 +0100 Revert "arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates" commit 26b483d52417253d88a3a01262ac85914a7aec8e upstream. This reverts commit e057b94772328221405b067c3a85fe479b915dc8. Sashiko points out that updating 'orig_x0' after secure_computing() has returned is too late to handle the case where a seccomp filter is re-evaluated after initially returning SECCOMP_RET_TRACE. This means that a tracer can manipulate the first argument of the syscall behind seccomp's back. For now, revert the initial fix and we'll have another crack at it soon. Since the incorrect fix was cc'd to stable, do the same here with an appropriate fixes tag. Cc: [email protected] Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Link: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sasha Levin <[email protected]> Date: Mon Jul 27 14:07:42 2026 -0400 Revert "drm/amd/display: Add missing kdoc for ALLM parameters" This reverts commit bca364c4c75796650e53837fbec174a866141511. Signed-off-by: Sasha Levin <[email protected]>
Author: Xie Bo <[email protected]> Date: Mon Jul 27 10:06:19 2026 +0800 RISC-V: KVM: Serialize virtual interrupt pending state updates commit d024a0a7879e6f37c0152aacf6d8e37b214a1738 upstream. KVM RISC-V tracks guest local interrupt state with two bitmaps: - irqs_pending: interrupts that should be visible to the guest - irqs_pending_mask: interrupts whose pending state changed The current code updates those bitmaps with independent atomic bitops and assumes a multiple-producer, single-consumer protocol. That model does not actually hold. kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest changes guest-visible HVIP state, sync_interrupts() writes both irqs_pending and irqs_pending_mask to reflect the new guest state back into KVM state. As a result, irqs_pending and irqs_pending_mask form a single logical state transition, but they are not updated atomically as a pair. This allows a race where a newly injected interrupt is lost. For example: CPU0 CPU1 ---- ---- kvm_riscv_vcpu_set_interrupt(VS_SOFT) set_bit(VS_SOFT, irqs_pending) kvm_riscv_vcpu_sync_interrupts() sees guest-cleared HVIP.VSSIP sets irqs_pending_mask clear_bit(IRQ_VS_SOFT, irqs_pending) set_bit(VS_SOFT, irqs_pending_mask) kvm_vcpu_kick() After that interleaving, a later flush can update HVIP without VSSIP even though a new virtual interrupt was injected. In practice, the guest can remain blocked in WFI with work pending. The same pending/mask protocol is shared by VS soft interrupts, PMU overflow delivery, and AIA high interrupt synchronization, so the race is not limited to one interrupt source. Fix this by serializing all updates to irqs_pending and irqs_pending_mask with a per-vCPU raw spinlock. This keeps the pending bit and the dirty mask as one state transition across: - set/unset interrupt - guest HVIP sync - interrupt flush to guest CSR state - vCPU reset - AIA CSR writes that clear dirty state Use non-atomic bitmap operations while holding the lock. Hold the lock across the AIA sync, flush, and pending checks as well, so both bitmap words share the same serialization domain. This intentionally replaces the existing lockless protocol instead of trying to repair it with additional barriers. The problem is not memory ordering on a single field; it is that two separate bitmaps encode one shared state machine while both producers and sync paths can modify them. A per-vCPU raw spinlock keeps the fix small, local, and suitable for backporting. Fixes: cce69aff689e ("RISC-V: KVM: Implement VCPU interrupts and requests handling") Cc: [email protected] Signed-off-by: Xie Bo <[email protected]> Reviewed-by: Anup Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Anup Patel <[email protected]> [ bo: Drop IRQ_PMU_OVF handling, which is not present in 6.6.y, and adapt the reset and CSR helpers to their older signatures. ] Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Thu Dec 12 20:58:15 2024 +0000 rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link commit d920270a6dbf756384b125ce39c17666a7c0c9f4 upstream. Use spin_lock_irq(), not spin_lock_bh() to take the lock when accessing the ->attend_link() to stop a delay in the I/O thread due to an interrupt being taken in the app thread whilst that holds the lock and vice versa. Fixes: a2ea9a907260 ("rxrpc: Use irq-disabling spinlocks between app and I/O thread") Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: [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: David Howells <[email protected]> Date: Wed Jul 22 13:30:03 2026 -0400 rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack [ Upstream commit 6396b48ac0a77165f9c2c40ab03d6c8188c89739 ] We don't need a barrier for the ->tx_bottom value (which indicates the lowest sequence still in the transmission queue) and the ->acks_hard_ack value (which tracks the DATA packets hard-ack'd by the latest ACK packet received and thus indicates which DATA packets can now be discarded) as the app thread doesn't use either value as a reference to memory to access. Rather, the app thread merely uses these as a guide to how much space is available in the transmission queue Change the code to use READ/WRITE_ONCE() instead. Also, change rxrpc_check_tx_space() to use the same value for tx_bottom throughout. Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e66f8f32f501 ("rxrpc: Fix socket notification race") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Jul 22 13:30:05 2026 -0400 rxrpc: Fix notification vs call-release vs recvmsg [ Upstream commit 2fd895842d49c23137ae48252dd211e5d6d8a3ed ] When a call is released, rxrpc takes the spinlock and removes it from ->recvmsg_q in an effort to prevent racing recvmsg() invocations from seeing the same call. Now, rxrpc_recvmsg() only takes the spinlock when actually removing a call from the queue; it doesn't, however, take it in the lead up to that when it checks to see if the queue is empty. It *does* hold the socket lock, which prevents a recvmsg/recvmsg race - but this doesn't prevent sendmsg from ending the call because sendmsg() drops the socket lock and relies on the call->user_mutex. Fix this by firstly removing the bit in rxrpc_release_call() that dequeues the released call and, instead, rely on recvmsg() to simply discard released calls (done in a preceding fix). Secondly, rxrpc_notify_socket() is abandoned if the call is already marked as released rather than trying to be clever by setting both pointers in call->recvmsg_link to NULL to trick list_empty(). This isn't perfect and can still race, resulting in a released call on the queue, but recvmsg() will now clean that up. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells <[email protected]> Reviewed-by: Jeffrey Altman <[email protected]> cc: Marc Dionne <[email protected]> cc: Junvyyang, Tencent Zhuque Lab <[email protected]> cc: LePremierHomme <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e66f8f32f501 ("rxrpc: Fix socket notification race") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Jul 22 13:30:06 2026 -0400 rxrpc: Fix socket notification race [ Upstream commit e66f8f32f50116670dbbee5bc9e692cd2cd0c8f8 ] There's a race between rxrpc_recvmsg() and rxrpc_notify_socket(), whereby the latter's attempt to avoid disabling interrupts and taking the socket's recvmsg_lock if the call is already queued may happen simultaneously with the former's discarding of a call that has nothing queued. Fix this by removing the shortcut. Note that this only affects userspace's use of AF_RXRPC; the AFS filesystem driver doesn't use the socket queue. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [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: David Howells <[email protected]> Date: Wed Jul 22 10:48:35 2026 -0400 rxrpc: Pull out certain app callback funcs into an ops table [ Upstream commit 23738cc8048322cf324f330cd697380fb3455da5 ] A number of functions separately furnish an AF_RXRPC socket with callback function pointers into a kernel app (such as the AFS filesystem) that is using it. Replace most of these with an ops table for the entire socket. This makes it easier to add more callback functions. Note that the call incoming data processing callback is retaind as that gets set to different things, depending on the type of op. Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: dc175389b18c ("rxrpc: serialize kernel accept preallocation with socket teardown") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Li Daming <[email protected]> Date: Wed Jul 22 10:48:36 2026 -0400 rxrpc: serialize kernel accept preallocation with socket teardown [ Upstream commit dc175389b18c29a5303ee83169ec653adfae3e17 ] rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog. Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Li Daming <[email protected]> Signed-off-by: Ren Wei <[email protected]> Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [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: David Howells <[email protected]> Date: Wed Jul 22 13:30:04 2026 -0400 rxrpc: Use irq-disabling spinlocks between app and I/O thread [ Upstream commit a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7 ] Where a spinlock is used by both the application thread and the I/O thread, use irq-disabling locking so that an interrupt taken on the app thread doesn't also slow down the I/O thread. Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: [email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e66f8f32f501 ("rxrpc: Fix socket notification race") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Wed Apr 10 17:09:45 2024 +0200 sched/vtime: Get rid of generic vtime_task_switch() implementation [ Upstream commit 89d6910cc562ab34d1f1c08f3cf0a9700b8bf2c4 ] The generic vtime_task_switch() implementation gets built only if __ARCH_HAS_VTIME_TASK_SWITCH is not defined, but requires an architecture to implement arch_vtime_task_switch() callback at the same time, which is confusing. Further, arch_vtime_task_switch() is implemented for 32-bit PowerPC architecture only and vtime_task_switch() generic variant is rather superfluous. Simplify the whole vtime_task_switch() wiring by moving the existing generic implementation to PowerPC. Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Frederic Weisbecker <[email protected]> Reviewed-by: Nicholas Piggin <[email protected]> Acked-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/2cb6e3caada93623f6d4f78ad938ac6cd0e2fda8.1712760275.git.agordeev@linux.ibm.com Stable-dep-of: c1c1ffa490fc ("powerpc/vtime: Initialize starttime at boot for native accounting") Signed-off-by: Sasha Levin <[email protected]>
Author: Qing Luo <[email protected]> Date: Tue Jul 21 09:55:32 2026 +0800 sctp: auth: verify auth requirement when auth_chunk is NULL [ Upstream commit 8e04823c120b376ef7dab14b60ebf6823aa16c14 ] sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Signed-off-by: Qing Luo <[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: Jun Yang <[email protected]> Date: Tue Jul 21 21:14:05 2026 +0800 sctp: don't free the ASCONF's own transport in DEL-IP processing commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f upstream. sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport. Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter") Cc: [email protected] Signed-off-by: Jun Yang <[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: Greg Kroah-Hartman <[email protected]>
Author: HanQuan <[email protected]> Date: Mon Jul 13 03:20:21 2026 +0000 sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid [ Upstream commit ff04b26794a16a8a879eb4fd2c02c2d6b03850e9 ] sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: HanQuan <[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: Xin Long <[email protected]> Date: Fri Jul 10 14:12:35 2026 -0400 sctp: fix auth_hmacs array size in struct sctp_cookie [ Upstream commit e0b5252a59383b77d1b8dbeda00b7184dd95f4d3 ] The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Reported-by: Yuan Tan <[email protected]> Reported-by: Xin Liu <[email protected]> Reported-by: Zihan Xi <[email protected]> Reported-by: Ren Wei <[email protected]> Signed-off-by: Xin Long <[email protected]> Link: https://patch.msgid.link/634a0de0d5de29532915e6d47c92a0cbc206e03f.1783707155.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang (Microsoft) <[email protected]> Date: Thu Jul 9 21:07:18 2026 -0400 sctp: validate stream count in sctp_process_strreset_inreq() [ Upstream commit 18ae07691d43183d270de8be9dc8e027906015d9 ] When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Xin Long <[email protected]> Signed-off-by: Cen Zhang (Microsoft) <[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: Kuniyuki Iwashima <[email protected]> Date: Thu Jun 20 19:10:51 2024 -0700 selftest: af_unix: Add Kconfig file. [ Upstream commit 11b006d6896c0471ad29c6f1fb1af606e7ba278f ] diag_uid selftest failed on NIPA where the received nlmsg_type is NLMSG_ERROR [0] because CONFIG_UNIX_DIAG is not set [1] by default and sock_diag_lock_handler() failed to load the module. # # Starting 2 tests from 2 test cases. # # RUN diag_uid.uid.1 ... # # diag_uid.c:159:1:Expected nlh->nlmsg_type (2) == SOCK_DIAG_BY_FAMILY (20) # # 1: Test terminated by assertion # # FAIL diag_uid.uid.1 # not ok 1 diag_uid.uid.1 Let's add all AF_UNIX Kconfig to the config file under af_unix dir so that NIPA consumes it. Fixes: ac011361bd4f ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.") Link: https://netdev-3.bots.linux.dev/vmksft-net/results/644841/104-diag-uid/stdout [0] Link: https://netdev-3.bots.linux.dev/vmksft-net/results/644841/config [1] Reported-by: Jakub Kicinski <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: f8b1abed7361 ("selftests: af_unix: add USER_NS config") Signed-off-by: Sasha Levin <[email protected]>
Author: Malaya Kumar Rout <[email protected]> Date: Sat Jul 4 16:27:36 2026 +0530 selftests/alsa: Fix memory leak in find_controls error path [ Upstream commit cb89f0c1aed02eb233c4271f76f830b37e222ff6 ] In find_controls(), card_data is allocated with malloc() but when snd_ctl_open_lconf() fails, the code jumps to next_card without freeing the allocated memory. This results in a memory leak for each card where snd_ctl_open_lconf() fails. Add free(card_data) before goto next_card to ensure proper cleanup of the allocated memory in the error path. Fixes: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest") Signed-off-by: Malaya Kumar Rout <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Borkmann <[email protected]> Date: Wed Jul 22 15:39:08 2026 +0800 selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs commit e0fcb42bc6f41bab2895757d6610616b3820eff7 upstream. Extend the verifier_ld_ind BPF selftests with subprogs containing ld_{abs,ind} and craft the test in a way where the invalid register read is rejected in the fixed case. Also add a success case each, and add additional coverage related to the BTF return type enforcement. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_ld_ind [...] #611/1 verifier_ld_ind/ld_ind: check calling conv, r1:OK #611/2 verifier_ld_ind/ld_ind: check calling conv, r1 @unpriv:OK #611/3 verifier_ld_ind/ld_ind: check calling conv, r2:OK #611/4 verifier_ld_ind/ld_ind: check calling conv, r2 @unpriv:OK #611/5 verifier_ld_ind/ld_ind: check calling conv, r3:OK #611/6 verifier_ld_ind/ld_ind: check calling conv, r3 @unpriv:OK #611/7 verifier_ld_ind/ld_ind: check calling conv, r4:OK #611/8 verifier_ld_ind/ld_ind: check calling conv, r4 @unpriv:OK #611/9 verifier_ld_ind/ld_ind: check calling conv, r5:OK #611/10 verifier_ld_ind/ld_ind: check calling conv, r5 @unpriv:OK #611/11 verifier_ld_ind/ld_ind: check calling conv, r7:OK #611/12 verifier_ld_ind/ld_ind: check calling conv, r7 @unpriv:OK #611/13 verifier_ld_ind/ld_abs: subprog early exit on ld_abs failure:OK #611/14 verifier_ld_ind/ld_ind: subprog early exit on ld_ind failure:OK #611/15 verifier_ld_ind/ld_abs: subprog with both paths safe:OK #611/16 verifier_ld_ind/ld_ind: subprog with both paths safe:OK #611/17 verifier_ld_ind/ld_abs: reject void return subprog:OK #611/18 verifier_ld_ind/ld_ind: reject void return subprog:OK #611 verifier_ld_ind:OK Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Philo Lu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Jul 10 20:04:41 2026 +0200 selftests: af_unix: add USER_NS config [ Upstream commit f8b1abed736111f914b2c567d9a3db1f71e788e8 ] This is required to use unshare(CLONE_NEWUSER). This has not been seen on NIPA before, because the 'af_unix' tests are executed with the 'net' ones, merging their config files. USER_NS is present in tools/testing/selftests/net/config. This issue is visible when only the af_unix config is used on top of the default one. This is the recommended way to execute selftest targets. Fixes: ac011361bd4f ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Fri Jul 10 20:04:42 2026 +0200 selftests: openvswitch: add config file [ Upstream commit 441a820ccef9af80a9ac5a4c85b9c396e595967c ] The kselftests doc mentions that a config file should be present "if a test needs specific kernel config options enabled". This selftest requires some kernel config, but no config file was provided. We could say that a sub-target could use the parent's config file, but the kselftests doc doesn't mention anything about that. Plus the net/openvswitch target is the only net target without a config file. Here is a new config file, which is a trimmed version of the net one, with hopefully the minimal required kconfig on top of 'make defconfig'. The Fixes tag points to the introduction of the net/openvswitch target, just to help validating this target on stable kernels. Fixes: 25f16c873fb1 ("selftests: add openvswitch selftest suite") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Eelco Chaudron <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Madani <[email protected]> Date: Thu Jul 23 10:19:20 2026 -0400 selinux: avoid sk_socket dereference in selinux_sctp_bind_connect() [ Upstream commit 56acfeb10019e200ab6787d01f8d7cbe0f01526f ] selinux_sctp_bind_connect() dereferences sk->sk_socket to pass a struct socket * to selinux_socket_bind() and selinux_socket_connect_helper(). However, when the hook is invoked from the ASCONF softirq path (sctp_process_asconf), there is no file reference guaranteeing that sk->sk_socket is non-NULL. The setsockopt callers (bindx, connectx, set_primary, sendmsg connect) hold a file reference and are not affected. Both selinux_socket_bind() and selinux_socket_connect_helper() immediately resolve sock->sk, never using the struct socket * for anything else. Refactor the inner logic into helpers that take a struct sock * directly so that selinux_sctp_bind_connect() never needs to touch sk->sk_socket at all. Cc: [email protected] Fixes: d452930fd3b9 ("selinux: Add SCTP support") Suggested-by: Stephen Smalley <[email protected]> Signed-off-by: Tristan Madani <[email protected]> Reviewed-by: Stephen Smalley <[email protected]> Tested-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Tue Oct 28 09:56:38 2025 +0100 seqlock: Allow KASAN to fail optimizing commit b94d45b6bbb42571ec225d3be0e7457c8765a5b4 upstream. Some KASAN builds are failing to properly optimize this code -- luckily we don't care about core quality for KASAN builds, so just exclude it. Reported-by: kernel test robot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Tue May 19 13:03:15 2026 +0200 seqlock: Allow UBSAN_ALIGNMENT to fail optimizing commit 88331c4ec23a28c1006ec532fa64763d4c695e90 upstream. With gcc-15 and gcc-16 with UBSAN_ALIGNMENT enabled the compiler fails to inline and optimize __scoped_seqlock_bug() away on s390: s390x-16.1.0-ld: kernel/sched/build_policy.o: in function `__scoped_seqlock_next': /.../seqlock.h:1286:(.text+0x22030): undefined reference to `__scoped_seqlock_bug' Fix this by adding UBSAN_ALIGNMENT to the list of config options where a not inlined empty __scoped_seqlock_bug() is allowed. Closes: https://lore.kernel.org/r/[email protected]/ Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Thu Dec 4 11:43:32 2025 +0100 seqlock: Cure some more scoped_seqlock() optimization fails commit 90dfeef1cd38dff19f8b3a752d13bfd79f0f7694 upstream. Arnd reported an x86 randconfig using gcc-15 tripped over __scoped_seqlock_bug(). Turns out GCC chose not to inline the scoped_seqlock helper functions and as such was not able to optimize properly. [ mingo: Clang fails the build too in some circumstances. ] Reported-by: Arnd Bergmann <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Oleg Nesterov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiangshan Yi <[email protected]> Date: Wed Jul 15 15:35:46 2026 +0800 serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms commit 7fb13fd7e9a59a37cd911efff83abe19e3ee029d upstream. Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks. Fixes: b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") Cc: stable <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jiangshan Yi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tapio Reijonen <[email protected]> Date: Wed Jul 22 09:54:28 2026 -0400 serial: max310x: implement gpio_chip::get_direction() [ Upstream commit a483b1a91b33b7533280e7c3efd2bc1275caef18 ] It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit selects output), which the existing direction_input/output callbacks already program, so the current direction can be read back directly. Fixes: f65444187a66 ("serial: New serial driver MAX310X") Cc: stable <[email protected]> Signed-off-by: Tapio Reijonen <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Hugo Villeneuve <[email protected]> Link: https://patch.msgid.link/20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hugo Villeneuve <[email protected]> Date: Wed Jul 22 09:54:27 2026 -0400 serial: max310x: replace bare use of 'unsigned' with 'unsigned int' (checkpatch) [ Upstream commit 79b69eb09cf5b6a77e621b2838b7e0d38113debb ] Fixes the following checkpatch warnings: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' With this change, the affected functions now match the prototypes in struct gpio_chip. Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hugo Villeneuve <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Stable-dep-of: a483b1a91b33 ("serial: max310x: implement gpio_chip::get_direction()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hugo Villeneuve <[email protected]> Date: Thu Jul 16 17:08:09 2026 -0400 serial: sc16is7xx: implement gpio get_direction() callback commit af071d9e07e57cfff239e8d09d2f3b05ebc9c667 upstream. It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable <[email protected]> Signed-off-by: Hugo Villeneuve <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huiwen He <[email protected]> Date: Fri Jul 3 13:32:56 2026 +0800 smb/client: handle overlapping allocated ranges in fallocate [ Upstream commit b09ae45d85dc816987a71db9eebc54b0ae288e94 ] smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Signed-off-by: Huiwen He <[email protected]> Reviewed-by: ChenXiaoSong <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yichong Chen <[email protected]> Date: Thu Jul 16 13:25:23 2026 +0800 smb: client: validate DFS referral PathConsumed [ Upstream commit f6f5ee2aa33b350c671721b965251c42cebb962e ] parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral. Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Yichong Chen <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: MinJea Kim <[email protected]> Date: Tue Jul 14 22:14:21 2026 +0900 staging: rtl8723bs: fix inverted HT40 secondary channel offset commit 30d49cba27f8905bc288cef5846963f0004f644c upstream. rtw_get_chan_type() maps the driver's channel offset to nl80211 channel types the wrong way around. In this driver HAL_PRIME_CHNL_OFFSET_LOWER means the primary channel is the lower 20 MHz half of the 40 MHz pair, i.e. the secondary channel is above the primary one: rtw_get_center_ch() computes the center channel as "channel + 2" for OFFSET_LOWER, and bwmode_update_check() sets OFFSET_LOWER when the AP's HT operation IE announces SCA (secondary channel above). In nl80211 terms that is NL80211_CHAN_HT40PLUS, not HT40MINUS. Because of the inversion, cfg80211_rtw_get_channel() reports an HT40+ association as HT40-. For an HT40+ AP on a low channel (e.g. channel 3) the resulting chandef spans below the 2.4 GHz band edge and is invalid, so the regulatory core tears the connection down 60 seconds (REG_ENFORCE_GRACE_MS) after the AP's country IE triggers a regdomain change: reg_check_chans_work() considers the reported chandef unusable and calls cfg80211_leave(). The supplicant then reconnects, the country IE changes the regdomain again, and the cycle repeats, causing a disconnect/reconnect loop every ~65 seconds for as long as the link is up. Observed on a TECLAST X80 Power tablet (RTL8723BS) associated to an HT40+ AP on channel 3 with a KR country IE; a kprobe trace showed cfg80211_disconnect() being invoked from reg_check_chans_work(). With the mapping fixed, "iw dev wlan0 info" reports the correct "width: 40 MHz, center1: 2432 MHz" and the periodic disconnects stop. Fixes: 5402cc178c5d ("staging: rtl8723bs: add get_channel cfg80211 implementation") Cc: [email protected] Assisted-by: Claude-Code:claude-fable-5 bpftrace Signed-off-by: MinJea Kim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Moksh Panicker <[email protected]> Date: Thu Jun 25 20:29:11 2026 +0000 staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() commit 0e95ff792ae0aa6fbad9455943e9e1e4062670e9 upstream. rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable <[email protected]> Signed-off-by: Moksh Panicker <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chuck Lever <[email protected]> Date: Thu Jul 23 21:25:13 2026 -0400 SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists [ Upstream commit e9be933959b581effd426f93b86654f5fbf0c574 ] The crypto/krb5 library accepts data in scatterlist form, but the GSS-API layer presents RPC payloads as struct xdr_buf. Bridge that gap with a pair of helper functions: xdr_buf_to_sg() - populate a caller-supplied scatterlist array from a byte range xdr_buf_to_sg_alloc() - populate a caller-supplied inline scatterlist, chaining to a heap- allocated overflow for large payloads The inline array (typically stack-allocated at eight entries) covers the common case of small RPCs with no heap allocation on the encrypt/decrypt path. Only buffers spanning many pages incur a kmalloc for the chained extension. The segment-walking logic follows the same head, page array, tail traversal as xdr_process_buf(), but populates a scatterlist directly rather than invoking a per-segment callback. sg_next() traversal makes the walker safe for chained scatterlists. Once subsequent patches reroute all per-message crypto operations through crypto/krb5, xdr_process_buf() loses its last callers and is removed. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton <[email protected]> Acked-by: Anna Schumaker <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Layton <[email protected]> Date: Thu Jul 23 21:25:12 2026 -0400 sunrpc: allocate a separate bvec array for socket sends [ Upstream commit 6b3b697d65d46a0f640216a3f6c72856c159c567 ] svc_tcp_sendmsg() calls xdr_buf_to_bvec() with the second slot of rq_bvec as the start, but doesn't reduce the array length by one, which could lead to an array overrun. Also, rq_bvec is always rq_maxpages in length, which can be too short in some cases, since the TCP record marker consumes a slot. Fix both problems by adding a separate bvec array to the svc_sock that is specifically for sending. For TCP, make this array one slot longer than rq_maxpages, to account for the record marker. For UDP, only allocate as large an array as we need since it's limited to 64k of payload. Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chuck Lever <[email protected]> Date: Thu Jul 23 21:25:15 2026 -0400 SUNRPC: Return an error from xdr_buf_to_bvec() on overflow [ Upstream commit 18c1cc69886192e33536498289d26dba6894e3d5 ] xdr_buf_to_bvec() returns a slot count even when the caller's bvec budget is exhausted partway through the xdr_buf. Callers feed that count into iov_iter_bvec() and continue as if the conversion had succeeded, silently sending or writing fewer bytes than the data length declares. For an NFS WRITE the server reports the truncated transfer to the client as full success. The overflow represents an internal invariant violation: a higher layer reserved a bvec budget too small for the xdr_buf it then asked the encoder to convert. That is a server-side fault, not a media I/O failure and not a malformed client argument. Change xdr_buf_to_bvec() to return a signed int and have the overflow label return -ESERVERFAULT. Update the three callers to detect the negative return and fail the request: nfsd_vfs_write() folds the error into host_err, which nfserrno() translates to nfserr_serverfault for the WRITE reply; svc_udp_sendto() and svc_tcp_sendmsg() propagate the error out of the send path. Reported-by: Chris Mason <[email protected]> Fixes: 2eb2b9358181 ("SUNRPC: Convert svc_tcp_sendmsg to use bio_vecs directly") Cc: [email protected] Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Oleg Nesterov <[email protected]> Date: Sun Jul 26 08:42:06 2026 -0400 taskstats: fill_stats_for_tgid: use for_each_thread() [ Upstream commit ed5378a387fd7c382497f2abcf4605e030b64044 ] do/while_each_thread should be avoided when possible. Plus I _think_ this change allows to avoid lock_task_sighand() but I am not sure, I forgot everything about taskstats. In any case, this code does not look right in that the same thread can be accounted twice: taskstats_exit() can account the exiting thread in signal->stats and drop ->siglock but this thread is still on the thread-group list, so lock_task_sighand() can't help. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Oleg Nesterov <[email protected]> Cc: Eric W. Biederman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: b3e4fbb04220 ("taskstats: retain dead thread stats in TGID queries") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yiyang Chen <[email protected]> Date: Sun Jul 26 08:42:07 2026 -0400 taskstats: retain dead thread stats in TGID queries [ Upstream commit b3e4fbb04220efc3bc022bcf31b5689d39c6b111 ] Patch series "taskstats: fix TGID dead-thread stat retention", v3. This series fixes a taskstats TGID aggregation bug where fields added in the TGID query path were not preserved after thread exit, and adds a kselftest covering the regression. The first patch keeps the cached TGID aggregate used for dead threads in step with the fields already accumulated for live threads, and also fixes the final TGID exit notification emitted when group_dead is true. The second patch adds a kselftest that verifies TGID CPU stats do not regress after a worker thread exits and has been reaped. This patch (of 2): fill_stats_for_tgid() builds TGID stats from two sources: the cached aggregate in signal->stats and a scan of the live threads in the group. However, fill_tgid_exit() only accumulates delay accounting into signal->stats. This means that once a thread exits, TGID queries lose the fields that fill_stats_for_tgid() adds for live threads. This gap was introduced incrementally by two earlier changes that extended fill_stats_for_tgid() but did not make the corresponding update to fill_tgid_exit(): - commit 8c733420bdd5 ("taskstats: add e/u/stime for TGID command") added ac_etime, ac_utime, and ac_stime to the TGID query path. - commit b663a79c1915 ("taskstats: add context-switch counters") added nvcsw and nivcsw to the TGID query path. As a result, those fields were accounted for live threads in TGID queries, but were dropped from the cached TGID aggregate after thread exit. The final TGID exit notification emitted when group_dead is true also copies that cached aggregate, so it loses the same fields. Factor the per-task TGID accumulation into tgid_stats_add_task() and use it in both fill_stats_for_tgid() and fill_tgid_exit(). This keeps the cached aggregate used for dead threads aligned with the live-thread accumulation used by TGID queries. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/abd2a15d33343636ab5ba43d540bcfe508bd66c7.1776094300.git.cyyzero16@gmail.com Fixes: 8c733420bdd5 ("taskstats: add e/u/stime for TGID command") Fixes: b663a79c1915 ("taskstats: add context-switch counters") Signed-off-by: Yiyang Chen <[email protected]> Acked-by: Balbir Singh <[email protected]> Cc: Dr. Thomas Orgis <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Wang Yaxin <[email protected]> Cc: Yang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daehyeon Ko <[email protected]> Date: Tue Jul 14 22:19:39 2026 +0900 tipc: clear sock->sk on the failed-insert path in tipc_sk_create() commit ba0533fc163f905fe817cfabdf8ed4058da44800 upstream. When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: if (tipc_sk_insert(tsk)) { sk_free(sk); pr_warn("Socket create failed; port number exhausted\n"); return -EINVAL; } This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact "failed accept() releases a pre-allocated child" case with "if (sk == NULL) return 0;", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Fixes: 00aff3590fc0 ("net: tipc: fix possible refcount leak in tipc_sk_create()") Cc: [email protected] Reviewed-by: Tung Nguyen <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Signed-off-by: Daehyeon Ko <[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: Greg Kroah-Hartman <[email protected]>
Author: Helen Koike <[email protected]> Date: Mon Jul 13 17:49:35 2026 -0300 tipc: fix infinite loop in __tipc_nl_compat_dumpit [ Upstream commit 22f8aa35964e8f2ab026578f45befc9605fd1b28 ] cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=85d0bec020d805014a3a Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat") Signed-off-by: Helen Koike <[email protected]> Reviewed-by: Tung Nguyen <[email protected] Reviewed-by: Tung Nguyen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang (Microsoft) <[email protected]> Date: Tue Jul 14 00:15:41 2026 -0400 tipc: fix u16 MTU truncation in media and bearer MTU validation [ Upstream commit 9f29cd8a8e7901a2617c8064ce9f50fc67b97cb8 ] Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX. Fixes: 901271e0403a ("tipc: implement configuration of UDP media MTU") Reported-by: [email protected] Closes: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com Reviewed-by: Vadim Fedorenko <[email protected]> Signed-off-by: Cen Zhang (Microsoft) <[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: Li Xiasong <[email protected]> Date: Wed Jul 22 13:29:40 2026 -0400 tipc: restrict socket queue dumps in enqueue tracepoints [ Upstream commit acd7df8d955480a6f6e5bb809da67b1500cc3cf4 ] tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 </TASK> The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context. Fixes: 01e661ebfbad ("tipc: add trace_events for tipc socket") Cc: [email protected] Signed-off-by: Li Xiasong <[email protected]> Reviewed-by: Tung Nguyen <[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: Rishikesh Jethwani <[email protected]> Date: Thu Jul 9 16:44:36 2026 -0600 tls: device: push pending open record on splice EOF [ Upstream commit eaa39f9f8ac8c1d032cd26b9cd572804e9d7683f ] On kTLS device-offload sockets, sendfile() with count > EOF can reach ->splice_eof() with a fully assembled but still-open TLS record left pending. tls_device_splice_eof() only flushes partially sent records, so an abrupt close() can drop the final record and the peer receives a short file. Fix tls_device_splice_eof() to also push pending open records. This matches the software path, where splice EOF already flushes pending open records. Fixes: d4c1e80b0d1b ("tls/device: Use splice_eof() to flush") Link: https://lore.kernel.org/netdev/CAMPsyauZ+jzG9AysO0FWv6ZY0kvCUpjX_U7o=oOjCuOQ87BCgg@mail.gmail.com/ Reported-by: Nils Juenemann <[email protected]> Signed-off-by: Rishikesh Jethwani <[email protected]> Tested-by: Nils Juenemann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Jul 20 19:12:38 2026 +0900 tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match() commit f418d68d71fd4a0a9cef92377bc8c4c3334b5b53 upstream. eprobe_dyn_event_match() checks if the target event system in argv[0] matches ep->event_system using strncmp(ep->event_system, argv[0], len). However, if ep->event_system is longer than len (e.g. "eprobes" vs "ep/event"), strncmp() still returns 0 because the first len characters match. Check that ep->event_system[len] is '\0' to ensure exact system name matching. Link: https://lore.kernel.org/all/178454235856.290363.14872590900774231133.stgit@devnote2/ Fixes: 7d5fda1c841f ("tracing: Fix event probe removal from dynamic events") Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Jul 20 19:12:10 2026 +0900 tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args() commit 15f197856d68882af9416fc97516bb55079b7677 upstream. In trace_probe_match_command_args(), a stack buffer buf[MAX_ARGSTR_LEN + 1] (256 bytes) is used to format "<name>=<comm>". However, since name can be up to 32 bytes (MAX_ARG_NAME_LEN) and comm up to 255 bytes (MAX_ARGSTR_LEN), the formatted string can exceed 256 bytes and get truncated by snprintf(), causing spurious argument matching failures. Instead of formatting into a temporary buffer on stack, compare the argument name, the '=' delimiter, and the comm expression directly. Link: https://lore.kernel.org/all/178454233010.290363.10428767141343428804.stgit@devnote2/ Fixes: eb5bf81330a7 ("tracing/kprobe: Add per-probe delete from event") Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Jul 20 19:12:29 2026 +0900 tracing/probes: Fix potential underflow in LEN_OR_ZERO macro commit 8ce20bfba48902e1382187cd1a852f7cf3a1e739 upstream. In __set_print_fmt(), LEN_OR_ZERO is defined as (len ? len - pos : 0). If len is non-zero but smaller than pos, len - pos evaluates to a negative integer. When passed as a size argument to snprintf(), this negative value is cast to a large unsigned size_t, bypassing buffer size limits. Ensure len > pos before subtracting to avoid integer underflow. Link: https://lore.kernel.org/all/178454234934.290363.15247317871499514139.stgit@devnote2/ Fixes: 5bf652aaf46c ("tracing/probes: Integrate duplicate set_print_fmt()") Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Jul 20 19:12:20 2026 +0900 tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err() commit a9d6fb284039a5d3858a1d9f9a0d7e46cfb7c2d4 upstream. If trace_probe_log.argc is 0 in __trace_probe_log_err(), the loop constructing the command string will not execute and p will remain equal to command. Writing to *(p - 1) will cause an out-of-bounds access before command. This should not happen, but better to be treated. Reject if trace_probe_log.argc is 0. Link: https://lore.kernel.org/all/178454233992.290363.18323091580600697731.stgit@devnote2/ Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events") Cc: [email protected] Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Mon Jul 27 19:37:50 2026 -0400 tracing/user_events: Fix use-after-free in user_event_mm_dup() [ Upstream commit 50fd6dd755c6e48a38af2fa4621167eea56829c2 ] user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated. Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Reported-by: XIAO WU <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Beau Belgrave <[email protected]> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Tue Jul 21 21:11:43 2026 -0400 tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev commit 144f29e85702234b23d2a62abf723e6a17eb5427 upstream. If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it. Cc: [email protected] Link: https://patch.msgid.link/[email protected] Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin") Reported-by: Sashiko <[email protected]> Link: https://sashiko.dev/#/patchset/20260715143604.14481-1-gaikwad.dcg%40gmail.com Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: deepakraog <[email protected]> Date: Wed Jul 15 20:06:04 2026 +0530 tracing: Fix resource leak on mmiotrace trace_pipe close commit c1d87e724ae55e781b7cc7ccafb34d9e668582b2 upstream. The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak. Cc: [email protected] Fixes: c521efd1700a8 ("tracing: Add pipe_close interface) Link: https://patch.msgid.link/[email protected] Signed-off-by: deepakraog <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Tue Jul 21 14:28:02 2026 -0400 udmabuf: Do not create malformed scatterlists [ Upstream commit 5bf888673e0dda5a53220fa0c4956271a46c353c ] Using a sg_set_folio() loop for every 4K results in a malformed scatterlist because sg_set_folio() has an issue with offsets > PAGE_SIZE and because scatterlist expects the creator to build a list which consolidates any physical contiguity. sg_alloc_table_from_pages() creates a valid scatterlist directly from a struct page array, so go back to that. Remove the offsets allocation and just store an array of tail pages as it did before the below commit. Everything wants that anyhow. Fixes: 0c8b91ef5100 ("udmabuf: add back support for mapping hugetlb pages") Reported-by: Julian Orth <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Vivek Kasireddy <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Link: https://patch.msgid.link/[email protected] Stable-dep-of: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Robert Mader <[email protected]> Date: Sat Jun 27 12:57:25 2026 +0200 udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf() commit 1d0e25c1ddf2063c499264fb2ba0fa6a3e4f8a00 upstream. The message of commit 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") says: > The CPU sync at map/unmap time is also redundant for udmabuf: > begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit > cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU > access is requested through the dma-buf interface. This, however, does not apply to the first time begin_cpu_udmabuf() is called on an udmabuf, in which case the implementation previously relied on get_sg_table() to perform the cache synchronisation. Ensure to call dma_sync_sgtable_for_cpu() in that case as well. Fixes: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Robert Mader <[email protected]> Reviewed-by: Mikhail Gavrilov <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Diego Fernando Mancera Gomez <[email protected]> Date: Fri Jul 17 02:07:04 2026 -0600 usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnect [ Upstream commit 71132cedd1ecbc4032d76e9928c18a10f7e39b80 ] uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a 'struct completion' for a pre-firmware device (to be waited on in .disconnect()), or a 'struct usbatm_data' for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small 'struct completion' stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to 'struct usbatm_data' and takes instance->serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470e2c60 by task kworker/1:2/982 ... __mutex_lock+0x152a/0x1b80 usbatm_usb_disconnect+0x70/0x820 uea_disconnect+0x133/0x2c0 usb_unbind_interface+0x1dd/0x9e0 ... which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes to the right of allocated 96-byte region [ffff8880470e2c00, ffff8880470e2c60) Reject such inconsistent descriptors in uea_probe() so that both handlers always make the same pre/post-firmware decision. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=e62a973f8322b3bbe3ac Fixes: e2674dfbed8a ("usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()") Signed-off-by: Diego Fernando Mancera Gomez <[email protected]> Acked-by: Stanislaw Gruszka <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yang <[email protected]> Date: Thu Jul 16 18:41:26 2026 +0800 usb: chipidea: fix usage_count leak when autosuspend_delay is negative commit fc3afb5728e297994863f8a2a01b88a920bbf53e upstream. The probe() calls pm_runtime_use_autosuspend(), but remove() does not call pm_runtime_dont_use_autosuspend(). This can lead to a usage_count leak if autosuspend_delay is set to a negative value. The pm_runtime_use_autosuspend() also notes that it's important to undo this with pm_runtime_dont_use_autosuspend() at driver exit time. Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support") Cc: stable <[email protected]> Assisted-by: Claude:claude-sonnet-4.6 Signed-off-by: Xu Yang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jinchao Wang <[email protected]> Date: Thu Jul 16 06:42:17 2026 -0400 usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback commit d5e5cd3654d2b5359a12ea6586120f05b28634ee upstream. dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the "emulated single-request FIFO" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as "the slot is free". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=faf3a6cf579fc65591ca Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <[email protected]> Signed-off-by: Jinchao Wang <[email protected]> Reviewed-by: Alan Stern <[email protected]> Link: https://patch.msgid.link/5db8bba5b3499a86cd2e776f9918126b68b2508b.1784198306.git.wangjinchao600@gmail.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fan Wu <[email protected]> Date: Thu Jul 9 15:07:17 2026 +0000 usb: gadget: f_midi: cancel pending IN work before freeing the midi object commit 5650c18d93a1db7e27cb5a40b394747eb4686d5b upstream. The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool. Fixes: 8653d71ce3763 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable <[email protected]> Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sonali Pradhan <[email protected]> Date: Fri Jul 3 08:37:24 2026 +0000 usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() commit 1febec7e47cdcd01f43fb0211094e3010474666e upstream. When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary. Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call") Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") Cc: stable <[email protected]> Assisted-by: Jetski:Gemini-2.5-Pro Signed-off-by: Sonali Pradhan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 2 16:15:33 2026 +0200 USB: gadget: fsl-udc: fix device name leak on probe failure commit 6b874d00c466e73c6448a89856407fe46b2f50e4 upstream. The gadget device name is set by UDC core when registering the gadget and must not be set before to avoid leaking the name in intermediate error paths (e.g. on dma pool creation failure). Fixes: eab35c4e6d95 ("usb: gadget: fsl_udc_core: let udc-core manage gadget->dev") Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Melbin K Mathew <[email protected]> Date: Thu Jul 9 21:56:22 2026 +0100 usb: gadget: printer: fix infinite loop in printer_read() commit c2e819be6a5c7f34344926b4bd7e3dfca58cf48a upstream. printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress. Fixes: b185f01a9ab7 ("usb: gadget: printer: factor out f_printer") Cc: stable <[email protected]> Reviewed-by: Peter Chen <[email protected]> Signed-off-by: Melbin K Mathew <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Thu Jul 2 16:15:34 2026 +0200 USB: gadget: snps-udc: fix device name leak on probe failure commit 29a142d3e8b35ebc9e0bcc78f4bc26c9b6a9ac0b upstream. The gadget device name is set by UDC core when registering the gadget and must not be set before to avoid leaking the name in intermediate error paths (e.g. when detecting an older chip revision). Fixes: 12ad0fcaf2fb ("usb: gadget: amd5536udc: let udc-core manage gadget->dev") Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fan Wu <[email protected]> Date: Thu Jul 9 02:09:04 2026 +0000 usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown commit 0583f2fbf8f86ae3a0ce054f96783dd83e65d9bb upstream. The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Cc: stable <[email protected]> Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Muhammad Bilal <[email protected]> Date: Tue Jun 30 00:50:04 2026 +0500 usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer commit b70dc75e85ba968b7b76eebfe5d63000080b875b upstream. uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: req->length = min_t(unsigned int, uvc->event_length, data->length); ... memcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well. Fixes: a5eaaa1f33e7 ("usb: gadget: uvc: use capped length value") Cc: stable <[email protected]> Signed-off-by: Muhammad Bilal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tim Pambor <[email protected]> Date: Sat Jul 11 17:36:30 2026 +0000 USB: serial: ftdi_sio: add support for E+H FXA291 commit fad0fd120e29041b3e6cdf41bb12e3184fb524a2 upstream. The Commubox FXA291 by Endress+Hauser AG is a USB serial converter based on FT232B which is used to communicate with field devices. It enumerates using the FTDI vendor ID and a custom PID. usb 1-9: New USB device found, idVendor=0403, idProduct=e510, bcdDevice= 4.00 usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-9: Product: FXA291 usb 1-9: Manufacturer: Endress+Hauser usb 1-9: SerialNumber: 00000000 ftdi_sio 1-9:1.0: FTDI USB Serial Device converter detected usb 1-9: Detected FT232B usb 1-9: FTDI USB Serial Device converter now attached to ttyUSB0 Signed-off-by: Tim Pambor <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sunho Park <[email protected]> Date: Tue Jul 14 19:42:30 2026 +0900 USB: serial: io_edgeport: cap received transmit credits commit faaddd811c5099f11a5f52e68a6b31a5898cda4f upstream. The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Assisted-by: Codex:GPT-5 Signed-off-by: Sunho Park <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Jul 8 16:31:35 2026 +0200 USB: serial: keyspan_pda: fix data loss on receive throttling commit 42a97c0480f96a2977e6d51ce512adc780f1ef5d upstream. Killing the interrupt-in urb when the line disciple requests throttling may lead to data loss if an ongoing transfer is cancelled. Instead set a flag to prevent the completion handler from resubmitting the urb until the port is unthrottled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chukun Pan <[email protected]> Date: Wed Jul 8 18:00:01 2026 +0800 USB: serial: option: add TDTECH MT5710-CN commit 55645e4f3c6022ffb160ad3617d2b624eaa38501 upstream. Add support for the TDTECH MT5710-CN (5G redcap) module based on the Huawei HiSilicon Balong chip. T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=3466 ProdID=3301 Rev=ff.ff S: Manufacturer=TD Tech Ltd. S: Product=TDTECH MT571X S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr= 0mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1c Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Interface: ECM / NCM + DIAG + AT + SERIAL + GPS Signed-off-by: Chukun Pan <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huang Wei <[email protected]> Date: Thu Jul 16 11:33:41 2026 +0800 USB: storage: add NO_ATA_1X quirk for Longmai USB Key commit 3b4ca2e01c1dd8c00b675b794732945f460a471b upstream. The Longmai Technologies USB Key (0x04b4:0xb708) advertises itself as a SCSI/Bulk-only mass storage device but does not correctly handle ATA pass-through commands. When such a command (ATA_12 or ATA_16) is sent to the device it fails to respond and the transfer eventually times out, leaving the device unusable. Add an unusual_devs entry for this device that sets the US_FL_NO_ATA_1X flag, so usb-storage short-circuits ATA pass-through commands and returns INVALID COMMAND OPERATION CODE (0x20 0x05 0x24 0x00) instead of forwarding them to the device. Information about the device in /sys/kernel/debug/usb/devices: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=06 Prot=50 MxPS=64 #Cfgs= 1 P: Vendor=04b4 ProdID=b708 Rev= 1.00 S: Manufacturer=Longmai Technologies S: Product=USB Key C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Reported-by: Ai Chao <[email protected]> Cc: stable <[email protected]> Signed-off-by: Huang Wei <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xincheng Zhang <[email protected]> Date: Tue Jul 28 13:41:00 2026 +0800 usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits commit 1fc50f1ecde39feb4fccdaf4bc71aa6c0eb25c49 upstream. The VIA VL805/806 xHCI controller advertises AC64, but fails to handle DMA addresses at or above 0x1000000000. On systems with large amounts of RAM, this can cause USB device failures when the controller is given DMA addresses beyond its usable address width. Do not use XHCI_NO_64BIT_SUPPORT for this controller. That quirk clears the cached AC64 capability and limits DMA to 32 bits, causing unnecessary bouncing for addresses between 4GiB and 64GiB and hiding the controller's real AC64 capability from code that may need to distinguish register access width from usable DMA address width. Track the usable DMA address width separately from the AC64 capability. Initialize the generic xhci->dma_mask_bits field to 64 and let PCI quirks reduce it for controllers with narrower DMA support. Set VIA VL805/806 to 36 bits so the DMA API only hands it addresses in the range it can handle while keeping HCCPARAMS1.AC64 visible. Cc: [email protected] Signed-off-by: Xincheng Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Wang <[email protected]> Date: Wed Jul 22 14:00:52 2026 -0400 VDUSE: avoid leaking information to userspace [ Upstream commit 9c1523803445ee0348f62b77793266dd981596e0 ] The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace. Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Cc: [email protected] Signed-off-by: Jason Wang <[email protected]> Reviewed-by: Xie Yongji <[email protected]> Reviewed-by: Eugenio Pérez <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-ID: <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eugenio Pérez <[email protected]> Date: Wed Jul 22 14:00:50 2026 -0400 vduse: remove unused vaddr parameter of vduse_domain_free_coherent [ Upstream commit 766e1749c0ef6a09651be9b8a8283d508c322b58 ] We will modify the function in next patches so let's clean it first. Signed-off-by: Eugenio Pérez <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-Id: <[email protected]> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eugenio Pérez <[email protected]> Date: Wed Jul 22 14:00:51 2026 -0400 vduse: take out allocations from vduse_dev_alloc_coherent [ Upstream commit 489d76520612abf9a4ede4344349105406c91a73 ] The function vduse_dev_alloc_coherent will be called under rwlock in next patches. Make it out of the lock to avoid increasing its fail rate. Acked-by: Jason Wang <[email protected]> Signed-off-by: Eugenio Pérez <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Message-Id: <[email protected]> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sheng Zhao <[email protected]> Date: Wed Jul 22 14:00:49 2026 -0400 vduse: Use fixed 4KB bounce pages for non-4KB page size [ Upstream commit 3fc3068e7247c94dec08e93fea422a1bb649bfe5 ] The allocation granularity of bounce pages is PAGE_SIZE. This may cause even small IO requests to occupy an entire bounce page exclusively. The kind of memory waste will be more significant when PAGE_SIZE is larger than 4KB (e.g. arm64 with 64KB pages). So, optimize it by using fixed 4KB bounce maps and iova allocation granularity. A single IO request occupies at least a 4KB bounce page instead of the entire memory page of PAGE_SIZE. Signed-off-by: Sheng Zhao <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: NeilBrown <[email protected]> Date: Tue Jul 21 20:51:12 2026 -0400 VFS/audit: introduce kern_path_parent() for audit [ Upstream commit 76a53de6f7ff0641570364234fb4489f4d4fc8e9 ] audit_alloc_mark() and audit_get_nd() both need to perform a path lookup getting the parent dentry (which must exist) and the final target (following a LAST_NORM name) which sometimes doesn't need to exist. They don't need the parent to be locked, but use kern_path_locked() or kern_path_locked_negative() anyway. This is somewhat misleading to the casual reader. This patch introduces a more targeted function, kern_path_parent(), which returns not holding locks. On success the "path" will be set to the parent, which must be found, and the return value is the dentry of the target, which might be negative. This will clear the way to rename kern_path_locked() which is otherwise only used to prepare for removing something. It also allows us to remove kern_path_locked_negative(), which is transformed into the new kern_path_parent(). Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Stable-dep-of: 81905b5acbe7 ("audit: fix recursive locking deadlock in audit_dupe_exe()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harshaka Narayana <[email protected]> Date: Mon Jul 13 07:09:15 2026 -0700 vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets [ Upstream commit 34a71f5361fc3adb5b7138da78750b0d535a8252 ] vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively. Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)") Signed-off-by: Harshaka Narayana <[email protected]> Reviewed-by: Ronak Doshi <[email protected]> Reviewed-by: Sankararaman Jayaraman <[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: James Raphael Tiovalen <[email protected]> Date: Tue Jul 21 00:04:24 2026 +0800 vxlan: mdb: Fix source list corruption on a failed replace commit dcd9b465965422b9654f6026e8a2fa8984f74c3c upstream. When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails. Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Cc: [email protected] Signed-off-by: James Raphael Tiovalen <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Antoine Tenart <[email protected]> Reviewed-by: Nikolay Aleksandrov <[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: Doruk Tan Ozturk <[email protected]> Date: Thu Jul 16 22:34:59 2026 +0200 vxlan: require CAP_NET_ADMIN in the device netns for changelink commit 3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e upstream. A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 8bcdc4f3a20b ("vxlan: add changelink support") Cc: [email protected] Signed-off-by: Doruk Tan Ozturk <[email protected]> Reviewed-by: Fernando Fernandez Mancera <[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: Ruoyu Wang <[email protected]> Date: Wed Jul 8 22:34:15 2026 +0800 wan: wanxl: Only reset hardware after BAR mapping [ Upstream commit 91957b89da995607cb654b1f9a3c126ddbaee10f ] wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ruoyu Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tzung-Bi Shih <[email protected]> Date: Tue Jul 7 10:18:03 2026 +0000 watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() [ Upstream commit 7362ba0f9c96ac3ad6a2ca3995bd9fc9a28a8661 ] When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered. Fixes: da0d12ff2b82 ("watchdog: pretimeout: add panic pretimeout governor") Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huihui Huang <[email protected]> Date: Wed Jul 15 22:08:10 2026 +0800 wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() commit 61a799ffd1e5a4fd3702d547828b7ff3d161468e upstream. at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: len -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off. Fixes: 1264b951463a ("at76c50x-usb: add driver") Cc: [email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Huihui Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gaole Zhang <[email protected]> Date: Tue Jun 9 17:06:09 2026 +0800 wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin [ Upstream commit e8d85672dd7e2523f774caafba8f858384e18df7 ] In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 6fe62a8cec51c ("wifi: ath11k: Add cold boot calibration support on WCN6750") Signed-off-by: Gaole Zhang <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Reviewed-by: Rameshkumar Sundaram <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Morgun <[email protected]> Date: Sat May 30 11:42:52 2026 +0000 wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() [ Upstream commit 7f11e70629650ff6ea140984e5ce188b775b2683 ] When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Dmitry Morgun <[email protected]> Reviewed-by: Rameshkumar Sundaram <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Tue Jun 23 16:16:48 2026 +0200 wifi: ath11k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET [ Upstream commit 0fe8010fc5b147607fc19ba010ba469afc95f35f ] ath11k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Fixes: f3c603d412b3 ("ath11k: reset MHI during power down and power up") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Reviewed-by: Raj Kumar Bhagat <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Tue Jun 23 16:16:49 2026 +0200 wifi: ath12k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET [ Upstream commit 55f3aa06951cac78b0206bde961c8cf11929a27a ] ath12k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reported-by: Alex Williamson <[email protected]> Closes: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Reviewed-by: Raj Kumar Bhagat <[email protected]> Tested-by: Raj Kumar Bhagat <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Madani <[email protected]> Date: Thu Jul 2 00:50:20 2026 +0000 wifi: ath6kl: fix OOB access from firmware ADDBA window size commit 44126b6994eeb28f2103b638e698f40a1244f327 upstream. aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: [email protected] Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Signed-off-by: Tristan Madani <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tristan Madani <[email protected]> Date: Tue Apr 21 13:50:08 2026 +0000 wifi: ath6kl: fix OOB read from firmware IE lengths in connect event [ Upstream commit 6b47b29730de3232b919d8362749f6814c5f2a33 ] The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Tristan Madani <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Madani <[email protected]> Date: Thu Jun 25 23:29:07 2026 +0000 wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler [ Upstream commit 3a21c89215cc18f1a97c5e5bfd1da6d4f3d44495 ] The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Tristan Madani <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cheng Yongkang <[email protected]> Date: Fri Jun 5 08:32:10 2026 -0700 wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request [ Upstream commit dad9f96945d77ecd4708f730c06ef54dcd8cc057 ] ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n", hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened. Fixes: e904cf6fe230 ("ath9k_htc: introduce support for different fw versions") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=50122cbc2874b1eb25b0 Signed-off-by: Cheng Yongkang <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shelley Yang <[email protected]> Date: Mon May 25 16:38:59 2026 +0800 wifi: brcmfmac: fix 802.1X-SHA256 call trace warning [ Upstream commit 7cb34f6c4fe8a68af621d870abe63bfca2275dd6 ] Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204] <TASK> [ 4481.831205] nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233] genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237] genl_rcv_msg+0x104/0x240 [ 4481.831239] ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257] ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259] netlink_rcv_skb+0x4e/0x100 [ 4481.831261] genl_rcv+0x24/0x40 [ 4481.831262] netlink_unicast+0x236/0x380 [ 4481.831264] netlink_sendmsg+0x250/0x4b0 [ 4481.831266] sock_sendmsg+0x5c/0x70 [ 4481.831269] ____sys_sendmsg+0x236/0x2b0 [ 4481.831271] ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272] ___sys_sendmsg+0x86/0xd0 [ 4481.831274] ? avc_has_perm+0x8c/0x1a0 [ 4481.831276] ? preempt_count_add+0x6a/0xa0 [ 4481.831279] ? sock_has_perm+0x82/0xa0 [ 4481.831280] __sys_sendmsg+0x57/0xa0 [ 4481.831282] do_syscall_64+0x38/0x90 [ 4481.831284] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4 Fixes: 2526ff21aa77 ("brcmfmac: support 4-way handshake offloading for 802.1X") Signed-off-by: Shelley Yang <[email protected]> Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Runyu Xiao <[email protected]> Date: Fri Jun 19 14:44:01 2026 +0800 wifi: brcmfmac: initialize SDIO data work before cleanup [ Upstream commit 2a665946e0407a05a3f81bd56a08553c446498e0 ] brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack. Fixes: 9982464379e8 ("brcmfmac: make sdio suspend wait for threads to freeze") Signed-off-by: Runyu Xiao <[email protected]> Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fan Wu <[email protected]> Date: Sat Jul 18 02:43:52 2026 +0000 wifi: brcmfmac: make release_scratchbuffers idempotent commit 538c51e9d124cf656f2dd0c0394a8545efc7102d upstream. brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: [email protected] Signed-off-by: Fan Wu <[email protected]> Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tristan Madani <[email protected]> Date: Tue Apr 21 13:49:26 2026 +0000 wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read [ Upstream commit 4cde55b2feff9504d1f993ab80e84e7ccb62791c ] When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani <[email protected]> Acked-by: Christian Lamparter <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Madani <[email protected]> Date: Tue Apr 21 13:49:28 2026 +0000 wifi: carl9170: fix buffer overflow in rx_stream failover path [ Upstream commit a1a21995c2e1cc2ca6b2226cfe4f5f018370182a ] The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani <[email protected]> Acked-by: Christian Lamparter <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/[email protected] [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Madani <[email protected]> Date: Tue Apr 21 13:49:27 2026 +0000 wifi: carl9170: fix OOB read from off-by-two in TX status handler [ Upstream commit a3f42f1049ad80c65560d2b078ad426c3134f78d ] The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani <[email protected]> Acked-by: Christian Lamparter <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HE WEI (ギカク) <[email protected]> Date: Tue Jul 7 18:48:28 2026 +0900 wifi: cfg80211: bound element ID read when checking non-inheritance [ Upstream commit cb8afea4655ff004fa7feee825d5c79783525383 ] cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN. Fixes: f7dacfb11475 ("cfg80211: support non-inheritance element") Signed-off-by: HE WEI (ギカク) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cen Zhang <[email protected]> Date: Sat Jun 20 00:25:42 2026 +0800 wifi: cfg80211: cancel sched scan results work on unregister [ Upstream commit edf0730be33696a1bd142792830d392129e495cc ] cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Fixes: 807f8a8c3004 ("cfg80211/nl80211: add support for scheduled scans") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhao Li <[email protected]> Date: Fri Jun 12 21:37:11 2026 +0800 wifi: cfg80211: reject unsupported PMSR FTM location requests [ Upstream commit 69ef6a7ec277f16d216be8da2b3cbe872786c999 ] PMSR FTM location request flags are syntactically valid, but they must be rejected when the device capability does not advertise support for them. Return an error immediately after rejecting unsupported LCI or civic location request bits so the request cannot reach the driver. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhao Li <[email protected]> Date: Fri Jun 12 21:37:04 2026 +0800 wifi: cfg80211: validate PMSR FTM preamble range [ Upstream commit 36230936468f0ba4930e94aef496fc229d4bb951 ] PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <[email protected]> Link: https://patch.msgid.link/[email protected] [drop unnecessary check] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhao Li <[email protected]> Date: Fri Jun 12 21:36:57 2026 +0800 wifi: cfg80211: validate PMSR measurement type data [ Upstream commit 41aa973eb05922848dded26875c55ef982ac1c49 ] PMSR request parsing accepts missing or duplicated measurement type entries in NL80211_PMSR_REQ_ATTR_DATA. Track whether one measurement type was already provided, reject a second one immediately, and return an error if the request data block contains no measurement type at all. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Sat Jun 20 12:22:39 2026 +0530 wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() [ Upstream commit 0d388f62031dbabcba0f44bb91b59f10e88cac17 ] The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline. Fixes: 2c86c275015c ("Add ipw2100 wireless driver.") Signed-off-by: Abdun Nihaal <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shahar Tzarfati <[email protected]> Date: Wed Jul 15 21:57:08 2026 +0300 wifi: iwlwifi: mvm: fix read in wake packet notification handler [ Upstream commit 9d7657aae8c1579584c67b0b66114a6a98db8b2f ] In iwl_mvm_wowlan_store_wake_pkt(), packet_len was initialized from notif->wake_packet_length before the explicit check that len >= sizeof(*notif). Move the assignment of packet_len to after the size check so that notif->wake_packet_length is only accessed once the payload length has been validated. Fixes: 219ed58feda9 ("wifi: iwlwifi: mvm: Add support for wowlan wake packet notification") Signed-off-by: Shahar Tzarfati <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20260715215523.99d5cf85a528.Ic4aa736011d4fe88e0cd19723d1d48bb24642198@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Pagadala Yesu Anjaneyulu <[email protected]> Date: Wed Jul 15 21:57:04 2026 +0300 wifi: iwlwifi: mvm: validate SAR GEO response payload size [ Upstream commit 408d7da38272ce48e2db79b8a9895999f94d7655 ] The SAR GEO command response is cast to iwl_geo_tx_power_profiles_resp without verifying the payload length. A malformed or unexpected firmware response can lead to reading an invalid structure layout. Add an explicit size check before accessing the response data and return -EIO when the payload size is wrong. Fixes: f604324eefec ("iwlwifi: remove iwl_validate_sar_geo_profile() export") Signed-off-by: Pagadala Yesu Anjaneyulu <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20260715215523.7e749b7d374a.I4ef54548bff6c6e7c7a57bee771ac12508aad677@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Dawei Feng <[email protected]> Date: Wed Jun 24 16:53:43 2026 +0800 wifi: libertas: fix memory leak in helper_firmware_cb() [ Upstream commit 63c2391deefb31e1b801b7f32bd502ca4808639b ] helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed. Fixes: 1dfba3060fe7 ("libertas: move firmware lifetime handling to firmware.c") Signed-off-by: Dawei Feng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maoyi Xie <[email protected]> Date: Mon Jul 27 20:57:42 2026 -0400 wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() [ Upstream commit aa6dcd5c8dd9ba1d7d0f60093bcda41c0d6d438d ] lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 ("wifi: libertas: fix use-after-free in lbs_free_adapter()") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed. Fixes: 06b16ae53192 ("libertas_tf: main.c, data paths and mac80211 handlers") Cc: [email protected] Signed-off-by: Maoyi Xie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cen Zhang <[email protected]> Date: Mon Jul 6 22:08:41 2026 +0800 wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock [ Upstream commit f3858d5b1432098c1936e03d6e03dd0e33facf60 ] ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip Fixes: 397a7a24ef8c ("mac80211: free ps->bc_buf skbs on vlan device stop") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrew Pope <[email protected]> Date: Fri Jul 17 11:17:51 2026 +1000 wifi: mac80211: recalculate TIM when a station enters power save [ Upstream commit a007a384c9eb17610f53a53e2f59944c31f1565a ] When an AP buffers frames for a station on its per-station TXQs and the station subsequently enters power save, sta_ps_start() records the buffered TIDs in txq_buffered_tids but does not update the TIM. The station's TIM bit is only ever set when a further frame is buffered while the station is already asleep (ieee80211_tx_h_unicast_ps_buf() -> sta_info_recalc_tim()). If no further downlink frame arrives for that station the beacon TIM never advertises the buffered traffic. A station relying on the TIM then remains in doze indefinitely on top of a non-empty queue. Its TXQs were removed from the scheduler's active list at PS entry, nothing pages it, and the flow deadlocks until an unrelated event wakes the station. Recalculate the TIM at the end of sta_ps_start(), so traffic already buffered at PS entry is advertised immediately. sta_info_recalc_tim() already consults txq_buffered_tids, which is updated above, and is safe in this context (it is already called from equivalent paths such as the tx handlers and ieee80211_handle_filtered_frame()). Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Andrew Pope <[email protected]> Link: https://patch.msgid.link/[email protected] [add wifi: subject prefix] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei <[email protected]> Date: Sat Jul 11 14:03:02 2026 -0700 wifi: mac80211: tear down new links on vif update error path [ Upstream commit 952c02b33f56207a160421bcd61e7ac53c9c59ae ] When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f ("wifi: mac80211: avoid weird state in error path") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception Fixes: 170cd6a66d9a ("wifi: mac80211: add netdev per-link debugfs data and driver hook") Reported-by: Weiming Shi <[email protected]> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryam Vargas <[email protected]> Date: Sat Jun 20 21:45:18 2026 -0500 wifi: mac80211_hwsim: clamp virtio RX length before skb_put [ Upstream commit 10a2b430f8f06ae14b9590b6f6faa6b588ef0654 ] hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem. Fixes: 5d44fe7c9808 ("mac80211_hwsim: add frame transmission support over virtio") Signed-off-by: Bryam Vargas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Sun Jun 21 15:24:59 2026 +0200 wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() [ Upstream commit 2c1fb2335f5e3afb34f91bc07ecb63517c328090 ] mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-1-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Devin Wittmayer <[email protected]> Date: Sat Jun 27 12:13:36 2026 -0700 wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses commit 39afc46c0243d10b7795e6e6cf4ae91f41732120 upstream. PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices"). Fixes: eb99cc95c3b6 ("mt76: mt7615: introduce mt7663u support") Cc: [email protected] Signed-off-by: Devin Wittmayer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ruoyu Wang <[email protected]> Date: Sat Jun 20 23:53:32 2026 +0800 wifi: mt76: mt7915: guard HE capability lookups [ Upstream commit 8e9db062654a388d0fa587acbeeae68dd33eba41 ] mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available. Fixes: e6d557a78b60 ("mt76: mt7915: rely on mt76_connac_get_phy utilities") Signed-off-by: Ruoyu Wang <[email protected]> Acked-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Devin Wittmayer <[email protected]> Date: Sat Jun 27 12:13:34 2026 -0700 wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses commit da4082e91acabc1498611ed8ccc53f0610baefc6 upstream. PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices"). Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Cc: [email protected] Signed-off-by: Devin Wittmayer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Sun Jun 21 15:25:01 2026 +0200 wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() [ Upstream commit e858cf6bf99880343348ff1e8c942aaff1d9d592 ] mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-3-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Sun Jun 21 15:25:02 2026 +0200 wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() [ Upstream commit 2fffc472bec490c8357defcee9c075ca74467352 ] mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: ba01944adee9f ("wifi: mt76: mt7996: add EHT beamforming support") Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-4-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: HE WEI (ギカク) <[email protected]> Date: Wed Jul 15 22:57:11 2026 +0900 wifi: mwifiex: bound uAP association event IEs to the event buffer [ Upstream commit f0858bfc7d3cab411a447b88e3ef970e575032c9 ] mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: sinfo->assoc_req_ies = &event->data[len]; len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets"). Fixes: e568634ae7ac ("mwifiex: add AP event handling framework") Signed-off-by: HE WEI (ギカク) <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Doruk Tan Ozturk <[email protected]> Date: Thu Jul 16 12:30:42 2026 +0200 wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper commit c3d68e294cbb6a4090bb219d3dcaca85a011809b upstream. mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: if (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && bss_desc->bcn_ht_cap && ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 396939f94084 ("mwifiex: add HT operation IE in TDLS setup confirm") Cc: [email protected] Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhao Li <[email protected]> Date: Wed Jun 10 19:22:09 2026 +0800 wifi: nl80211: free RNR data on MBSSID mismatch [ Upstream commit 07a95ec2b54774201fdf4ef7ffb0ca2ab19ed29c ] nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error. Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP") Signed-off-by: Zhao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhao Li <[email protected]> Date: Fri Jun 12 21:18:55 2026 +0800 wifi: nl80211: validate nested MBSSID IE blobs [ Upstream commit 7f4b01812323443b55e4c65381c9dc851ff009e3 ] Validate each nested NL80211_ATTR_MBSSID_ELEMS entry as a well-formed information-element stream before storing it for beacon construction. RNR parsing already validates each nested blob with validate_ie_attr() before storing it. Apply the same syntactic IE validation to MBSSID entries before counting and copying their data and length pointers. Fixes: dc1e3cb8da8b ("nl80211: MBSSID and EMA support in AP mode") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei <[email protected]> Date: Sat Jun 27 17:05:10 2026 -0700 wifi: p54: validate RX frame length in p54_rx_eeprom_readback() [ Upstream commit ebd6d37fa94bee929e0b4c9ca19fdf9b1dcf6cea ] p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 ("wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: <IRQ> ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... </IRQ> The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying. Fixes: 7cb770729ba8 ("p54: move eeprom code into common library") Reported-by: Weiming Shi <[email protected]> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <[email protected]> Acked-by: Christian Lamparter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huihui Huang <[email protected]> Date: Tue Jul 14 17:17:58 2026 +0800 wifi: wilc1000: validate assoc response length before subtracting header commit 4c4c97b60a5e978121d9ee8cb0ab3916e5d6a8de upstream. wilc_parse_assoc_resp_info() computes the trailing IE length as ies_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a "conn_info->status == WLAN_STATUS_SUCCESS" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: [email protected] Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Huihui Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marco Crivellari <[email protected]> Date: Mon Jul 27 19:37:49 2026 -0400 workqueue: Add system_percpu_wq and system_dfl_wq [ Upstream commit 128ea9f6ccfb6960293ae4212f4f97165e42222d ] Currently, if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_wq is a per-CPU worqueue, yet nothing in its name tells about that CPU affinity constraint, which is very often not required by users. Make it clear by adding a system_percpu_wq. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. Suggested-by: Tejun Heo <[email protected]> Signed-off-by: Marco Crivellari <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Stable-dep-of: 50fd6dd755c6 ("tracing/user_events: Fix use-after-free in user_event_mm_dup()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tejun Heo <[email protected]> Date: Mon Jul 27 19:37:48 2026 -0400 workqueue: Factor out init_cpu_worker_pool() [ Upstream commit 2fcdb1b44491e08f5334a92c50e8f362e0d46f91 ] Factor out init_cpu_worker_pool() from workqueue_init_early(). This is pure reorganization in preparation of BH workqueue support. Signed-off-by: Tejun Heo <[email protected]> Tested-by: Allen Pais <[email protected]> Stable-dep-of: 50fd6dd755c6 ("tracing/user_events: Fix use-after-free in user_event_mm_dup()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Wed Jul 22 17:09:43 2026 -0700 x86/boot/compressed: Disable jump tables commit 4a9ec5ec9555ad62dc5b81a37ac946025c2ea002 upstream. After a recent upstream LLVM change to start generating jump and lookup tables in switch statements in more instances [1], linking the compressed x86 boot image when CONFIG_KERNEL_ZSTD is enabled fails with: ld.lld: error: Unexpected run-time relocations (.rela) detected! Dumping the relocations in misc.o, which is the only file influenced by CONFIG_KERNEL_ZSTD in the decompressor, shows dynamic relocations to some string constants, which correspond to the string literals in the switch statement in handle_zstd_error(): Relocation section '.rela.data.rel.ro' at offset 0x277b0 contains 31 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 73a 0000000000000008 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000010 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000018 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e ... This optimization is problematic for the decompressor environment, as it is built as -fPIE without any explicit absolute references (as described at the top of misc.c) while not applying any dynamic relocations, hence the linker assertion. To opt out of this optimization, which is of little value in this special early boot code, and to mirror the other x86 startup code in arch/x86/boot/startup, disable jump tables in the decompressor. Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: https://github.com/llvm/llvm-project/commit/fa02a6ed66b1700c996b49c96c6bc0eb014c9518 [1] Link: https://patch.msgid.link/20260722-x86-boot-compressed-disable-jt-clang-v2-1-7373d38482fb@kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2165 Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Thu Jul 2 01:05:16 2026 +0000 xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() [ Upstream commit 136992de9bb91871084ae52d172610541c76e4d2 ] On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for <dev> to become free"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ... Fixes: 84c4a9dfbf43 ("xfrm6: release dev before returning error") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Mei (Microsoft) <[email protected]> Date: Fri Jul 3 05:19:32 2026 +0000 xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert [ Upstream commit f38f8cce2f7e79775b3db7e8a5eacda04ac908e4 ] xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt Fixes: 24969facd704 ("xfrm: policy: store inexact policies in an rhashtable") Reported-by: [email protected] Signed-off-by: Xiang Mei (Microsoft) <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Tue May 26 10:14:04 2026 -0400 xprtrdma: Clear receive-side ownership pointers on release [ Upstream commit 2ae8e7afbc63bf84243367f89eb43571f0345a74 ] Three small ownership-state cleanups land the transport in a state that lets future reviewers reason about each pointer locally rather than tracing the whole reply path: rpcrdma_rep_put() clears rep->rr_rqst before the rep enters rb_free_reps so that no rep on the free list still carries a stale rqst pointer. rpcrdma_reply_handler() and rpcrdma_unpin_rqst() are the only sites that set rr_rqst; rpcrdma_reply_handler() hands the rep through rpcrdma_rep_put(), and rpcrdma_unpin_rqst() NULLs rr_rqst directly because its error path abandons the rep for teardown cleanup rather than returning it to rb_free_reps. rpcrdma_reply_put() NULLs req->rl_reply before calling rpcrdma_rep_put(). The previous order placed the rep on rb_free_reps while req->rl_reply still pointed at it; the window was harmless because xprt_rdma_free_slot() holds the req exclusively across the pair, but closing it makes the invariant 'rep on rb_free_reps implies no req references it' strictly checkable. rpcrdma_sendctx_unmap() and rpcrdma_sendctx_cancel() clear req->rl_sendctx after dropping the sendctx pointer in the sendctx ring. Without this, req->rl_sendctx survives across Send completion and points at a sendctx that may already have been reassigned by rpcrdma_sendctx_get_locked() to a different req. No caller dereferences the stale pointer today -- rpcrdma_prepare_send_sges() overwrites it before the next Send -- but a NULL is a more honest representation of 'the Send is no longer outstanding' and lets the assertion patch that follows trip on any future regression. Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>