Author: Amir Mohammad Jahangirzad <[email protected]> Date: Tue Sep 23 05:01:13 2025 +0330 ACPI: debug: fix signedness issues in read/write helpers commit 496f9372eae14775e0524e83e952814691fe850a upstream. In the ACPI debugger interface, the helper functions for read and write operations use "int" as the length parameter data type. When a large "size_t count" is passed from the file operations, this cast to "int" results in truncation and a negative value due to signed integer representation. Logically, this negative number propagates to the min() calculation, where it is selected over the positive buffer space value, leading to unexpected behavior. Subsequently, when this negative value is used in copy_to_user() or copy_from_user(), it is interpreted as a large positive value due to the unsigned nature of the size parameter in these functions, causing the copy operations to attempt handling sizes far beyond the intended buffer limits. Address the issue by: - Changing the length parameters in acpi_aml_read_user() and acpi_aml_write_user() from "int" to "size_t", aligning with the expected unsigned size semantics. - Updating return types and local variables in acpi_aml_read() and acpi_aml_write() to "ssize_t" for consistency with kernel file operation conventions. - Using "size_t" for the "n" variable to ensure calculations remain unsigned. - Using min_t() for circ_count_to_end() and circ_space_to_end() to ensure type-safe comparisons and prevent integer overflow. Signed-off-by: Amir Mohammad Jahangirzad <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog tweaks, local variable definitions ordering adjustments ] Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") Cc: 4.5+ <[email protected]> # 4.5+ Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huisong Li <[email protected]> Date: Mon Jul 28 15:06:11 2025 +0800 ACPI: processor: idle: Fix memory leak when register cpuidle device failed [ Upstream commit 11b3de1c03fa9f3b5d17e6d48050bc98b3704420 ] The cpuidle device's memory is leaked when cpuidle device registration fails in acpi_processor_power_init(). Free it as appropriate. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure") Signed-off-by: Huisong Li <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changed the order of the new statements, added empty line after if () ] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Tang <[email protected]> Date: Thu Aug 28 01:38:14 2025 -0400 ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT commit 4aac453deca0d9c61df18d968f8864c3ae7d3d8d upstream. Previously, after `rmmod acpi_tad`, `modprobe acpi_tad` would fail with this dmesg: sysfs: cannot create duplicate filename '/devices/platform/ACPI000E:00/time' Call Trace: <TASK> dump_stack_lvl+0x6c/0x90 dump_stack+0x10/0x20 sysfs_warn_dup+0x8b/0xa0 sysfs_add_file_mode_ns+0x122/0x130 internal_create_group+0x1dd/0x4c0 sysfs_create_group+0x13/0x20 acpi_tad_probe+0x147/0x1f0 [acpi_tad] platform_probe+0x42/0xb0 </TASK> acpi-tad ACPI000E:00: probe with driver acpi-tad failed with error -17 Fixes: 3230b2b3c1ab ("ACPI: TAD: Add low-level support for real time capability") Signed-off-by: Daniel Tang <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Link: https://patch.msgid.link/2881298.hMirdbgypa@daniel-desktop3 Cc: 5.2+ <[email protected]> # 5.2+ Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Mon Oct 13 20:05:52 2025 -0700 ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings [ Upstream commit d41f68dff783d181a8fd462e612bda0fbab7f735 ] Fix spelling of CIP_NO_HEADER to prevent a kernel-doc warning. Warning: amdtp-stream.h:57 Enum value 'CIP_NO_HEADER' not described in enum 'cip_flags' Warning: amdtp-stream.h:57 Excess enum value '%CIP_NO_HEADERS' description in 'cip_flags' Fixes: 3b196c394dd9f ("ALSA: firewire-lib: add no-header packet processing") Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Takashi Sakamoto <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Thu Aug 28 16:13:10 2025 +0800 ALSA: lx_core: use int type to store negative error codes [ Upstream commit 4ef353d546cda466fc39b7daca558d7bcec21c09 ] Change the 'ret' variable from u16 to int to store negative error codes or zero returned by lx_message_send_atomic(). Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface") Signed-off-by: Qianfeng Rong <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raju Rangoju <[email protected]> Date: Fri Oct 10 12:21:42 2025 +0530 amd-xgbe: Avoid spurious link down messages during interface toggle [ Upstream commit 2616222e423398bb374ffcb5d23dea4ba2c3e524 ] During interface toggle operations (ifdown/ifup), the driver currently resets the local helper variable 'phy_link' to -1. This causes the link state machine to incorrectly interpret the state as a link change event, resulting in spurious "Link is down" messages being logged when the interface is brought back up. Preserve the phy_link state across interface toggles to avoid treating the -1 sentinel value as a legitimate link state transition. Fixes: 88131a812b16 ("amd-xgbe: Perform phy connect/disconnect at dev open/stop") Signed-off-by: Raju Rangoju <[email protected]> Reviewed-by: Dawid Osuchowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huang Ying <[email protected]> Date: Wed Oct 15 10:37:12 2025 +0800 arm64, mm: avoid always making PTE dirty in pte_mkwrite() [ Upstream commit 143937ca51cc6ae2fccc61a1cb916abb24cd34f5 ] Current pte_mkwrite_novma() makes PTE dirty unconditionally. This may mark some pages that are never written dirty wrongly. For example, do_swap_page() may map the exclusive pages with writable and clean PTEs if the VMA is writable and the page fault is for read access. However, current pte_mkwrite_novma() implementation always dirties the PTE. This may cause unnecessary disk writing if the pages are never written before being reclaimed. So, change pte_mkwrite_novma() to clear the PTE_RDONLY bit only if the PTE_DIRTY bit is set to make it possible to make the PTE writable and clean. The current behavior was introduced in commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()"). Before that, pte_mkwrite() only sets the PTE_WRITE bit, while set_pte_at() only clears the PTE_RDONLY bit if both the PTE_WRITE and the PTE_DIRTY bits are set. To test the performance impact of the patch, on an arm64 server machine, run 16 redis-server processes on socket 1 and 16 memtier_benchmark processes on socket 0 with mostly get transactions (that is, redis-server will mostly read memory only). The memory footprint of redis-server is larger than the available memory, so swap out/in will be triggered. Test results show that the patch can avoid most swapping out because the pages are mostly clean. And the benchmark throughput improves ~23.9% in the test. Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") Signed-off-by: Huang Ying <[email protected]> Cc: Will Deacon <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Gavin Shan <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Yicong Yang <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Rutland <[email protected]> Date: Fri Sep 19 15:58:28 2025 +0100 arm64: cputype: Add Neoverse-V3AE definitions commit 3bbf004c4808e2c3241e5c1ad6cc102f38a03c39 upstream. Add cputype definitions for Neoverse-V3AE. These will be used for errata detection in subsequent patches. These values can be found in the Neoverse-V3AE TRM: https://developer.arm.com/documentation/SDEN-2615521/9-0/ ... in section A.6.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Ryan Roberts <[email protected]> Signed-off-by: Will Deacon <[email protected]> [ Ryan: Trivial backport ] Signed-off-by: Ryan Roberts <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Mon Sep 15 15:28:30 2025 +0200 arm64: dts: qcom: msm8916: Add missing MDSS reset commit 99b78773c2ae55dcc01025f94eae8ce9700ae985 upstream. On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader already initializes the display to show the boot splash screen. In this situation, MDSS is already configured and left running when starting Linux. To avoid side effects from the bootloader configuration, the MDSS reset can be specified in the device tree to start again with a clean hardware state. The reset for MDSS is currently missing in msm8916.dtsi, which causes errors when the MDSS driver tries to re-initialize the registers: dsi_err_worker: status=6 dsi_err_worker: status=6 dsi_err_worker: status=6 ... It turns out that we have always indirectly worked around this by building the MDSS driver as a module. Before v6.17, the power domain was temporarily turned off until the module was loaded, long enough to clear the register contents. In v6.17, power domains are not turned off during boot until sync_state() happens, so this is no longer working. Even before v6.17 this resulted in broken behavior, but notably only when the MDSS driver was built-in instead of a module. Cc: [email protected] Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Stephan Gerhold <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mark Rutland <[email protected]> Date: Fri Sep 19 15:58:29 2025 +0100 arm64: errata: Apply workarounds for Neoverse-V3AE commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream. Neoverse-V3AE is also affected by erratum #3312417, as described in its Software Developer Errata Notice (SDEN) document: Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417 https://developer.arm.com/documentation/SDEN-2615521/9-0/ Enable the workaround for Neoverse-V3AE, and document this. Signed-off-by: Mark Rutland <[email protected]> Cc: James Morse <[email protected]> Cc: Will Deacon <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Ryan Roberts <[email protected]> Signed-off-by: Will Deacon <[email protected]> [ Ryan: Trivial backport ] Signed-off-by: Ryan Roberts <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Sep 2 19:18:19 2025 +0200 ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping [ Upstream commit b20eb0e8de383116f1e1470d74da2a3c83c4e345 ] When an invalid value is passed via quirk option, currently bytcht_es8316 driver just ignores and leaves as is, which may lead to unepxected results like OOB access. This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 249d2fc9e55c ("ASoC: Intel: bytcht_es8316: Set card long_name based on quirks") Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Sep 2 19:18:20 2025 +0200 ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping [ Upstream commit fba404e4b4af4f4f747bb0e41e9fff7d03c7bcc0 ] When an invalid value is passed via quirk option, currently bytcr_rt5640 driver only shows an error message but leaves as is. This may lead to unepxected results like OOB access. This patch corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 063422ca2a9d ("ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks") Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Sep 2 19:18:21 2025 +0200 ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping [ Upstream commit 4336efb59ef364e691ef829a73d9dbd4d5ed7c7b ] When an invalid value is passed via quirk option, currently bytcr_rt5640 driver just ignores and leaves as is, which may lead to unepxected results like OOB access. This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed. Fixes: 64484ccee7af ("ASoC: Intel: bytcr_rt5651: Set card long_name based on quirks") Signed-off-by: Takashi Iwai <[email protected]> Message-ID: <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alice Ryhl <[email protected]> Date: Wed Oct 15 14:26:55 2025 +0000 binder: remove "invalid inc weak" check commit d90eeb8ecd227c204ab6c34a17b372bd950b7aa2 upstream. There are no scenarios where a weak increment is invalid on binder_node. The only possible case where it could be invalid is if the kernel delivers BR_DECREFS to the process that owns the node, and then increments the weak refcount again, effectively "reviving" a dead node. However, that is not possible: when the BR_DECREFS command is delivered, the kernel removes and frees the binder_node. The fact that you were able to call binder_inc_node_nilocked() implies that the node is not yet destroyed, which implies that BR_DECREFS has not been delivered to userspace, so incrementing the weak refcount is valid. Note that it's currently possible to trigger this condition if the owner calls BINDER_THREAD_EXIT while node->has_weak_ref is true. This causes BC_INCREFS on binder_ref instances to fail when they should not. Cc: [email protected] Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Reported-by: Yu-Ting Tseng <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Li Nan <[email protected]> Date: Tue Aug 26 16:48:54 2025 +0800 blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx [ Upstream commit 4c7ef92f6d4d08a27d676e4c348f4e2922cab3ed ] In __blk_mq_update_nr_hw_queues() the return value of blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk] kobjct_del() was called unconditionally even if sysfs creation failed. Fix it by checkig the kobject creation statusbefore deleting it. Fixes: 477e19dedc9d ("blk-mq: adjust debugfs and sysfs register when updating nr_hw_queues") Signed-off-by: Li Nan <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Tue Sep 2 21:09:30 2025 +0800 block: use int to store blk_stack_limits() return value [ Upstream commit b0b4518c992eb5f316c6e40ff186cbb7a5009518 ] Change the 'ret' variable in blk_stack_limits() from unsigned int to int, as it needs to store negative value -1. Storing the negative error codes in unsigned type, or performing equality comparisons (e.g., ret == -1), doesn't cause an issue at runtime [1] but can be confusing. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Link: https://lore.kernel.org/all/x3wogjf6vgpkisdhg3abzrx7v7zktmdnfmqeih5kosszmagqfs@oh3qxrgzkikf/ #1 Signed-off-by: Qianfeng Rong <[email protected]> Reviewed-by: John Garry <[email protected]> Fixes: fe0b393f2c0a ("block: Correct handling of bottom device misaligment") Reviewed-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Chaignon <[email protected]> Date: Wed Sep 17 10:08:00 2025 +0200 bpf: Explicitly check accesses to bpf_sock_addr [ Upstream commit 6fabca2fc94d33cdf7ec102058983b086293395f ] Syzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exit which triggers: verifier bug: error during ctx access conversion (0) This is happening because offset 60 in bpf_sock_addr corresponds to an implicit padding of 4 bytes, right after msg_src_ip4. Access to this padding isn't rejected in sock_addr_is_valid_access and it thus later fails to convert the access. This patch fixes it by explicitly checking the various fields of bpf_sock_addr in sock_addr_is_valid_access. I checked the other ctx structures and is_valid_access functions and didn't find any other similar cases. Other cases of (properly handled) padding are covered in new tests in a subsequent patch. Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg") Reported-by: [email protected] Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=136ca59d411f92e821b7 Link: https://lore.kernel.org/bpf/b58609d9490649e76e584b0361da0abd3c2c1779.1758094761.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin <[email protected]>
Author: Anderson Nascimento <[email protected]> Date: Sat Oct 18 12:10:44 2025 -0400 btrfs: avoid potential out-of-bounds in btrfs_encode_fh() [ Upstream commit dff4f9ff5d7f289e4545cc936362e01ed3252742 ] The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/[email protected]/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data. Fixes: be6e8dc0ba84 ("NFS support for btrfs - v3") CC: [email protected] # 3.0+ Signed-off-by: Anderson Nascimento <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> [ replaced btrfs_root_id() calls with direct ->root->root_key.objectid access ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Sun Jul 6 13:11:55 2025 -0700 clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver [ Upstream commit 1624dead9a4d288a594fdf19735ebfe4bb567cb8 ] The conditional check for the PLL0 multiplier 'm' used a logical AND instead of OR, making the range check ineffective. This patch replaces && with || to correctly reject invalid values of 'm' that are either less than or equal to 0 or greater than LPC18XX_PLL0_MSEL_MAX. This ensures proper bounds checking during clk rate setting and rounding. Fixes: b04e0b8fd544 ("clk: add lpc18xx cgu clk driver") Signed-off-by: Alok Tiwari <[email protected]> [[email protected]: 'm' is unsigned so remove < condition] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Masney <[email protected]> Date: Mon Aug 11 11:18:29 2025 -0400 clk: nxp: lpc18xx-cgu: convert from round_rate() to determine_rate() [ Upstream commit b46a3d323a5b7942e65025254c13801d0f475f02 ] The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney <[email protected]> Stable-dep-of: 1624dead9a4d ("clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver") Signed-off-by: Sasha Levin <[email protected]>
Author: Zhen Ni <[email protected]> Date: Thu Aug 14 20:33:24 2025 +0800 clocksource/drivers/clps711x: Fix resource leaks in error paths commit cd32e596f02fc981674573402c1138f616df1728 upstream. The current implementation of clps711x_timer_init() has multiple error paths that directly return without releasing the base I/O memory mapped via of_iomap(). Fix of_iomap leaks in error paths. Fixes: 04410efbb6bc ("clocksource/drivers/clps711x: Convert init function to return error") Fixes: 2a6a8e2d9004 ("clocksource/drivers/clps711x: Remove board support") Signed-off-by: Zhen Ni <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Wed Sep 24 15:56:39 2025 +0530 comedi: fix divide-by-zero in comedi_buf_munge() commit 87b318ba81dda2ee7b603f4f6c55e78ec3e95974 upstream. The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=f6c3c066162d2c43a66c Cc: [email protected] Signed-off-by: Deepanshu Kartikey <[email protected]> Reviewed-by: Ian Abbott <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Fri Sep 5 15:52:03 2025 +0200 cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() commit 69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467 upstream. The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later. Fixes: da5c504c7aae ("cpufreq: intel_pstate: Implement QoS supported freq constraints") Cc: 5.4+ <[email protected]> # 5.4+ Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Zihuan Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Sat Aug 30 19:01:01 2025 +0900 cramfs: Verify inode mode when loading from disk [ Upstream commit 7f9d34b0a7cb93d678ee7207f0634dbf79e47fe5 ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <[email protected]> Link: https://lore.kernel.org/[email protected] Acked-by: Nicolas Pitre <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Wed Sep 3 10:34:46 2025 +0200 crypto: atmel - Fix dma_unmap_sg() direction commit f5d643156ef62216955c119216d2f3815bd51cb1 upstream. It seems like everywhere in this file, dd->in_sg is mapped with DMA_TO_DEVICE and dd->out_sg is mapped with DMA_FROM_DEVICE. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Cc: <[email protected]> Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Herbert Xu <[email protected]> Date: Wed Oct 8 15:54:20 2025 +0800 crypto: essiv - Check ssize for decryption and in-place encryption [ Upstream commit 6bb73db6948c2de23e407fe1b7ef94bf02b7529f ] Move the ssize check to the start in essiv_aead_crypt so that it's also checked for decryption and in-place encryption. Reported-by: Muhammad Alifa Ramdhan <[email protected]> Fixes: be1eb7f78aa8 ("crypto: essiv - create wrapper template for ESSIV generation") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Aring <[email protected]> Date: Wed Jul 23 11:21:52 2025 -0400 dlm: check for defined force value in dlm_lockspace_release [ Upstream commit 6af515c9f3ccec3eb8a262ca86bef2c499d07951 ] Force values over 3 are undefined, so don't treat them as 3. Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Sep 8 15:52:02 2025 +0200 dm-integrity: limit MAX_TAG_SIZE to 255 [ Upstream commit 77b8e6fbf9848d651f5cb7508f18ad0971f3ffdb ] MAX_TAG_SIZE was 0x1a8 and it may be truncated in the "bi->metadata_size = ic->tag_size" assignment. We need to limit it to 255. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Qixing <[email protected]> Date: Tue Oct 14 07:35:55 2025 -0400 dm: fix NULL pointer dereference in __dm_suspend() [ Upstream commit 8d33a030c566e1f105cd5bf27f37940b6367f3be ] There is a race condition between dm device suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes: BUG: kernel NULL pointer dereference, address: 0000000000000054 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50 Call Trace: <TASK> blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0 The issue can be triggered as below: T1 T2 dm_suspend table_load __dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1) dm_stop_queue / dm_wait_for_completion => q->tag_set NULL pointer! (2) => q->tag_set = set; (3) Fix this by checking if a valid table (map) exists before performing request-based suspend and waiting for target I/O. When map is NULL, skip these table-dependent suspend steps. Even when map is NULL, no I/O can reach any target because there is no table loaded; I/O submitted in this state will fail early in the DM layer. Skipping the table-dependent suspend logic in this case is safe and avoids NULL pointer dereferences. Fixes: c4576aed8d85 ("dm: fix request-based dm's use of dm_wait_for_completion") Cc: [email protected] Signed-off-by: Zheng Qixing <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> [ omitted DMF_QUEUE_STOPPED flag setting and braces absent in 5.15 ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Thu Aug 28 12:59:24 2025 +0200 driver core/PM: Set power.no_callbacks along with power.no_pm commit c2ce2453413d429e302659abc5ace634e873f6f5 upstream. Devices with power.no_pm set are not expected to need any power management at all, so modify device_set_pm_not_required() to set power.no_callbacks for them too in case runtime PM will be enabled for any of them (which in principle may be done for convenience if such a device participates in a dependency chain). Since device_set_pm_not_required() must be called before device_add() or it would not have any effect, it can update power.no_callbacks without locking, unlike pm_runtime_no_callbacks() that can be called after registering the target device. Signed-off-by: Rafael J. Wysocki <[email protected]> Cc: stable <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Donet Tom <[email protected]> Date: Thu Sep 18 11:11:44 2025 +0530 drivers/base/node: fix double free in register_one_node() [ Upstream commit 0efdedfa537eb534c251a5b4794caaf72cc55869 ] When device_register() fails in register_node(), it calls put_device(&node->dev). This triggers node_device_release(), which calls kfree(to_node(dev)), thereby freeing the entire node structure. As a result, when register_node() returns an error, the node memory has already been freed. Calling kfree(node) again in register_one_node() leads to a double free. This patch removes the redundant kfree(node) from register_one_node() to prevent the double free. Link: https://lkml.kernel.org/r/[email protected] Fixes: 786eb990cfb7 ("drivers/base/node: handle error properly in register_one_node()") Signed-off-by: Donet Tom <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Oscar Salvador <[email protected]> Cc: Alison Schofield <[email protected]> Cc: Chris Mason <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Hiroyouki Kamezawa <[email protected]> Cc: Joanthan Cameron <[email protected]> Cc: "Ritesh Harjani (IBM)" <[email protected]> Cc: Yury Norov (NVIDIA) <[email protected]> Cc: Zi Yan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Donet Tom <[email protected]> Date: Fri Aug 22 14:18:45 2025 +0530 drivers/base/node: handle error properly in register_one_node() [ Upstream commit 786eb990cfb78aab94eb74fb32a030e14723a620 ] If register_node() returns an error, it is not handled correctly. The function will proceed further and try to register CPUs under the node, which is not correct. So, in this patch, if register_node() returns an error, we return immediately from the function. Link: https://lkml.kernel.org/r/[email protected] Fixes: 76b67ed9dce6 ("[PATCH] node hotplug: register cpu: remove node struct") Signed-off-by: Donet Tom <[email protected]> Acked-by: David Hildenbrand <[email protected]> Cc: Alison Schofield <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Donet Tom <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Hiroyouki Kamezawa <[email protected]> Cc: Joanthan Cameron <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: "Ritesh Harjani (IBM)" <[email protected]> Cc: Yury Norov (NVIDIA) <[email protected]> Cc: Zi Yan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gui-Dong Han <[email protected]> Date: Tue Oct 21 09:51:54 2025 -0400 drm/amdgpu: use atomic functions with memory barriers for vm fault info [ Upstream commit 6df8e84aa6b5b1812cc2cacd6b3f5ccbb18cda2b ] The atomic variable vm_fault_info_updated is used to synchronize access to adev->gmc.vm_fault_info between the interrupt handler and get_vm_fault_info(). The default atomic functions like atomic_set() and atomic_read() do not provide memory barriers. This allows for CPU instruction reordering, meaning the memory accesses to vm_fault_info and the vm_fault_info_updated flag are not guaranteed to occur in the intended order. This creates a race condition that can lead to inconsistent or stale data being used. The previous implementation, which used an explicit mb(), was incomplete and inefficient. It failed to account for all potential CPU reorderings, such as the access of vm_fault_info being reordered before the atomic_read of the flag. This approach is also more verbose and less performant than using the proper atomic functions with acquire/release semantics. Fix this by switching to atomic_set_release() and atomic_read_acquire(). These functions provide the necessary acquire and release semantics, which act as memory barriers to ensure the correct order of operations. It is also more efficient and idiomatic than using explicit full memory barriers. Fixes: b97dfa27ef3a ("drm/amdgpu: save vm fault information for amdkfd") Cc: [email protected] Signed-off-by: Gui-Dong Han <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> [ kept kgd_dev parameter and adev cast in amdgpu_amdkfd_gpuvm_get_vm_fault_info ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kaustabh Chakraborty <[email protected]> Date: Sat Oct 18 09:57:00 2025 -0400 drm/exynos: exynos7_drm_decon: remove ctx->suspended [ Upstream commit e1361a4f1be9cb69a662c6d7b5ce218007d6e82b ] Condition guards are found to be redundant, as the call flow is properly managed now, as also observed in the Exynos5433 DECON driver. Since state checking is no longer necessary, remove it. This also fixes an issue which prevented decon_commit() from decon_atomic_enable() due to an incorrect state change setting. Fixes: 96976c3d9aff ("drm/exynos: Add DECON driver") Cc: [email protected] Suggested-by: Inki Dae <[email protected]> Signed-off-by: Kaustabh Chakraborty <[email protected]> Signed-off-by: Inki Dae <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuhao Fu <[email protected]> Date: Wed Oct 8 00:17:09 2025 +0800 drm/nouveau: fix bad ret code in nouveau_bo_move_prep commit e4bea919584ff292c9156cf7d641a2ab3cbe27b0 upstream. In `nouveau_bo_move_prep`, if `nouveau_mem_map` fails, an error code should be returned. Currently, it returns zero even if vmm addr is not correctly mapped. Cc: [email protected] Reviewed-by: Petr Vorel <[email protected]> Signed-off-by: Shuhao Fu <[email protected]> Fixes: 9ce523cc3bf2 ("drm/nouveau: separate buffer object backing memory from nvkm structures") Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brahmajit Das <[email protected]> Date: Mon Aug 11 14:51:25 2025 +0530 drm/radeon/r600_cs: clean up of dead code in r600_cs [ Upstream commit 260dcf5b06d519bcf27a5dfdb5c626821a55c170 ] GCC 16 enables -Werror=unused-but-set-variable= which results in build error with the following message. drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_texture_size’: drivers/gpu/drm/radeon/r600_cs.c:1411:29: error: variable ‘level’ set but not used [-Werror=unused-but-set-variable=] 1411 | unsigned offset, i, level; | ^~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/radeon/r600_cs.o] Error 1 level although is set, but in never used in the function r600_texture_size. Thus resulting in dead code and this error getting triggered. Fixes: 60b212f8ddcd ("drm/radeon: overhaul texture checking. (v3)") Acked-by: Christian König <[email protected]> Signed-off-by: Brahmajit Das <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Fri Sep 26 14:54:25 2025 -0500 drm/vmwgfx: Fix Use-after-free in validation [ Upstream commit dfe1323ab3c8a4dd5625ebfdba44dc47df84512a ] Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely. Fixes: 64ad2abfe9a6 ("drm/vmwgfx: Adapt validation code for reference-free lookups") Reported-by: Kuzey Arda Bulut <[email protected]> Signed-off-by: Ian Forbes <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xichao Zhao <[email protected]> Date: Mon Aug 25 15:36:09 2025 +0800 exec: Fix incorrect type for ret [ Upstream commit 5e088248375d171b80c643051e77ade6b97bc386 ] In the setup_arg_pages(), ret is declared as an unsigned long. The ret might take a negative value. Therefore, its type should be changed to int. Signed-off-by: Xichao Zhao <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Theodore Ts'o <[email protected]> Date: Tue Oct 21 13:49:05 2025 -0400 ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() [ Upstream commit 8ecb790ea8c3fc69e77bace57f14cf0d7c177bd8 ] Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring. Cc: [email protected] Fixes: 8b67f04ab9de ("ext4: Add mount options in superblock") Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> [ applied to ext4_fill_super() instead of parse_apply_sb_mount_options() ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ojaswin Mujoo <[email protected]> Date: Fri Sep 5 13:44:46 2025 +0530 ext4: correctly handle queries for metadata mappings commit 46c22a8bb4cb03211da1100d7ee4a2005bf77c70 upstream. Currently, our handling of metadata is _ambiguous_ in some scenarios, that is, we end up returning unknown if the range only covers the mapping partially. For example, in the following case: $ xfs_io -c fsmap -d 0: 254:16 [0..7]: static fs metadata 8 1: 254:16 [8..15]: special 102:1 8 2: 254:16 [16..5127]: special 102:2 5112 3: 254:16 [5128..5255]: special 102:3 128 4: 254:16 [5256..5383]: special 102:4 128 5: 254:16 [5384..70919]: inodes 65536 6: 254:16 [70920..70967]: unknown 48 ... $ xfs_io -c fsmap -d 24 33 0: 254:16 [24..39]: unknown 16 <--- incomplete reporting $ xfs_io -c fsmap -d 24 33 (With patch) 0: 254:16 [16..5127]: special 102:2 5112 This is because earlier in ext4_getfsmap_meta_helper, we end up ignoring any extent that starts before our queried range, but overlaps it. While the man page [1] is a bit ambiguous on this, this fix makes the output make more sense since we are anyways returning an "unknown" extent. This is also consistent to how XFS does it: $ xfs_io -c fsmap -d ... 6: 254:16 [104..127]: free space 24 7: 254:16 [128..191]: inodes 64 ... $ xfs_io -c fsmap -d 137 150 0: 254:16 [128..191]: inodes 64 <-- full extent returned [1] https://man7.org/linux/man-pages/man2/ioctl_getfsmap.2.html Reported-by: Ritesh Harjani (IBM) <[email protected]> Cc: [email protected] Signed-off-by: Ojaswin Mujoo <[email protected]> Message-ID: <023f37e35ee280cd9baac0296cbadcbe10995cab.1757058211.git.ojaswin@linux.ibm.com> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Tue Oct 21 09:12:17 2025 -0400 ext4: detect invalid INLINE_DATA + EXTENTS flag combination [ Upstream commit 1d3ad183943b38eec2acf72a0ae98e635dc8456b ] syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode. Cc: [email protected] Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=038b7bf43423e132b308 Suggested-by: Zhang Yi <[email protected]> Signed-off-by: Deepanshu Kartikey <[email protected]> Reviewed-by: Zhang Yi <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ahmet Eray Karadag <[email protected]> Date: Sat Sep 20 05:13:43 2025 +0300 ext4: guard against EA inode refcount underflow in xattr update commit 57295e835408d8d425bef58da5253465db3d6888 upstream. syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1). That lets the refcount underflow and we proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode <n> ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117 Make the invariant explicit: if the current refcount is non-positive, treat this as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. Delete the WARN_ONCE() as negative refcounts are now impossible; keep error reporting in ext4_error_inode(). This prevents the underflow and the follow-on orphan/cleanup churn. Reported-by: [email protected] Fixes: https://syzbot.org/bug?extid=0be4f339a8218d2a5bb1 Cc: [email protected] Co-developed-by: Albin Babu Varghese <[email protected]> Signed-off-by: Albin Babu Varghese <[email protected]> Signed-off-by: Ahmet Eray Karadag <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yongjian Sun <[email protected]> Date: Thu Sep 11 21:30:24 2025 +0800 ext4: increase i_disksize to offset + len in ext4_update_disksize_before_punch() commit 9d80eaa1a1d37539224982b76c9ceeee736510b9 upstream. After running a stress test combined with fault injection, we performed fsck -a followed by fsck -fn on the filesystem image. During the second pass, fsck -fn reported: Inode 131512, end of extent exceeds allowed value (logical block 405, physical block 1180540, len 2) This inode was not in the orphan list. Analysis revealed the following call chain that leads to the inconsistency: ext4_da_write_end() //does not update i_disksize ext4_punch_hole() //truncate folio, keep size ext4_page_mkwrite() ext4_block_page_mkwrite() ext4_block_write_begin() ext4_get_block() //insert written extent without update i_disksize journal commit echo 1 > /sys/block/xxx/device/delete da-write path updates i_size but does not update i_disksize. Then ext4_punch_hole truncates the da-folio yet still leaves i_disksize unchanged(in the ext4_update_disksize_before_punch function, the condition offset + len < size is met). Then ext4_page_mkwrite sees ext4_nonda_switch return 1 and takes the nodioread_nolock path, the folio about to be written has just been punched out, and it’s offset sits beyond the current i_disksize. This may result in a written extent being inserted, but again does not update i_disksize. If the journal gets committed and then the block device is yanked, we might run into this. It should be noted that replacing ext4_punch_hole with ext4_zero_range in the call sequence may also trigger this issue, as neither will update i_disksize under these circumstances. To fix this, we can modify ext4_update_disksize_before_punch to increase i_disksize to min(i_size, offset + len) when both i_size and (offset + len) are greater than i_disksize. Cc: [email protected] Signed-off-by: Yongjian Sun <[email protected]> Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Baokun Li <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Jul 25 09:40:19 2025 +0200 firmware: meson_sm: fix device leak at probe commit 8ece3173f87df03935906d0c612c2aeda9db92ca upstream. Make sure to drop the reference to the secure monitor device taken by of_find_device_by_node() when looking up its driver data on behalf of other drivers (e.g. during probe). Note that holding a reference to the platform device does not prevent its driver data from going away so there is no point in keeping the reference after the helper returns. Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver") Cc: [email protected] # 5.5 Cc: Carlo Caione <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lichen Liu <[email protected]> Date: Fri Aug 15 20:14:59 2025 +0800 fs: Add 'initramfs_options' to set initramfs mount options [ Upstream commit 278033a225e13ec21900f0a92b8351658f5377f2 ] When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs. By default, a tmpfs mount is limited to using 50% of the available RAM for its content. This can be problematic in memory-constrained environments, particularly during a kdump capture. In a kdump scenario, the capture kernel boots with a limited amount of memory specified by the 'crashkernel' parameter. If the initramfs is large, it may fail to unpack into the tmpfs rootfs due to insufficient space. This is because to get X MB of usable space in tmpfs, 2*X MB of memory must be available for the mount. This leads to an OOM failure during the early boot process, preventing a successful crash dump. This patch introduces a new kernel command-line parameter, initramfs_options, which allows passing specific mount options directly to the rootfs when it is first mounted. This gives users control over the rootfs behavior. For example, a user can now specify initramfs_options=size=75% to allow the tmpfs to use up to 75% of the available memory. This can significantly reduce the memory pressure for kdump. Consider a practical example: To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With the default 50% limit, this requires a memory pool of 96MB to be available for the tmpfs mount. The total memory requirement is therefore approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB. By using initramfs_options=size=75%, the memory pool required for the 48MB tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a smaller crashkernel size, such as 192MB. An alternative approach of reusing the existing rootflags parameter was considered. However, a new, dedicated initramfs_options parameter was chosen to avoid altering the current behavior of rootflags (which applies to the final root filesystem) and to prevent any potential regressions. Also add documentation for the new kernel parameter "initramfs_options" This approach is inspired by prior discussions and patches on the topic. Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128 Ref: https://landley.net/notes-2015.html#01-01-2015 Ref: https://lkml.org/lkml/2021/6/29/783 Ref: https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs Signed-off-by: Lichen Liu <[email protected]> Link: https://lore.kernel.org/[email protected] Tested-by: Rob Landley <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Larshin Sergey <[email protected]> Date: Mon Oct 13 17:45:00 2025 -0400 fs: udf: fix OOB read in lengthAllocDescs handling [ Upstream commit 3bd5e45c2ce30e239d596becd5db720f7eb83c99 ] When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309 CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Validate the computed total length against epos->bh->b_size. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=8743fca924afed42f93e Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Larshin Sergey <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Fri Aug 15 12:49:19 2025 -0700 hfs: clear offset and space out of valid records in b-tree node [ Upstream commit 18b07c44f245beb03588b00b212b38fce9af7cc9 ] Currently, hfs_brec_remove() executes moving records towards the location of deleted record and it updates offsets of moved records. However, the hfs_brec_remove() logic ignores the "mess" of b-tree node's free space and it doesn't touch the offsets out of records number. Potentially, it could confuse fsck or driver logic or to be a reason of potential corruption cases. This patch reworks the logic of hfs_brec_remove() by means of clearing freed space of b-tree node after the records moving. And it clear the last offset that keeping old location of free space because now the offset before this one is keeping the actual offset to the free space after the record deletion. Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Wed Aug 20 16:06:38 2025 -0700 hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() [ Upstream commit 2048ec5b98dbdfe0b929d2e42dc7a54c389c53dd ] The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the "garbage", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and "garbage" in the not initialized memory will be the reason of volume coruptions and file system driver bugs. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=773fa9d79b29bd8b6831 Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Mon Aug 18 15:52:52 2025 -0700 hfs: make proper initalization of struct hfs_find_data [ Upstream commit c62663a986acee7c4485c1fa9de5fc40194b6290 ] Potenatially, __hfs_ext_read_extent() could operate by not initialized values of fd->key after hfs_brec_find() call: static inline int __hfs_ext_read_extent(struct hfs_find_data *fd, struct hfs_extent *extent, u32 cnid, u32 block, u8 type) { int res; hfs_ext_build_key(fd->search_key, cnid, block, type); fd->key->ext.FNum = 0; res = hfs_brec_find(fd); if (res && res != -ENOENT) return res; if (fd->key->ext.FNum != fd->search_key->ext.FNum || fd->key->ext.FkType != fd->search_key->ext.FkType) return -ENOENT; if (fd->entrylength != sizeof(hfs_extent_rec)) return -EIO; hfs_bnode_read(fd->bnode, extent, fd->entryoffset, sizeof(hfs_extent_rec)); return 0; } This patch changes kmalloc() on kzalloc() in hfs_find_init() and intializes fd->record, fd->keyoffset, fd->keylength, fd->entryoffset, fd->entrylength for the case if hfs_brec_find() has been found nothing in the b-tree node. Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Chenzhi <[email protected]> Date: Mon Aug 18 22:17:34 2025 +0800 hfs: validate record offset in hfsplus_bmap_alloc [ Upstream commit 738d5a51864ed8d7a68600b8c0c63fe6fe5c4f20 ] hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] <TASK> [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 <f3> 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] </TASK> When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions. Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yang Chenzhi <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Mon Aug 18 15:52:32 2025 -0700 hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() [ Upstream commit 4840ceadef4290c56cc422f0fc697655f3cbf070 ] The syzbot reported issue in __hfsplus_ext_cache_extent(): [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] <TASK> [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 [ 70.229458][ T9350] ? __x64_sys_write+0x97/0xf0 [ 70.229939][ T9350] ? x64_sys_call+0x3015/0x3cf0 [ 70.230432][ T9350] ? do_syscall_64+0xd9/0x1d0 [ 70.230941][ T9350] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.231926][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.232738][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.233711][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.234516][ T9350] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.235398][ T9350] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.236323][ T9350] ? hfsplus_brec_find+0x218/0x9f0 [ 70.237090][ T9350] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 70.237938][ T9350] ? __msan_instrument_asm_store+0xbf/0xf0 [ 70.238827][ T9350] ? __msan_metadata_ptr_for_store_4+0x27/0x40 [ 70.239772][ T9350] ? __hfsplus_ext_write_extent+0x536/0x620 [ 70.240666][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.241175][ T9350] __msan_warning+0x96/0x120 [ 70.241645][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.242223][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.242748][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.243255][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.243878][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.244400][ T9350] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.244967][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.245531][ T9350] ? __pfx_hfsplus_get_block+0x10/0x10 [ 70.246079][ T9350] cont_write_begin+0x1000/0x1950 [ 70.246598][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.247105][ T9350] ? __pfx_hfsplus_get_block+0x10/0x10 [ 70.247650][ T9350] ? __pfx_hfsplus_write_begin+0x10/0x10 [ 70.248211][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.248752][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.249314][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.249856][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.250487][ T9350] vfs_write+0xb0f/0x14e0 [ 70.250930][ T9350] ? __pfx_generic_file_write_iter+0x10/0x10 [ 70.251530][ T9350] ksys_write+0x23e/0x490 [ 70.251974][ T9350] __x64_sys_write+0x97/0xf0 [ 70.252450][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.252924][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.253384][ T9350] ? irqentry_exit+0x16/0x60 [ 70.253844][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.254430][ T9350] RIP: 0033:0x7f7a92adffc9 [ 70.254873][ T9350] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 70.256674][ T9350] RSP: 002b:00007fff0bca3188 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 70.257485][ T9350] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7a92adffc9 [ 70.258246][ T9350] RDX: 000000000208e24b RSI: 0000000020000100 RDI: 0000000000000004 [ 70.258998][ T9350] RBP: 00007fff0bca31a0 R08: 00007fff0bca31a0 R09: 00007fff0bca31a0 [ 70.259769][ T9350] R10: 0000000000000000 R11: 0000000000000202 R12: 000055e0d75f8250 [ 70.260520][ T9350] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 70.261286][ T9350] </TASK> [ 70.262026][ T9350] Kernel Offset: disabled (gdb) l *__hfsplus_ext_cache_extent+0x7d0 0xffffffff8318aef0 is in __hfsplus_ext_cache_extent (fs/hfsplus/extents.c:168). 163 fd->key->ext.cnid = 0; 164 res = hfs_brec_find(fd, hfs_find_rec_by_key); 165 if (res && res != -ENOENT) 166 return res; 167 if (fd->key->ext.cnid != fd->search_key->ext.cnid || 168 fd->key->ext.fork_type != fd->search_key->ext.fork_type) 169 return -ENOENT; 170 if (fd->entrylength != sizeof(hfsplus_extent_rec)) 171 return -EIO; 172 hfs_bnode_read(fd->bnode, extent, fd->entryoffset, The __hfsplus_ext_cache_extent() calls __hfsplus_ext_read_extent(): res = __hfsplus_ext_read_extent(fd, hip->cached_extents, inode->i_ino, block, HFSPLUS_IS_RSRC(inode) ? HFSPLUS_TYPE_RSRC : HFSPLUS_TYPE_DATA); And if inode->i_ino could be equal to zero or any non-available CNID, then hfs_brec_find() could not find the record in the tree. As a result, fd->key could be compared with fd->search_key. But hfsplus_find_init() uses kmalloc() for fd->key and fd->search_key allocation: int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd) { <skipped> ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL); if (!ptr) return -ENOMEM; fd->search_key = ptr; fd->key = ptr + tree->max_key_len + 2; <skipped> } Finally, fd->key is still not initialized if hfs_brec_find() has found nothing. This patch changes kmalloc() on kzalloc() in hfs_find_init() and intializes fd->record, fd->keyoffset, fd->keylength, fd->entryoffset, fd->entrylength for the case if hfs_brec_find() has been found nothing in the b-tree node. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=55ad87f38795d6787521 Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Mon Aug 25 15:51:04 2025 -0700 hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() [ Upstream commit 9b3d15a758910bb98ba8feb4109d99cc67450ee4 ] The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Tainted: G B 6.12.0-rc6-dirty #17 [ 70.715007][ T9333] Tainted: [B]=BAD_PAGE [ 70.715365][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.716311][ T9333] Call Trace: [ 70.716621][ T9333] <TASK> [ 70.716899][ T9333] dump_stack_lvl+0x1fd/0x2b0 [ 70.717350][ T9333] dump_stack+0x1e/0x30 [ 70.717743][ T9333] panic+0x502/0xca0 [ 70.718116][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.718611][ T9333] kmsan_report+0x296/0x2a0 [ 70.719038][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.719859][ T9333] ? __msan_warning+0x96/0x120 [ 70.720345][ T9333] ? hfsplus_subfolders_dec+0x1d7/0x220 [ 70.720881][ T9333] ? hfsplus_delete_cat+0x105d/0x12b0 [ 70.721412][ T9333] ? hfsplus_rmdir+0x13d/0x310 [ 70.721880][ T9333] ? vfs_rmdir+0x5ba/0x810 [ 70.722458][ T9333] ? do_rmdir+0x964/0xea0 [ 70.722883][ T9333] ? __x64_sys_rmdir+0x71/0xb0 [ 70.723397][ T9333] ? x64_sys_call+0xcd8/0x3cf0 [ 70.723915][ T9333] ? do_syscall_64+0xd9/0x1d0 [ 70.724454][ T9333] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.725110][ T9333] ? vprintk_emit+0xd1f/0xe60 [ 70.725616][ T9333] ? vprintk_default+0x3f/0x50 [ 70.726175][ T9333] ? vprintk+0xce/0xd0 [ 70.726628][ T9333] ? _printk+0x17e/0x1b0 [ 70.727129][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.727739][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.728324][ T9333] __msan_warning+0x96/0x120 [ 70.728854][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.729479][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.729984][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.730646][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.731296][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.731863][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.732390][ T9333] ? __pfx_hfsplus_rmdir+0x10/0x10 [ 70.732919][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.733416][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.734044][ T9333] do_rmdir+0x964/0xea0 [ 70.734537][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.735032][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.735579][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.736092][ T9333] ? irqentry_exit+0x16/0x60 [ 70.736637][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.737269][ T9333] RIP: 0033:0x7fa9424eafc9 [ 70.737775][ T9333] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 70.739844][ T9333] RSP: 002b:00007fff099cd8d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000054 [ 70.740760][ T9333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa9424eafc9 [ 70.741642][ T9333] RDX: 006c6f72746e6f63 RSI: 000000000000000a RDI: 0000000020000100 [ 70.742543][ T9333] RBP: 00007fff099cd8e0 R08: 00007fff099cd910 R09: 00007fff099cd910 [ 70.743376][ T9333] R10: 0000000000000000 R11: 0000000000000202 R12: 0000565430642260 [ 70.744247][ T9333] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 70.745082][ T9333] </TASK> The main reason of the issue that struct hfsplus_inode_info has not been properly initialized for the case of root folder. In the case of root folder, hfsplus_fill_super() calls the hfsplus_iget() that implements only partial initialization of struct hfsplus_inode_info and subfolders field is not initialized by hfsplus_iget() logic. This patch implements complete initialization of struct hfsplus_inode_info in the hfsplus_iget() logic with the goal to prevent likewise issues for the case of root folder. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=fdedff847a0e5e84c39f Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Dubeyko <[email protected]> Date: Fri Sep 19 12:12:44 2025 -0700 hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() commit 42520df65bf67189541a425f7d36b0b3e7bd7844 upstream. The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] <TASK> [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ORIG_RAX: 00000000000000a6 [ 117.320172][ T9855] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dd7908b07 [ 117.320176][ T9855] RDX: 0000000000000009 RSI: 0000000000000009 RDI: 00007ffd5ebd9740 [ 117.320179][ T9855] RBP: 00007ffd5ebda780 R08: 0000000000000005 R09: 00007ffd5ebd9530 [ 117.320181][ T9855] R10: 00007f7dd799bfc0 R11: 0000000000000202 R12: 000055e2008b32d0 [ 117.320184][ T9855] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 117.320189][ T9855] </TASK> [ 117.320190][ T9855] [ 117.351311][ T9855] Allocated by task 9855: [ 117.351683][ T9855] kasan_save_track+0x3e/0x80 [ 117.352093][ T9855] __kasan_kmalloc+0x8d/0xa0 [ 117.352490][ T9855] __kmalloc_noprof+0x288/0x510 [ 117.352914][ T9855] hfsplus_find_init+0x8c/0x1d0 [ 117.353342][ T9855] hfsplus_lookup+0x19c/0x890 [ 117.353747][ T9855] __lookup_slow+0x297/0x3d0 [ 117.354148][ T9855] lookup_slow+0x53/0x70 [ 117.354514][ T9855] walk_component+0x2f0/0x430 [ 117.354921][ T9855] path_lookupat+0x169/0x440 [ 117.355325][ T9855] filename_lookup+0x212/0x590 [ 117.355740][ T9855] user_path_at+0x3a/0x60 [ 117.356115][ T9855] __x64_sys_umount+0xee/0x160 [ 117.356529][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.356920][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.357429][ T9855] [ 117.357636][ T9855] The buggy address belongs to the object at ffff88802160f000 [ 117.357636][ T9855] which belongs to the cache kmalloc-2k of size 2048 [ 117.358827][ T9855] The buggy address is located 0 bytes to the right of [ 117.358827][ T9855] allocated 1036-byte region [ffff88802160f000, ffff88802160f40c) [ 117.360061][ T9855] [ 117.360266][ T9855] The buggy address belongs to the physical page: [ 117.360813][ T9855] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x21608 [ 117.361562][ T9855] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 117.362285][ T9855] flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff) [ 117.362929][ T9855] page_type: f5(slab) [ 117.363282][ T9855] raw: 00fff00000000040 ffff88801a842f00 ffffea0000932000 dead000000000002 [ 117.364015][ T9855] raw: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000 [ 117.364750][ T9855] head: 00fff00000000040 ffff88801a842f00 ffffea0000932000 dead000000000002 [ 117.365491][ T9855] head: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000 [ 117.366232][ T9855] head: 00fff00000000003 ffffea0000858201 00000000ffffffff 00000000ffffffff [ 117.366968][ T9855] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 [ 117.367711][ T9855] page dumped because: kasan: bad access detected [ 117.368259][ T9855] page_owner tracks the page as allocated [ 117.368745][ T9855] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN1 [ 117.370541][ T9855] post_alloc_hook+0x240/0x2a0 [ 117.370954][ T9855] get_page_from_freelist+0x2101/0x21e0 [ 117.371435][ T9855] __alloc_frozen_pages_noprof+0x274/0x380 [ 117.371935][ T9855] alloc_pages_mpol+0x241/0x4b0 [ 117.372360][ T9855] allocate_slab+0x8d/0x380 [ 117.372752][ T9855] ___slab_alloc+0xbe3/0x1400 [ 117.373159][ T9855] __kmalloc_cache_noprof+0x296/0x3d0 [ 117.373621][ T9855] nexthop_net_init+0x75/0x100 [ 117.374038][ T9855] ops_init+0x35c/0x5c0 [ 117.374400][ T9855] setup_net+0x10c/0x320 [ 117.374768][ T9855] copy_net_ns+0x31b/0x4d0 [ 117.375156][ T9855] create_new_namespaces+0x3f3/0x720 [ 117.375613][ T9855] unshare_nsproxy_namespaces+0x11c/0x170 [ 117.376094][ T9855] ksys_unshare+0x4ca/0x8d0 [ 117.376477][ T9855] __x64_sys_unshare+0x38/0x50 [ 117.376879][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.377265][ T9855] page last free pid 9110 tgid 9110 stack trace: [ 117.377795][ T9855] __free_frozen_pages+0xbeb/0xd50 [ 117.378229][ T9855] __put_partials+0x152/0x1a0 [ 117.378625][ T9855] put_cpu_partial+0x17c/0x250 [ 117.379026][ T9855] __slab_free+0x2d4/0x3c0 [ 117.379404][ T9855] qlist_free_all+0x97/0x140 [ 117.379790][ T9855] kasan_quarantine_reduce+0x148/0x160 [ 117.380250][ T9855] __kasan_slab_alloc+0x22/0x80 [ 117.380662][ T9855] __kmalloc_noprof+0x232/0x510 [ 117.381074][ T9855] tomoyo_supervisor+0xc0a/0x1360 [ 117.381498][ T9855] tomoyo_env_perm+0x149/0x1e0 [ 117.381903][ T9855] tomoyo_find_next_domain+0x15ad/0x1b90 [ 117.382378][ T9855] tomoyo_bprm_check_security+0x11c/0x180 [ 117.382859][ T9855] security_bprm_check+0x89/0x280 [ 117.383289][ T9855] bprm_execve+0x8f1/0x14a0 [ 117.383673][ T9855] do_execveat_common+0x528/0x6b0 [ 117.384103][ T9855] __x64_sys_execve+0x94/0xb0 [ 117.384500][ T9855] [ 117.384706][ T9855] Memory state around the buggy address: [ 117.385179][ T9855] ffff88802160f300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 117.385854][ T9855] ffff88802160f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 117.386534][ T9855] >ffff88802160f400: 00 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 117.387204][ T9855] ^ [ 117.387566][ T9855] ffff88802160f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 117.388243][ T9855] ffff88802160f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 117.388918][ T9855] ================================================================== The issue takes place if the length field of struct hfsplus_unistr is bigger than HFSPLUS_MAX_STRLEN. The patch simply checks the length of comparing strings. And if the strings' length is bigger than HFSPLUS_MAX_STRLEN, then it is corrected to this value. v2 The string length correction has been added for hfsplus_strcmp(). Reported-by: Jiaming Zhang <[email protected]> Signed-off-by: Viacheslav Dubeyko <[email protected]> cc: John Paul Adrian Glaubitz <[email protected]> cc: Yangtao Li <[email protected]> cc: [email protected] cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yangtao Li <[email protected]> Date: Tue Aug 5 10:58:59 2025 -0600 hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super() [ Upstream commit 9282bc905f0949fab8cf86c0f620ca988761254c ] If Catalog File contains corrupted record for the case of hidden directory's type, regard it as I/O error instead of Invalid argument. Signed-off-by: Yangtao Li <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kunihiko Hayashi <[email protected]> Date: Thu Jul 24 13:22:11 2025 +0900 i2c: designware: Add disabling clocks when probe fails [ Upstream commit c149841b069ccc6e480b00e11f35a57b5d88c7bb ] After an error occurs during probing state, dw_i2c_plat_pm_cleanup() is called. However, this function doesn't disable clocks and the clock-enable count keeps increasing. Should disable these clocks explicitly. Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM") Co-developed-by: Kohei Ito <[email protected]> Signed-off-by: Kohei Ito <[email protected]> Signed-off-by: Kunihiko Hayashi <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leilk.Liu <[email protected]> Date: Sat Sep 6 16:24:06 2025 +0800 i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD [ Upstream commit b492183652808e0f389272bf63dc836241b287ff ] The old IC does not support the I2C_MASTER_WRRD (write-then-read) function, but the current code’s handling of i2c->auto_restart may potentially lead to entering the I2C_MASTER_WRRD software flow, resulting in unexpected bugs. Instead of repurposing the auto_restart flag, add a separate flag to signal I2C_MASTER_WRRD operations. Also fix handling of msgs. If the operation (i2c->op) is I2C_MASTER_WRRD, then the msgs pointer is incremented by 2. For all other operations, msgs is simply incremented by 1. Fixes: b2ed11e224a2 ("I2C: mediatek: Add driver for MediaTek MT8173 I2C controller") Signed-off-by: Leilk.Liu <[email protected]> Suggested-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vlad Dumitrescu <[email protected]> Date: Tue Sep 16 19:31:12 2025 +0300 IB/sa: Fix sa_local_svc_timeout_ms read race [ Upstream commit 1428cd764cd708d53a072a2f208d87014bfe05bc ] When computing the delta, the sa_local_svc_timeout_ms is read without ib_nl_request_lock held. Though unlikely in practice, this can cause a race condition if multiple local service threads are managing the timeout. Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink") Signed-off-by: Vlad Dumitrescu <[email protected]> Reviewed-by: Mark Zhang <[email protected]> Signed-off-by: Edward Srouji <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Aug 31 12:48:21 2025 +0200 iio: consumers: Fix offset handling in iio_convert_raw_to_processed() [ Upstream commit 33f5c69c4daff39c010b3ea6da8ebab285f4277b ] Fix iio_convert_raw_to_processed() offset handling for channels without a scale attribute. The offset has been applied to the raw64 value not to the original raw value. Use the raw64 value so that the offset is taken into account. Fixes: 14b457fdde38 ("iio: inkern: apply consumer scale when no channel scale is available") Cc: Liam Beguin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Mon Sep 1 21:57:25 2025 +0800 iio: dac: ad5360: use int type to store negative error codes commit f9381ece76de999a2065d5b4fdd87fa17883978c upstream. Change the 'ret' variable in ad5360_update_ctrl() from unsigned int to int, as it needs to store either negative error codes or zero returned by ad5360_write_unlocked(). Fixes: a3e2940c24d3 ("staging:iio:dac: Add AD5360 driver") Signed-off-by: Qianfeng Rong <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Mon Sep 1 21:57:26 2025 +0800 iio: dac: ad5421: use int type to store negative error codes commit 3379c900320954d768ed9903691fb2520926bbe3 upstream. Change the 'ret' variable in ad5421_update_ctrl() from unsigned int to int, as it needs to store either negative error codes or zero returned by ad5421_write_unlocked(). Fixes: 5691b23489db ("staging:iio:dac: Add AD5421 driver") Signed-off-by: Qianfeng Rong <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Hennerich <[email protected]> Date: Fri Aug 29 12:25:43 2025 +0100 iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE commit 1d8fdabe19267338f29b58f968499e5b55e6a3b6 upstream. The clk div bits (2 bits wide) do not start in bit 16 but in bit 15. Fix it accordingly. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Michael Hennerich <[email protected]> Signed-off-by: Nuno Sá <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Hennerich <[email protected]> Date: Fri Aug 29 12:25:42 2025 +0100 iio: frequency: adf4350: Fix prescaler usage. commit 33d7ecbf69aa7dd4145e3b77962bcb8759eede3d upstream. The ADF4350/1 features a programmable dual-modulus prescaler of 4/5 or 8/9. When set to 4/5, the maximum RF frequency allowed is 3 GHz. Therefore, when operating the ADF4351 above 3 GHz, this must be set to 8/9. In this context not the RF output frequency is meant - it's the VCO frequency. Therefore move the prescaler selection after we derived the VCO frequency from the desired RF output frequency. This BUG may have caused PLL lock instabilities when operating the VCO at the very high range close to 4.4 GHz. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Michael Hennerich <[email protected]> Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhen Ni <[email protected]> Date: Sun Sep 28 14:37:37 2025 +0800 Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak commit d3366a04770eea807f2826cbdb96934dd8c9bf79 upstream. Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace. Initialize ff_up_compat to zero before filling valid fields. Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") Cc: [email protected] Signed-off-by: Zhen Ni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Slavin Liu <[email protected]> Date: Fri Sep 12 01:57:59 2025 +0800 ipvs: Defer ip_vs_ftp unregister during netns cleanup [ Upstream commit 134121bfd99a06d44ef5ba15a9beb075297c0821 ] On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free. Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately. Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.") Suggested-by: Julian Anastasov <[email protected]> Signed-off-by: Slavin Liu <[email protected]> Signed-off-by: Julian Anastasov <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Yi <[email protected]> Date: Mon Oct 20 21:42:22 2025 -0400 jbd2: ensure that all ongoing I/O complete before freeing blocks [ Upstream commit 3c652c3a71de1d30d72dc82c3bead8deb48eb749 ] When releasing file system metadata blocks in jbd2_journal_forget(), if this buffer has not yet been checkpointed, it may have already been written back, currently be in the process of being written back, or has not yet written back. jbd2_journal_forget() calls jbd2_journal_try_remove_checkpoint() to check the buffer's status and add it to the current transaction if it has not been written back. This buffer can only be reallocated after the transaction is committed. jbd2_journal_try_remove_checkpoint() attempts to lock the buffer and check its dirty status while holding the buffer lock. If the buffer has already been written back, everything proceeds normally. However, there are two issues. First, the function returns immediately if the buffer is locked by the write-back process. It does not wait for the write-back to complete. Consequently, until the current transaction is committed and the block is reallocated, there is no guarantee that the I/O will complete. This means that ongoing I/O could write stale metadata to the newly allocated block, potentially corrupting data. Second, the function unlocks the buffer as soon as it detects that the buffer is still dirty. If a concurrent write-back occurs immediately after this unlocking and before clear_buffer_dirty() is called in jbd2_journal_forget(), data corruption can theoretically still occur. Although these two issues are unlikely to occur in practice since the undergoing metadata writeback I/O does not take this long to complete, it's better to explicitly ensure that all ongoing I/O operations are completed. Fixes: 597599268e3b ("jbd2: discard dirty data when forgetting an un-journalled buffer") Cc: [email protected] Suggested-by: Jan Kara <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Message-ID: <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Oct 20 12:27:23 2025 -0400 KEYS: trusted_tpm1: Compare HMAC values in constant time [ Upstream commit eed0e3d305530066b4fc5370107cff8ef1a0d229 ] To prevent timing attacks, HMAC value comparison needs to be constant time. Replace the memcmp() with the correct function, crypto_memneq(). [For the Fixes commit I used the commit that introduced the memcmp(). It predates the introduction of crypto_memneq(), but it was still a bug at the time even though a helper function didn't exist yet.] Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> [ changed include from crypto/utils.h to crypto/algapi.h ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon Oct 13 15:30:09 2025 -0400 KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O [ Upstream commit e750f85391286a4c8100275516973324b621a269 ] When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended "recipient") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected] Fixes: 8a76d7f25f8f ("KVM: x86: Add x86 callback for intercept check") Cc: [email protected] Cc: Jim Mattson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> [ is_guest_mode() was open coded ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Sep 24 10:02:07 2025 +0200 lib/genalloc: fix device leak in of_gen_pool_get() commit 1260cbcffa608219fc9188a6cbe9c45a300ef8b5 upstream. Make sure to drop the reference taken when looking up the genpool platform device in of_gen_pool_get() before returning the pool. Note that holding a reference to a device does typically not prevent its devres managed resources from being released so there is no point in keeping the reference. Link: https://lkml.kernel.org/r/[email protected] Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") Signed-off-by: Johan Hovold <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Vladimir Zapolskiy <[email protected]> Cc: <[email protected]> [3.10+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Oct 29 14:00:02 2025 +0100 Linux 5.4.301 Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Alok Tiwari <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed Sep 10 17:16:13 2025 +0200 m68k: bitops: Fix find_*_bit() signatures [ Upstream commit 6d5674090543b89aac0c177d67e5fb32ddc53804 ] The function signatures of the m68k-optimized implementations of the find_{first,next}_{,zero_}bit() helpers do not match the generic variants. Fix this by changing all non-pointer inputs and outputs to "unsigned long", and updating a few local variables. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: "Yury Norov (NVIDIA)" <[email protected]> Link: https://patch.msgid.link/de6919554fbb4cd1427155c6bafbac8a9df822c8.1757517135.git.geert@linux-m68k.org Signed-off-by: Sasha Levin <[email protected]>
Author: Harini T <[email protected]> Date: Mon Sep 29 13:07:21 2025 +0530 mailbox: zynqmp-ipi: Remove dev.parent check in zynqmp_ipi_free_mboxes [ Upstream commit 019e3f4550fc7d319a7fd03eff487255f8e8aecd ] The ipi_mbox->dev.parent check is unreliable proxy for registration status as it fails to protect against probe failures that occur after the parent is assigned but before device_register() completes. device_is_registered() is the canonical and robust method to verify the registration status. Remove ipi_mbox->dev.parent check in zynqmp_ipi_free_mboxes(). Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harini T <[email protected]> Date: Mon Sep 29 13:07:20 2025 +0530 mailbox: zynqmp-ipi: Remove redundant mbox_controller_unregister() call [ Upstream commit 341867f730d3d3bb54491ee64e8b1a0c446656e7 ] The controller is registered using the device-managed function 'devm_mbox_controller_register()'. As documented in mailbox.c, this ensures the devres framework automatically calls mbox_controller_unregister() when device_unregister() is invoked, making the explicit call unnecessary. Remove redundant mbox_controller_unregister() call as device_unregister() handles controller cleanup. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Harini T <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Wed Sep 17 17:59:26 2025 +0800 media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove commit 01e03fb7db419d39e18d6090d4873c1bff103914 upstream. The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug. Fixes: 382c5546d618 ("V4L/DVB (10694): [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards") Cc: [email protected] Signed-off-by: Duoming Zhou <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Oct 17 09:55:39 2025 -0400 media: cx18: Add missing check after DMA map [ Upstream commit 23b53639a793477326fd57ed103823a8ab63084f ] The DMA map functions can fail and should be tested for errors. If the mapping fails, dealloc buffers, and return. Fixes: 1c1e45d17b66 ("V4L/DVB (7786): cx18: new driver for the Conexant CX23418 MPEG encoder chip") Cc: [email protected] Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [ removed pci_map_single() replaced by dma_map_single() ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qianfeng Rong <[email protected]> Date: Wed Aug 27 20:39:10 2025 +0800 media: i2c: mt9v111: fix incorrect type for ret commit bacd713145443dce7764bb2967d30832a95e5ec8 upstream. Change "ret" from unsigned int to int type in mt9v111_calc_frame_rate() to store negative error codes or zero returned by __mt9v111_hw_reset() and other functions. Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. No effect on runtime. Signed-off-by: Qianfeng Rong <[email protected]> Fixes: aab7ed1c3927 ("media: i2c: Add driver for Aptina MT9V111") Cc: [email protected] Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Fri Oct 3 16:43:23 2025 -0400 media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe [ Upstream commit 79d10f4f21a92e459b2276a77be62c59c1502c9d ] The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface. Fixes: 869f38ae07f7 ("media: i2c: tc358743: Fix crash in the probe error path when using polling") Fixes: d32d98642de6 ("[media] Driver for Toshiba TC358743 HDMI to CSI-2 bridge") Cc: [email protected] Signed-off-by: Duoming Zhou <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [ replaced del_timer() instead of timer_delete() ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Fri Oct 3 16:55:36 2025 -0400 media: imon: grab lock earlier in imon_ir_change_protocol() [ Upstream commit 7019553ab850ce1d3f0e512e16d14ab153f91c04 ] Move mutex_trylock() in imon_ir_change_protocol() to the beginning, for memcpy() which modifies ictx->usb_tx_buf should be protected by ictx->lock. Also, verify at the beginning of send_packet() that ictx->lock is held in case send_packet() is by error called from imon_ir_change_protocol() when mutex_trylock() failed due to concurrent requests. Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Stable-dep-of: fa0f61cc1d82 ("media: rc: fix races with imon_disconnect()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Fri Oct 3 16:55:35 2025 -0400 media: imon: reorganize serialization [ Upstream commit db264d4c66c0fe007b5d19fd007707cd0697603d ] Since usb_register_dev() from imon_init_display() from imon_probe() holds minor_rwsem while display_open() which holds driver_lock and ictx->lock is called with minor_rwsem held from usb_open(), holding driver_lock or ictx->lock when calling usb_register_dev() causes circular locking dependency problem. Since usb_deregister_dev() from imon_disconnect() holds minor_rwsem while display_open() which holds driver_lock is called with minor_rwsem held, holding driver_lock when calling usb_deregister_dev() also causes circular locking dependency problem. Sean Young explained that the problem is there are imon devices which have two usb interfaces, even though it is one device. The probe and disconnect function of both usb interfaces can run concurrently. Alan Stern responded that the driver and USB cores guarantee that when an interface is probed, both the interface and its USB device are locked. Ditto for when the disconnect callback gets run. So concurrent probing/ disconnection of multiple interfaces on the same device is not possible. Therefore, we don't need locks for handling race between imon_probe() and imon_disconnect(). But we still need to handle race between display_open() /vfd_write()/lcd_write()/display_close() and imon_disconnect(), for disconnect event can happen while file descriptors are in use. Since "struct file"->private_data is set by display_open(), vfd_write()/ lcd_write()/display_close() can assume that "struct file"->private_data is not NULL even after usb_set_intfdata(interface, NULL) was called. Replace insufficiently held driver_lock with refcount_t based management. Add a boolean flag for recording whether imon_disconnect() was already called. Use RCU for accessing this boolean flag and refcount_t. Since the boolean flag for imon_disconnect() is shared, disconnect event on either intf0 or intf1 affects both interfaces. But I assume that this change does not matter, for usually disconnect event would not happen while interfaces are in use. Link: https://syzkaller.appspot.com/bug?extid=c558267ad910fc494497 Reported-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Tested-by: syzbot <[email protected]> Cc: Alan Stern <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: fa0f61cc1d82 ("media: rc: fix races with imon_disconnect()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ma Ke <[email protected]> Date: Fri Oct 17 19:31:51 2025 -0400 media: lirc: Fix error handling in lirc_register() [ Upstream commit 4f4098c57e139ad972154077fb45c3e3141555dd ] When cdev_device_add() failed, calling put_device() to explicitly release dev->lirc_dev. Otherwise, it could cause the fault of the reference count. Found by code review. Cc: [email protected] Fixes: a6ddd4fecbb0 ("media: lirc: remove last remnants of lirc kapi") Signed-off-by: Ma Ke <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Mon Oct 13 18:47:44 2025 -0400 media: mc: Clear minor number before put device [ Upstream commit 8cfc8cec1b4da88a47c243a11f384baefd092a50 ] The device minor should not be cleared after the device is released. Fixes: 9e14868dc952 ("media: mc: Clear minor number reservation at unregistration time") Cc: [email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=031d0cfd7c362817963f Tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [ moved clear_bit from media_devnode_release callback to media_devnode_unregister before put_device ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Fri Oct 17 10:32:41 2025 -0400 media: pci/ivtv: switch from 'pci_' to 'dma_' API [ Upstream commit 1932dc2f4cf6ac23e48e5fcc24d21adbe35691d1 ] The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below. It has been compile tested. No memory allocation in involved in this patch, so no GFP_ tweak is needed. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: 1069a4fe637d ("media: pci: ivtv: Add missing check after DMA map") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Oct 17 10:32:42 2025 -0400 media: pci: ivtv: Add missing check after DMA map [ Upstream commit 1069a4fe637d0e3e4c163e3f8df9be306cc299b4 ] The DMA map functions can fail and should be tested for errors. If the mapping fails, free blanking_ptr and set it to 0. As 0 is a valid DMA address, use blanking_ptr to test if the DMA address is set. Fixes: 1a0adaf37c30 ("V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder") Cc: [email protected] Signed-off-by: Thomas Fourier <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Flavius Georgescu <[email protected]> Date: Fri Oct 3 16:55:34 2025 -0400 media: rc: Add support for another iMON 0xffdc device [ Upstream commit cf330691668a3bee37b8ac8212709b3ccdd87997 ] The device it's an iMON UltraBay (0x98 in config byte) with LCD, IR and dual-knobs front panel. To work properly the device also require its own key table, and repeat suppression for all buttons. Signed-off-by: Flavius Georgescu <[email protected]> Co-developed-by: Chris Vandomelen <[email protected]> Signed-off-by: Chris Vandomelen <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: fa0f61cc1d82 ("media: rc: fix races with imon_disconnect()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: keliu <[email protected]> Date: Fri Oct 17 19:31:50 2025 -0400 media: rc: Directly use ida_free() [ Upstream commit cd54ff938091d890edf78e6555ec30c63dcd2eb5 ] Use ida_alloc() and ida_free() instead of the deprecated ida_simple_get() and ida_simple_remove(). Signed-off-by: keliu <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: 4f4098c57e13 ("media: lirc: Fix error handling in lirc_register()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Larshin Sergey <[email protected]> Date: Fri Oct 3 16:55:37 2025 -0400 media: rc: fix races with imon_disconnect() [ Upstream commit fa0f61cc1d828178aa921475a9b786e7fbb65ccb ] Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465 CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer. Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1) ... while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAF Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present. Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations. Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=f1a69784f6efe748c3bf Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Cc: [email protected] Signed-off-by: Larshin Sergey <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Shurong <[email protected]> Date: Tue Jun 24 16:27:24 2025 +0800 media: rj54n1cb0c: Fix memleak in rj54n1_probe() [ Upstream commit fda55673ecdabf25f5ecc61b5ab17239257ac252 ] rj54n1_probe() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: f187352dcd45 ("media: i2c: Copy rj54n1cb0c soc_camera sensor driver") Signed-off-by: Zhang Shurong <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Oct 17 19:31:49 2025 -0400 media: s5p-mfc: remove an unused/uninitialized variable [ Upstream commit 7fa37ba25a1dfc084e24ea9acc14bf1fad8af14c ] The s5p_mfc_cmd_args structure in the v6 driver is never used, not initialized to anything other than zero, but as of clang-21 this causes a warning: drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:45:7: error: variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 45 | &h2r_args); | ^~~~~~~~ Just remove this for simplicity. Since the function is also called through a callback, this does require adding a trivial wrapper with the correct prototype. Fixes: f96f3cfa0bb8 ("[media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x") Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Fri Oct 3 20:40:15 2025 -0400 media: tuner: xc5000: Fix use-after-free in xc5000_release [ Upstream commit 40b7a19f321e65789612ebaca966472055dab48c ] The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. Fixes: f7a27ff1fb77 ("[media] xc5000: delay tuner sleep to 5 seconds") Cc: [email protected] Signed-off-by: Duoming Zhou <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: fix typo in Subject: tunner -> tuner] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Fri Oct 3 20:40:14 2025 -0400 media: tunner: xc5000: Refactor firmware load [ Upstream commit 8e1f5da59dd4a1966f859639860b803a7e8b8bfb ] Make sure the firmware is released when we leave xc_load_fw_and_init_tuner() This change makes smatch happy: drivers/media/tuners/xc5000.c:1213 xc_load_fw_and_init_tuner() warn: 'fw' from request_firmware() not released on lines: 1213. Cc: Shuah Khan <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Stable-dep-of: 40b7a19f321e ("media: tuner: xc5000: Fix use-after-free in xc5000_release") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Oct 21 14:55:57 2025 -0400 memory: samsung: exynos-srom: Correct alignment [ Upstream commit 90de1c75d8acd83e9a699b93153307a1e411ef3a ] Align indentation with open parenthesis (or fix existing alignment). Signed-off-by: Krzysztof Kozlowski <[email protected]> Stable-dep-of: 6744085079e7 ("memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhen Ni <[email protected]> Date: Tue Oct 21 14:55:58 2025 -0400 memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe [ Upstream commit 6744085079e785dae5f7a2239456135407c58b25 ] The of_platform_populate() call at the end of the function has a possible failure path, causing a resource leak. Replace of_iomap() with devm_platform_ioremap_resource() to ensure automatic cleanup of srom->reg_base. This issue was detected by smatch static analysis: drivers/memory/samsung/exynos-srom.c:155 exynos_srom_probe()warn: 'srom->reg_base' from of_iomap() not released on lines: 155. Fixes: 8ac2266d8831 ("memory: samsung: exynos-srom: Add support for bank configuration") Cc: [email protected] Signed-off-by: Zhen Ni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Mon Oct 13 20:17:33 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type [ Upstream commit 9eb99c08508714906db078b5efbe075329a3fb06 ] REGCACHE_NONE is the default type of the cache when not provided. Drop unneeded explicit assignment to it. Note, it's defined to 0, and if ever be redefined, it will break literally a lot of the drivers, so it very unlikely to happen. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Stable-dep-of: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Oct 13 20:17:32 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register value [ Upstream commit 70e997e0107e5ed85c1a3ef2adfccbe351c29d71 ] The max_register = 128 setting in the regmap config is not valid. The Intel Dollar Cove TI PMIC has an eeprom unlock register at address 0x88 and a number of EEPROM registers at 0xF?. Increase max_register to 0xff so that these registers can be accessed. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Stable-dep-of: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Oct 13 20:17:34 2025 -0400 mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag [ Upstream commit 64e0d839c589f4f2ecd2e3e5bdb5cee6ba6bade9 ] Testing has shown that reading multiple registers at once (for 10-bit ADC values) does not work. Set the use_single_read regmap_config flag to make regmap split these for us. This should fix temperature opregion accesses done by drivers/acpi/pmic/intel_pmic_chtdc_ti.c and is also necessary for the upcoming drivers for the ADC and battery MFD cells. Fixes: 6bac0606fdba ("mfd: Add support for Cherry Trail Dollar Cove TI PMIC") Cc: [email protected] Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Mon Oct 13 20:20:00 2025 -0400 mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data() [ Upstream commit 1efbee6852f1ff698a9981bd731308dd027189fb ] Commit 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") removed the return value check from the call to gpiochip_add_data() (or rather gpiochip_add() back then and later converted to devres) with no explanation. This function however can still fail, so check the return value and bail-out if it does. Cc: [email protected] Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> [ Use non-devm variants ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Wed Aug 13 00:17:44 2025 +0900 minixfs: Verify inode mode when loading from disk [ Upstream commit 73861970938ad1323eb02bbbc87f6fbd1e5bacca ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Tue Oct 21 20:38:22 2025 +0100 MIPS: Malta: Fix keyboard resource preventing i8042 driver from registering commit bf5570590a981d0659d0808d2d4bcda21b27a2a5 upstream. MIPS Malta platform code registers the PCI southbridge legacy port I/O PS/2 keyboard range as a standard resource marked as busy. It prevents the i8042 driver from registering as it fails to claim the resource in a call to i8042_platform_init(). Consequently PS/2 keyboard and mouse devices cannot be used with this platform. Fix the issue by removing the busy marker from the standard reservation, making the driver register successfully: serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 and the resource show up as expected among the legacy devices: 00000000-00ffffff : MSC PCI I/O 00000000-0000001f : dma1 00000020-00000021 : pic1 00000040-0000005f : timer 00000060-0000006f : keyboard 00000060-0000006f : i8042 00000070-00000077 : rtc0 00000080-0000008f : dma page reg 000000a0-000000a1 : pic2 000000c0-000000df : dma2 [...] If the i8042 driver has not been configured, then the standard resource will remain there preventing any conflicting dynamic assignment of this PCI port I/O address range. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maciej W. Rozycki <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Acked-by: Thomas Bogendoerfer <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Colin Ian King <[email protected]> Date: Tue Sep 2 12:37:12 2025 +0100 misc: genwqe: Fix incorrect cmd field being reported in error [ Upstream commit 6b26053819dccc664120e07c56f107fb6f72f3fa ] There is a dev_err message that is reporting the value of cmd->asiv_length when it should be reporting cmd->asv_length instead. Fix this. Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue") Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Shi <[email protected]> Date: Mon Sep 29 13:24:02 2025 -0700 mm: hugetlb: avoid soft lockup when mprotect to large memory area commit f52ce0ea90c83a28904c7cc203a70e6434adfecb upstream. When calling mprotect() to a large hugetlb memory area in our customer's workload (~300GB hugetlb memory), soft lockup was observed: watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916] CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mte_clear_page_tags+0x14/0x24 lr : mte_sync_tags+0x1c0/0x240 sp : ffff80003150bb80 x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000 x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458 x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000 x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000 x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000 Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8 Soft lockup is not triggered with THP or base page because there is cond_resched() called for each PMD size. Although the soft lockup was triggered by MTE, it should be not MTE specific. The other processing which takes long time in the loop may trigger soft lockup too. So add cond_resched() for hugetlb to avoid soft lockup. Link: https://lkml.kernel.org/r/[email protected] Fixes: 8f860591ffb2 ("[PATCH] Enable mprotect on huge pages") Signed-off-by: Yang Shi <[email protected]> Tested-by: Carl Worth <[email protected]> Reviewed-by: Christoph Lameter (Ampere) <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Oscar Salvador <[email protected]> Reviewed-by: Anshuman Khandual <[email protected]> Reviewed-by: Dev Jain <[email protected]> Cc: Muchun Song <[email protected]> Cc: Will Deacon <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rex Chen <[email protected]> Date: Mon Jul 28 17:22:29 2025 +0900 mmc: core: SPI mode remove cmd7 commit fec40f44afdabcbc4a7748e4278f30737b54bb1a upstream. SPI mode doesn't support cmd7, so remove it in mmc_sdio_alive() and confirm if sdio is active by checking CCCR register value is available or not. Signed-off-by: Rex Chen <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linus Walleij <[email protected]> Date: Tue Sep 16 18:07:37 2025 +0200 mtd: rawnand: fsmc: Default to autodetect buswidth commit b8df622cf7f6808c85764e681847150ed6d85f3d upstream. If you don't specify buswidth 2 (16 bits) in the device tree, FSMC doesn't even probe anymore: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro 10100000.flash nand: bus width 8 instead of 16 bits nand: No NAND device found fsmc-nand 10100000.flash: probe with driver fsmc-nand failed with error -22 With this patch to use autodetection unless buswidth is specified, the device is properly detected again: fsmc-nand 10100000.flash: FSMC device partno 090, manufacturer 80, revision 00, config 00 nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 nand: ST Micro NAND 128MiB 1,8V 16-bit nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme Scanning device for bad blocks I don't know where or how this happened, I think some change in the nand core. Cc: [email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nalivayko Sergey <[email protected]> Date: Mon Oct 13 13:36:38 2025 -0400 net/9p: fix double req put in p9_fd_cancelled [ Upstream commit 674b56aa57f9379854cb6798c3bbcef7e7b51ab7 ] Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: <TASK> p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: afd8d6541155 ("9P: Add cancelled() to the transport functions.") Cc: [email protected] Signed-off-by: Nalivayko Sergey <[email protected]> Message-ID: <[email protected]> [updated the check from status == RECV || status == ERROR to status != SENT] Signed-off-by: Dominique Martinet <[email protected]> [ replaced m->req_lock with client->lock ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Safonov <[email protected]> Date: Thu Oct 9 16:02:19 2025 +0100 net/ip6_tunnel: Prevent perpetual tunnel growth [ Upstream commit 21f4d45eba0b2dcae5dbc9e5e0ad08735c993f16 ] Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer. Fixes: 8eb30be0352d ("ipv6: Create ip6_tnl_xmit") Cc: Florian Westphal <[email protected]> Cc: Francesco Ruggeri <[email protected]> Signed-off-by: Dmitry Safonov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Sep 30 15:25:01 2025 +0300 net/mlx4: prevent potential use after free in mlx4_en_do_uc_filter() [ Upstream commit 4f0d91ba72811fd5dd577bcdccd7fed649aae62c ] Print "entry->mac" before freeing "entry". The "entry" pointer is freed with kfree_rcu() so it's unlikely that we would trigger this in real life, but it's safer to re-order it. Fixes: cc5387f7346a ("net/mlx4_en: Add unicast MAC filtering") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-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: Alexandr Sapozhnikov <[email protected]> Date: Thu Oct 2 12:14:47 2025 +0300 net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() [ Upstream commit 2f3119686ef50319490ccaec81a575973da98815 ] If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function. Signed-off-by: Alexandr Sapozhnikov <[email protected]> Acked-by: Xin Long <[email protected]> Fixes: 30f6ebf65bc4 ("sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:56 2022 +0300 net: add ndo_fdb_del_bulk [ Upstream commit 1306d5362a591493a2d07f685ed2cc480dcda320 ] Add a new netdev op called ndo_fdb_del_bulk, it will be later used for driver-specific bulk delete implementation dispatched from rtnetlink. The first user will be the bridge, we need it to signal to rtnetlink from the driver that we support bulk delete operation (NLM_F_BULK). Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Tonghao Zhang <[email protected]> Date: Tue Oct 21 13:09:33 2025 +0800 net: bonding: fix possible peer notify event loss or dup issue commit 10843e1492e474c02b91314963161731fa92af91 upstream. If the send_peer_notif counter and the peer event notify are not synchronized. It may cause problems such as the loss or dup of peer notify event. Before this patch: - If should_notify_peers is true and the lock for send_peer_notif-- fails, peer event may be sent again in next mii_monitor loop, because should_notify_peers is still true. - If should_notify_peers is true and the lock for send_peer_notif-- succeeded, but the lock for peer event fails, the peer event will be lost. This patch locks the RTNL for send_peer_notif, events, and commit simultaneously. Fixes: 07a4ddec3ce9 ("bonding: add an option to specify a delay between peer notifications") Cc: Jay Vosburgh <[email protected]> Cc: Andrew Lunn <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Hangbin Liu <[email protected]> Cc: Nikolay Aleksandrov <[email protected]> Cc: Vincent Bernat <[email protected]> Cc: <[email protected]> Signed-off-by: Tonghao Zhang <[email protected]> Acked-by: Jay Vosburgh <[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: Christophe JAILLET <[email protected]> Date: Sun Sep 13 08:14:17 2020 +0200 net: dl2k: switch from 'pci_' to 'dma_' API [ Upstream commit b49db89e9697ddfa7fbe7387e176072ee2feb2db ] The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'rio_probe1()' GFP_KERNEL can be used because it is a probe function and no lock is taken in the between. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 65946eac6d88 ("net: dlink: handle dma_map_single() failure properly") Signed-off-by: Sasha Levin <[email protected]>
Author: Yeounsu Moon <[email protected]> Date: Fri Oct 10 00:57:16 2025 +0900 net: dlink: handle dma_map_single() failure properly [ Upstream commit 65946eac6d888d50ae527c4e5c237dbe5cc3a2f2 ] There is no error handling for `dma_map_single()` failures. Add error handling by checking `dma_mapping_error()` and freeing the `skb` using `dev_kfree_skb()` (process context) when it fails. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yeounsu Moon <[email protected]> Tested-on: D-Link DGE-550T Rev-A3 Suggested-by: Simon Horman <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kohei Enju <[email protected]> Date: Mon Sep 29 14:02:22 2025 +0900 net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable [ Upstream commit f017156aea60db8720e47591ed1e041993381ad2 ] In EC2 instances where the RSS hash key is not configurable, ethtool shows bogus RSS hash key since ena_get_rxfh_key_size() unconditionally returns ENA_HASH_KEY_SIZE. Commit 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported") added proper handling for devices that don't support RSS hash key configuration, but ena_get_rxfh_key_size() has been unchanged. When the RSS hash key is not configurable, return 0 instead of ENA_HASH_KEY_SIZE to clarify getting the value is not supported. Tested on m5 instance families. Without patch: # ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 With patch: # ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: Operation not supported Fixes: 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported") Signed-off-by: Kohei Enju <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wei Fang <[email protected]> Date: Thu Oct 16 16:01:31 2025 +0800 net: enetc: correct the value of ENETC_RXB_TRUESIZE [ Upstream commit e59bc32df2e989f034623a580e30a2a72af33b3f ] The ENETC RX ring uses the page halves flipping mechanism, each page is split into two halves for the RX ring to use. And ENETC_RXB_TRUESIZE is defined to 2048 to indicate the size of half a page. However, the page size is configurable, for ARM64 platform, PAGE_SIZE is default to 4K, but it could be configured to 16K or 64K. When PAGE_SIZE is set to 16K or 64K, ENETC_RXB_TRUESIZE is not correct, and the RX ring will always use the first half of the page. This is not consistent with the description in the relevant kernel doc and commit messages. This issue is invisible in most cases, but if users want to increase PAGE_SIZE to receive a Jumbo frame with a single buffer for some use cases, it will not work as expected, because the buffer size of each RX BD is fixed to 2048 bytes. Based on the above two points, we expect to correct ENETC_RXB_TRUESIZE to (PAGE_SIZE >> 1), as described in the comment. Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Claudiu Manoil <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Erick Karanja <[email protected]> Date: Thu Oct 2 20:46:17 2025 +0300 net: fsl_pq_mdio: Fix device node reference leak in fsl_pq_mdio_probe [ Upstream commit 521405cb54cd2812bbb6dedd5afc14bca1e7e98a ] Add missing of_node_put call to release device node tbi obtained via for_each_child_of_node. Fixes: afae5ad78b342 ("net/fsl_pq_mdio: streamline probing of MDIO nodes") Signed-off-by: Erick Karanja <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:54 2022 +0300 net: netlink: add NLM_F_BULK delete request modifier [ Upstream commit 545528d788556c724eeb5400757f828ef27782a8 ] Add a new delete request modifier called NLM_F_BULK which, when supported, would cause the request to delete multiple objects. The flag is a convenient way to signal that a multiple delete operation is requested which can be gradually added to different delete requests. In order to make sure older kernels will error out if the operation is not supported instead of doing something unintended we have to break a required condition when implementing support for this flag, f.e. for neighbors we will omit the mandatory mac address attribute. Initially it will be used to add flush with filtering support for bridge fdbs, but it also opens the door to add similar support to others. Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Lad Prabhakar <[email protected]> Date: Fri Oct 17 16:18:30 2025 +0100 net: ravb: Ensure memory write completes before ringing TX doorbell commit 706136c5723626fcde8dd8f598a4dcd251e24927 upstream. Add a final dma_wmb() barrier before triggering the transmit request (TCCR_TSRQ) to ensure all descriptor and buffer writes are visible to the DMA engine. According to the hardware manual, a read-back operation is required before writing to the doorbell register to guarantee completion of previous writes. Instead of performing a dummy read, a dma_wmb() is used to both enforce the same ordering semantics on the CPU side and also to ensure completion of writes. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Cc: [email protected] Co-developed-by: Fabrizio Castro <[email protected]> Signed-off-by: Fabrizio Castro <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Niklas Söderlund <[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: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:55 2022 +0300 net: rtnetlink: add bulk delete support flag [ Upstream commit a6cec0bcd34264be8887791594be793b3f12719f ] Add a new rtnl flag (RTNL_FLAG_BULK_DEL_SUPPORTED) which is used to verify that the delete operation allows bulk object deletion. Also emit a warning if anyone tries to set it for non-delete kind. Suggested-by: David Ahern <[email protected]> Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:52 2022 +0300 net: rtnetlink: add helper to extract msg type's kind [ Upstream commit 2e9ea3e30f696fd438319c07836422bb0bbb4608 ] Add a helper which extracts the msg type's kind using the kind mask (0x3). Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:51 2022 +0300 net: rtnetlink: add msg kind names [ Upstream commit 12dc5c2cb7b269c5a1c6d02844f40bfce942a7a6 ] Add rtnl kind names instead of using raw values. We'll need to check for DEL kind later to validate bulk flag support. Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:57 2022 +0300 net: rtnetlink: add NLM_F_BULK support to rtnl_fdb_del [ Upstream commit 9e83425993f38bb89e0ea07849ba0039a748e85b ] When NLM_F_BULK is specified in a fdb del message we need to handle it differently. First since this is a new call we can strictly validate the passed attributes, at first only ifindex and vlan are allowed as these will be the initially supported filter attributes, any other attribute is rejected. The mac address is no longer mandatory, but we use it to error out in older kernels because it cannot be specified with bulk request (the attribute is not allowed) and then we have to dispatch the call to ndo_fdb_del_bulk if the device supports it. The del bulk callback can do further validation of the attributes if necessary. Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Zhengchao Shao <[email protected]> Date: Mon Aug 15 10:46:29 2022 +0800 net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg commit 5b22f62724a0a09e00d301abf5b57b0c12be8a16 upstream. When bulk delete command is received in the rtnetlink_rcv_msg function, if bulk delete is not supported, module_put is not called to release the reference counting. As a result, module reference count is leaked. Fixes: a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag") Signed-off-by: Zhengchao Shao <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Colin Ian King <[email protected]> Date: Sat Apr 25 12:28:14 2020 +0100 net: rtnetlink: remove redundant assignment to variable err [ Upstream commit 7d3118016787b5c05da94b3bcdb96c9d6ff82c44 ] The variable err is being initializeed with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Aleksandrov <[email protected]> Date: Wed Apr 13 13:51:53 2022 +0300 net: rtnetlink: use BIT for flag values [ Upstream commit 0569e31f1bc2f50613ba4c219f3ecc0d1174d841 ] Use BIT to define flag values. Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: bf29555f5bdc ("rtnetlink: Allow deleting FDB entries in user namespace") Signed-off-by: Sasha Levin <[email protected]>
Author: I Viswanath <[email protected]> Date: Wed Sep 24 19:13:50 2025 +0530 net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast [ Upstream commit 958baf5eaee394e5fd976979b0791a875f14a179 ] syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb. This is the sequence of events that leads to the warning: rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); } rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done } rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission } rtl8150_set_multicast being the ndo_set_rx_mode callback should not be calling netif_stop_queue and notif_start_queue as these handle TX queue synchronization. The net core function dev_set_rx_mode handles the synchronization for rtl8150_set_multicast making it safe to remove these locks. Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=78cae3f37c62ad092caa Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Michal Pecio <[email protected]> Signed-off-by: I Viswanath <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Pecio <[email protected]> Date: Tue Oct 14 20:35:28 2025 +0200 net: usb: rtl8150: Fix frame padding commit 75cea9860aa6b2350d90a8d78fed114d27c7eca2 upstream. TX frames aren't padded and unknown memory is sent into the ether. Theoretically, it isn't even guaranteed that the extra memory exists and can be sent out, which could cause further problems. In practice, I found that plenty of tailroom exists in the skb itself (in my test with ping at least) and skb_padto() easily succeeds, so use it here. In the event of -ENOMEM drop the frame like other drivers do. The use of one more padding byte instead of a USB zero-length packet is retained to avoid regression. I have a dodgy Etron xHCI controller which doesn't seem to support sending ZLPs at all. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Michal Pecio <[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: Greg Kroah-Hartman <[email protected]>
Author: Zhen Ni <[email protected]> Date: Fri Aug 29 16:36:21 2025 +0800 netfilter: ipset: Remove unused htable_bits in macro ahash_region [ Upstream commit ba941796d7cd1e81f51eed145dad1b47240ff420 ] Since the ahash_region() macro was redefined to calculate the region index solely from HTABLE_REGION_BITS, the htable_bits parameter became unused. Remove the unused htable_bits argument and its call sites, simplifying the code without changing semantics. Fixes: 8478a729c046 ("netfilter: ipset: fix region locking in hash types") Signed-off-by: Zhen Ni <[email protected]> Reviewed-by: Phil Sutter <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kohei Enju <[email protected]> Date: Mon Sep 29 14:42:15 2025 +0900 nfp: fix RSS hash key size when RSS is not supported [ Upstream commit 8425161ac1204d2185e0a10f5ae652bae75d2451 ] The nfp_net_get_rxfh_key_size() function returns -EOPNOTSUPP when devices don't support RSS, and callers treat the negative value as a large positive value since the return type is u32. Return 0 when devices don't support RSS, aligning with the ethtool interface .get_rxfh_key_size() that requires returning 0 in such cases. Fixes: 9ff304bfaf58 ("nfp: add support for reporting CRC32 hash function") Signed-off-by: Kohei Enju <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Mon Oct 20 21:10:56 2025 -0400 NFSD: Define a proc_layoutcommit for the FlexFiles layout type [ Upstream commit 4b47a8601b71ad98833b447d465592d847b4dc77 ] Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout. Reported-by: Robert Morris <[email protected]> Closes: https://lore.kernel.org/linux-nfs/[email protected]/T/#t Cc: Thomas Haynes <[email protected]> Cc: [email protected] Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Signed-off-by: Chuck Lever <[email protected]> [ removed struct svc_rqst parameter from nfsd4_ff_proc_layoutcommit ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergey Bashirov <[email protected]> Date: Mon Oct 20 08:57:40 2025 -0400 NFSD: Fix last write offset handling in layoutcommit [ Upstream commit d68886bae76a4b9b3484d23e5b7df086f940fa38 ] The data type of loca_last_write_offset is newoffset4 and is switched on a boolean value, no_newoffset, that indicates if a previous write occurred or not. If no_newoffset is FALSE, an offset is not given. This means that client does not try to update the file size. Thus, server should not try to calculate new file size and check if it fits into the segment range. See RFC 8881, section 12.5.4.2. Sometimes the current incorrect logic may cause clients to hang when trying to sync an inode. If layoutcommit fails, the client marks the inode as dirty again. Fixes: 9cf514ccfacb ("nfsd: implement pNFS operations") Cc: [email protected] Co-developed-by: Konstantin Evtushenko <[email protected]> Signed-off-by: Konstantin Evtushenko <[email protected]> Signed-off-by: Sergey Bashirov <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> [ replaced inode_get_mtime() with inode->i_mtime and removed rqstp parameter from proc_layoutcommit() ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergey Bashirov <[email protected]> Date: Mon Oct 20 08:57:39 2025 -0400 NFSD: Minor cleanup in layoutcommit processing [ Upstream commit 274365a51d88658fb51cca637ba579034e90a799 ] Remove dprintk in nfsd4_layoutcommit. These are not needed in day to day usage, and the information is also available in Wireshark when capturing NFS traffic. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Sergey Bashirov <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Stable-dep-of: d68886bae76a ("NFSD: Fix last write offset handling in layoutcommit") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Thu Aug 21 16:31:46 2025 -0400 nfsd: nfserr_jukebox in nlm_fopen should lead to a retry commit a082e4b4d08a4a0e656d90c2c05da85f23e6d0c9 upstream. When v3 NLM request finds a conflicting delegation, it triggers a delegation recall and nfsd_open fails with EAGAIN. nfsd_open then translates EAGAIN into nfserr_jukebox. In nlm_fopen, instead of returning nlm_failed for when there is a conflicting delegation, drop this NLM request so that the client retries. Once delegation is recalled and if a local lock is claimed, a retry would lead to nfsd returning a nlm_lck_blocked error or a successful nlm lock. Fixes: d343fce148a4 ("[PATCH] knfsd: Allow lockd to drop replies as appropriate") Cc: [email protected] # v6.6 Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anthony Iliopoulos <[email protected]> Date: Wed Aug 13 11:00:46 2025 +0200 NFSv4.1: fix backchannel max_resp_sz verification check [ Upstream commit 191512355e520dfc45c8bc3b56d4de59c3ade33e ] When the client max_resp_sz is larger than what the server encodes in its reply, the nfs4_verify_back_channel_attrs() check fails and this causes nfs4_proc_create_session() to fail, in cases where the client page size is larger than that of the server and the server does not want to negotiate upwards. While this is not a problem with the linux nfs server that will reflect the proposed value in its reply irrespective of the local page size, other nfs server implementations may insist on their own max_resp_sz value, which could be smaller. Fix this by accepting smaller max_resp_sz values from the server, as this does not violate the protocol. The server is allowed to decrease but not increase proposed the size, and as such values smaller than the client-proposed ones are valid. Fixes: 43c2e885be25 ("nfs4: fix channel attribute sanity-checks") Signed-off-by: Anthony Iliopoulos <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Thu Oct 9 21:19:03 2025 +0530 ocfs2: clear extent cache after moving/defragmenting extents commit 78a63493f8e352296dbc7cb7b3f4973105e8679e upstream. The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk. Link: https://lore.kernel.org/all/[email protected]/T/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 53069d4e7695 ("Ocfs2/move_extents: move/defrag extents within a certain range.") Signed-off-by: Deepanshu Kartikey <[email protected]> Reported-by: [email protected] Tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?id=2959889e1f6e216585ce522f7e8bc002b46ad9e7 Reviewed-by: Mark Fasheh <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Sep 23 14:26:07 2025 +0300 ocfs2: fix double free in user_cluster_connect() [ Upstream commit 8f45f089337d924db24397f55697cda0e6960516 ] user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free. Link: https://lkml.kernel.org/r/[email protected] Fixes: c994c2ebdbbc ("ocfs2: use the new DLM operation callbacks while requesting new lockspace") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Reviewed-by: Goldwyn Rodrigues <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiao Liang <[email protected]> Date: Mon Oct 20 11:41:31 2025 -0400 padata: Reset next CPU when reorder sequence wraps around [ Upstream commit 501302d5cee0d8e8ec2c4a5919c37e0df9abc99b ] When seq_nr wraps around, the next reorder job with seq 0 is hashed to the first CPU in padata_do_serial(). Correspondingly, need reset pd->cpu to the first one when pd->processed wraps around. Otherwise, if the number of used CPUs is not a power of 2, padata_find_next() will be checking a wrong list, hence deadlock. Fixes: 6fc4dbcf0276 ("padata: Replace delayed timer with immediate workqueue in padata_reorder") Cc: <[email protected]> Signed-off-by: Xiao Liang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> [ moved from padata_reorder() to padata_find_next() function ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sam James <[email protected]> Date: Wed Oct 1 23:58:40 2025 +0100 parisc: don't reference obsolete termio struct for TC* constants commit 8ec5a066f88f89bd52094ba18792b34c49dcd55a upstream. Similar in nature to ab107276607af90b13a5994997e19b7b9731e251. glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Co-authored-by: Stian Halseth <[email protected]> Cc: [email protected] Signed-off-by: Sam James <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Thu Aug 7 15:55:38 2025 +0200 PCI/AER: Fix missing uevent on recovery when a reset is requested commit bbf7d0468d0da71d76cc6ec9bc8a224325d07b6b upstream. Since commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") AER uses the result of error_detected() as parameter to pci_uevent_ers(). As pci_uevent_ers() however does not handle PCI_ERS_RESULT_NEED_RESET this results in a missing uevent for the beginning of recovery if drivers request a reset. Fix this by treating PCI_ERS_RESULT_NEED_RESET as beginning recovery. Fixes: 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niklas Schnelle <[email protected]> Date: Tue Aug 26 10:52:08 2025 +0200 PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV commit 05703271c3cdcc0f2a8cf6ebdc45892b8ca83520 upstream. Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking. Fixes: 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Reviewed-by: Farhan Ali <[email protected]> Reviewed-by: Julian Ruess <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Siddharth Vadapalli <[email protected]> Date: Fri Sep 12 15:37:58 2025 +0530 PCI: keystone: Use devm_request_irq() to free "ks-pcie-error-irq" on exit commit e51d05f523e43ce5d2bad957943a2b14f68078cd upstream. Commit under Fixes introduced the IRQ handler for "ks-pcie-error-irq". The interrupt is acquired using "request_irq()" but is never freed if the driver exits due to an error. Although the section in the driver that invokes "request_irq()" has moved around over time, the issue hasn't been addressed until now. Fix this by using "devm_request_irq()" which automatically frees the interrupt if the driver exits. Fixes: 025dd3daeda7 ("PCI: keystone: Add error IRQ handler") Reported-by: Jiri Slaby <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Signed-off-by: Siddharth Vadapalli <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Tue Aug 19 08:04:08 2025 -0700 PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation [ Upstream commit e1a8805e5d263453ad76a4f50ab3b1c18ea07560 ] Fix incorrect argument order in devm_kcalloc() when allocating port->phys. The original call used sizeof(phy) as the number of elements and port->lanes as the element size, which is reversed. While this happens to produce the correct total allocation size with current pointer size and lane counts, the argument order is wrong. Fixes: 6fe7c187e026 ("PCI: tegra: Support per-lane PHYs") Signed-off-by: Alok Tiwari <[email protected]> [mani: added Fixes tag] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Fri Aug 8 14:24:40 2025 +0100 perf session: Fix handling when buffer exceeds 2 GiB [ Upstream commit c17dda8013495d8132c976cbf349be9949d0fbd1 ] If a user specifies an AUX buffer larger than 2 GiB, the returned size may exceed 0x80000000. Since the err variable is defined as a signed 32-bit integer, such a value overflows and becomes negative. As a result, the perf record command reports an error: 0x146e8 [0x30]: failed to process type: 71 [Unknown error 183711232] Change the type of the err variable to a signed 64-bit integer to accommodate large buffer sizes correctly. Fixes: d5652d865ea734a1 ("perf session: Add ability to skip 4GiB or more") Reported-by: Tamas Zsoldos <[email protected]> Signed-off-by: Leo Yan <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: hupu <[email protected]> Date: Wed Sep 10 16:16:55 2025 +0800 perf subcmd: avoid crash in exclude_cmds when excludes is empty [ Upstream commit a5edf3550f4260504b7e0ab3d40d13ffe924b773 ] When cross-compiling the perf tool for ARM64, `perf help` may crash with the following assertion failure: help.c:122: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. This happens when the perf binary is not named exactly "perf" or when multiple "perf-*" binaries exist in the same directory. In such cases, the `excludes` command list can be empty, which leads to the final assertion in exclude_cmds() being triggered. Add a simple guard at the beginning of exclude_cmds() to return early if excludes->cnt is zero, preventing the crash. Signed-off-by: hupu <[email protected]> Reported-by: Guilherme Amadio <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yunseong Kim <[email protected]> Date: Fri Aug 22 16:25:08 2025 +0000 perf util: Fix compression checks returning -1 as bool [ Upstream commit 43fa1141e2c1af79c91aaa4df03e436c415a6fc3 ] The lzma_is_compressed and gzip_is_compressed functions are declared to return a "bool" type, but in case of an error (e.g., file open failure), they incorrectly returned -1. A bool type is a boolean value that is either true or false. Returning -1 for a bool return type can lead to unexpected behavior and may violate strict type-checking in some compilers. Fix the return value to be false in error cases, ensuring the function adheres to its declared return type improves for preventing potential bugs related to type mismatch. Fixes: 4b57fd44b61beb51 ("perf tools: Add lzma_is_compressed function") Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Yunseong Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Stephen Brennan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Wed Sep 17 18:41:39 2025 +0100 perf: arm_spe: Prevent overflow in PERF_IDX2OFF() [ Upstream commit a29fea30dd93da16652930162b177941abd8c75e ] Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2 GiB). Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Leo Yan <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: gaoxiang17 <[email protected]> Date: Sat Aug 2 10:21:23 2025 +0800 pid: Add a judgment for ns null in pid_nr_ns [ Upstream commit 006568ab4c5ca2309ceb36fa553e390b4aa9c0c7 ] __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Signed-off-by: gaoxiang17 <[email protected]> Link: https://lore.kernel.org/[email protected] Reviewed-by: Baoquan He <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bartosz Golaszewski <[email protected]> Date: Tue Sep 2 13:59:10 2025 +0200 pinctrl: check the return value of pinmux_ops::get_function_name() commit 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 upstream. While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions. Cc: [email protected] Tested-by: Neil Armstrong <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Da Xue <[email protected]> Date: Thu Aug 21 19:33:34 2025 -0400 pinctrl: meson-gxl: add missing i2c_d pinmux [ Upstream commit d8c2a9edd181f0cc4a66eec954b3d8f6a1d954a7 ] Amlogic GXL has 4 I2C attached to gpio-periphs. I2C_D is on GPIOX_10/11. Add the relevant func 3 pinmux per the datasheet for S805X/S905X/S905D. Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions") Signed-off-by: Da Xue <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Liang <[email protected]> Date: Sat Aug 30 15:50:23 2025 +0800 pps: fix warning in pps_register_cdev when register device fail [ Upstream commit b0531cdba5029f897da5156815e3bdafe1e9b88d ] Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error handling in __video_register_device()"), the release hook should be set before device_register(). Otherwise, when device_register() return error and put_device() try to callback the release function, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: <TASK> kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Before commit c79a39dc8d06 ("pps: Fix a use-after-free"), pps_register_cdev() call device_create() to create pps->dev, which will init dev->release to device_create_release(). Now the comment is outdated, just remove it. Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed in pps_register_source() to avoid a double free in the failure case. Link: https://lore.kernel.org/all/[email protected]/ Fixes: c79a39dc8d06 ("pps: Fix a use-after-free") Signed-off-by: Wang Liang <[email protected]> Reviewed-By: Calvin Owens <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jisheng Zhang <[email protected]> Date: Tue Aug 19 19:42:24 2025 +0800 pwm: berlin: Fix wrong register in suspend/resume commit 3a4b9d027e4061766f618292df91760ea64a1fcc upstream. The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume. Fixes: bbf0722c1c66 ("pwm: berlin: Add suspend/resume support") Signed-off-by: Jisheng Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] [ukleinek: backport to 5.10] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Aug 11 18:01:02 2025 +0200 pwm: tiehrpwm: Fix corner case in clock divisor calculation [ Upstream commit 00f83f0e07e44e2f1fb94b223e77ab7b18ee2d7d ] The function set_prescale_div() is responsible for calculating the clock divisor settings such that the input clock rate is divided down such that the required period length is at most 0x10000 clock ticks. If period_cycles is an integer multiple of 0x10000, the divisor period_cycles / 0x10000 is good enough. So round up in the calculation of the required divisor and compare it using >= instead of >. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/85488616d7bfcd9c32717651d0be7e330e761b9c.1754927682.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Parav Pandit <[email protected]> Date: Tue Sep 16 14:11:01 2025 +0300 RDMA/core: Resolve MAC of next-hop device without ARP support [ Upstream commit 200651b9b8aadfbbec852f0e5d042d9abe75e2ab ] Currently, if the next-hop netdevice does not support ARP resolution, the destination MAC address is silently set to zero without reporting an error. This leads to incorrect behavior and may result in packet transmission failures. Fix this by deferring MAC resolution to the IP stack via neighbour lookup, allowing proper resolution or error reporting as appropriate. Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)") Signed-off-by: Parav Pandit <[email protected]> Reviewed-by: Vlad Dumitrescu <[email protected]> Signed-off-by: Edward Srouji <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bernard Metzler <[email protected]> Date: Tue Sep 23 16:45:36 2025 +0200 RDMA/siw: Always report immediate post SQ errors [ Upstream commit fdd0fe94d68649322e391c5c27dd9f436b4e955e ] In siw_post_send(), any immediate error encountered during processing of the work request list must be reported to the caller, even if previous work requests in that list were just accepted and added to the send queue. Not reporting those errors confuses the caller, which would wait indefinitely for the failing and potentially subsequently aborted work requests completion. This fixes a case where immediate errors were overwritten by subsequent code in siw_post_send(). Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Link: https://patch.msgid.link/r/[email protected] Suggested-by: Stefan Metzmacher <[email protected]> Signed-off-by: Bernard Metzler <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed Aug 13 15:07:18 2025 +0200 regmap: Remove superfluous check for !config in __regmap_init() [ Upstream commit 5c36b86d2bf68fbcad16169983ef7ee8c537db59 ] The first thing __regmap_init() do is check if config is non-NULL, so there is no need to check for this again later. Fixes: d77e745613680c54 ("regmap: Add bulk read/write callbacks into regmap_config") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/a154d9db0f290dda96b48bd817eb743773e846e1.1755090330.git.geert+renesas@glider.be Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Wed Aug 20 18:02:33 2025 +0200 remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice [ Upstream commit 110be46f5afe27b66caa2d12473a84cd397b1925 ] enable_irq() and disable_irq() are reference counted, so we must make sure that each enable_irq() is always paired with a single disable_irq(). If we call disable_irq() twice followed by just a single enable_irq(), the IRQ will remain disabled forever. For the error handling path in qcom_q6v5_wait_for_start(), disable_irq() will end up being called twice, because disable_irq() also happens in qcom_q6v5_unprepare() when rolling back the call to qcom_q6v5_prepare(). Fix this by dropping disable_irq() in qcom_q6v5_wait_for_start(). Since qcom_q6v5_prepare() is the function that calls enable_irq(), it makes more sense to have the rollback handled always by qcom_q6v5_unprepare(). Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Sat Oct 18 14:27:15 2025 +0200 Revert "cpuidle: menu: Avoid discarding useful information" commit 10fad4012234a7dea621ae17c0c9486824f645a0 upstream. It is reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information") led to a performance regression on Intel Jasper Lake systems because it reduced the time spent by CPUs in idle state C7 which is correlated to the maximum frequency the CPUs can get to because of an average running power limit [1]. Before that commit, get_typical_interval() would have returned UINT_MAX whenever it had been unable to make a high-confidence prediction which had led to selecting the deepest available idle state too often and both power and performance had been inadequate as a result of that on some systems. However, this had not been a problem on systems with relatively aggressive average running power limits, like the Jasper Lake systems in question, because on those systems it was compensated by the ability to run CPUs faster. It was addressed by causing get_typical_interval() to return a number based on the recent idle duration information available to it even if it could not make a high-confidence prediction, but that clearly did not take the possible correlation between idle power and available CPU capacity into account. For this reason, revert most of the changes made by commit 85975daeaa4d, except for one cosmetic cleanup, and add a comment explaining the rationale for returning UINT_MAX from get_typical_interval() when it is unable to make a high-confidence prediction. Fixes: 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information") Closes: https://lore.kernel.org/linux-pm/36iykr223vmcfsoysexug6s274nq2oimcu55ybn6ww4il3g3cv@cohflgdbpnq7/ [1] Reported-by: Sergey Senozhatsky <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Mon Sep 29 11:15:29 2025 -0700 Revert "net/mlx5e: Update and set Xon/Xoff upon MTU set" [ Upstream commit 6f5dacf88a32b3fd8b52c8ea781bf188c42aaa95 ] This reverts commit ceddedc969f0532b7c62ca971ee50d519d2bc0cb. Commit in question breaks the mapping of PGs to pools for some SKUs. Specifically multi-host NICs seem to be shipped with a custom buffer configuration which maps the lossy PG to pool 4. But the bad commit overrides this with pool 0 which does not have sufficient buffer space reserved. Resulting in ~40% packet loss. The commit also breaks BMC / OOB connection completely (100% packet loss). Revert, similarly to commit 3fbfe251cc9f ("Revert "net/mlx5e: Update and set Xon/Xoff upon port speed set""). The breakage is exactly the same, the only difference is that quoted commit would break the NIC immediately on boot, and the currently reverted commit only when MTU is changed. Note: "good" kernels do not restore the configuration, so downgrade isn't enough to recover machines. A NIC power cycle seems to be necessary to return to a healthy state (or overriding the relevant registers using a custom patch). Fixes: ceddedc969f0 ("net/mlx5e: Update and set Xon/Xoff upon MTU set") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Aug 19 15:29:44 2025 -0700 rseq/selftests: Use weak symbol reference, not definition, to link with glibc commit a001cd248ab244633c5fabe4f7c707e13fc1d1cc upstream. Add "extern" to the glibc-defined weak rseq symbols to convert the rseq selftest's usage from weak symbol definitions to weak symbol _references_. Effectively re-defining the glibc symbols wreaks havoc when building with -fno-common, e.g. generates segfaults when running multi-threaded programs, as dynamically linked applications end up with multiple versions of the symbols. Building with -fcommon, which until recently has the been the default for GCC and clang, papers over the bug by allowing the linker to resolve the weak/tentative definition to glibc's "real" definition. Note, the symbol itself (or rather its address), not the value of the symbol, is set to 0/NULL for unresolved weak symbol references, as the symbol doesn't exist and thus can't have a value. Check for a NULL rseq size pointer to handle the scenario where the test is statically linked against a libc that doesn't support rseq in any capacity. Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") Reported-by: Thomas Gleixner <[email protected]> Suggested-by: Florian Weimer <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: [email protected] Closes: https://lore.kernel.org/all/87frdoybk4.ffs@tglx Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Esben Haabendal <[email protected]> Date: Fri May 16 09:23:39 2025 +0200 rtc: interface: Ensure alarm irq is enabled when UIE is enabled commit 9db26d5855d0374d4652487bfb5aacf40821c469 upstream. When setting a normal alarm, user-space is responsible for using RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. But when RTC_UIE_ON is used, interrupts must be enabled so that the requested irq events are generated. When RTC_UIE_OFF is used, alarm irq is disabled if there are no other alarms queued, so this commit brings symmetry to that. Signed-off-by: Esben Haabendal <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Esben Haabendal <[email protected]> Date: Fri May 16 09:23:35 2025 +0200 rtc: interface: Fix long-standing race when setting alarm commit 795cda8338eab036013314dbc0b04aae728880ab upstream. As described in the old comment dating back to commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") from 2010, we have been living with a race window when setting alarm with an expiry in the near future (i.e. next second). With 1 second resolution, it can happen that the second ticks after the check for the timer having expired, but before the alarm is actually set. When this happen, no alarm IRQ is generated, at least not with some RTC chips (isl12022 is an example of this). With UIE RTC timer being implemented on top of alarm irq, being re-armed every second, UIE will occasionally fail to work, as an alarm irq lost due to this race will stop the re-arming loop. For now, I have limited the additional expiry check to only be done for alarms set to next seconds. I expect it should be good enough, although I don't know if we can now for sure that systems with loads could end up causing the same problems for alarms set 2 seconds or even longer in the future. I haven't been able to reproduce the problem with this check in place. Cc: [email protected] Signed-off-by: Esben Haabendal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rob Herring (Arm) <[email protected]> Date: Thu Aug 21 16:57:02 2025 -0500 rtc: x1205: Fix Xicor X1205 vendor prefix [ Upstream commit 606d19ee37de3a72f1b6e95a4ea544f6f20dbb46 ] The vendor for the X1205 RTC is not Xircom, but Xicor which was acquired by Intersil. Since the I2C subsystem drops the vendor prefix for driver matching, the vendor prefix hasn't mattered. Fixes: 6875404fdb44 ("rtc: x1205: Add DT probing support") Signed-off-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Wiesböck <[email protected]> Date: Wed Oct 15 22:15:43 2025 +0200 rtnetlink: Allow deleting FDB entries in user namespace [ Upstream commit bf29555f5bdc017bac22ca66fcb6c9f46ec8788f ] Creating FDB entries is possible from a non-initial user namespace when having CAP_NET_ADMIN, yet, when deleting FDB entries, processes receive an EPERM because the capability is always checked against the initial user namespace. This restricts the FDB management from unprivileged containers. Drop the netlink_capable check in rtnl_fdb_del as it was originally dropped in c5c351088ae7 and reintroduced in 1690be63a27b without intention. This patch was tested using a container on GyroidOS, where it was possible to delete FDB entries from an unprivileged user namespace and private network namespace. Fixes: 1690be63a27b ("bridge: Add vlan support to static neighbors") Reviewed-by: Michael Weiß <[email protected]> Tested-by: Harshal Gohel <[email protected]> Signed-off-by: Johannes Wiesböck <[email protected]> Reviewed-by: Ido Schimmel <[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: Sasha Levin <[email protected]>
Author: Ingo Molnar <[email protected]> Date: Fri Mar 8 12:18:16 2024 +0100 sched/balancing: Rename newidle_balance() => sched_balance_newidle() [ Upstream commit 7d058285cd77cc1411c91efd1b1673530bb1bee8 ] Standardize scheduler load-balancing function names on the sched_balance_() prefix. Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Shrikanth Hegde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 17e3e88ed0b6 ("sched/fair: Fix pelt lost idle time detection") Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Guittot <[email protected]> Date: Wed Oct 8 15:12:14 2025 +0200 sched/fair: Fix pelt lost idle time detection [ Upstream commit 17e3e88ed0b6318fde0d1c14df1a804711cab1b5 ] The check for some lost idle pelt time should be always done when pick_next_task_fair() fails to pick a task and not only when we call it from the fair fast-path. The case happens when the last running task on rq is a RT or DL task. When the latter goes to sleep and the /Sum of util_sum of the rq is at the max value, we don't account the lost of idle time whereas we should. Fixes: 67692435c411 ("sched: Rework pick_next_task() slow-path") Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Barry Song <[email protected]> Date: Thu Dec 3 11:06:41 2020 +1300 sched/fair: Trivial correction of the newidle_balance() comment [ Upstream commit 5b78f2dc315354c05300795064f587366a02c6ff ] idle_balance() has been renamed to newidle_balance(). To differentiate with nohz_idle_balance, it seems refining the comment will be helpful for the readers of the code. Signed-off-by: Barry Song <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Stable-dep-of: 17e3e88ed0b6 ("sched/fair: Fix pelt lost idle time detection") Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Yu <[email protected]> Date: Tue Apr 21 18:50:34 2020 +0800 sched: Make newidle_balance() static again [ Upstream commit d91cecc156620ec75d94c55369509c807c3d07e6 ] After Commit 6e2df0581f56 ("sched: Fix pick_next_task() vs 'change' pattern race"), there is no need to expose newidle_balance() as it is only used within fair.c file. Change this function back to static again. No functional change. Reported-by: kbuild test robot <[email protected]> Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Chen Yu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/83cd3030b031ca5d646cd5e225be10e7a0fdd8f5.1587464698.git.yu.c.chen@intel.com Stable-dep-of: 17e3e88ed0b6 ("sched/fair: Fix pelt lost idle time detection") Signed-off-by: Sasha Levin <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Fri Sep 19 11:26:37 2025 +0200 scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl() commit b81296591c567b12d3873b05a37b975707959b94 upstream. Replace kmalloc() followed by copy_from_user() with memdup_user() to fix a memory leak that occurs when copy_from_user(buff[sg_used],,) fails and the 'cleanup1:' path does not free the memory for 'buff[sg_used]'. Using memdup_user() avoids this by freeing the memory internally. Since memdup_user() already allocates memory, use kzalloc() in the else branch instead of manually zeroing 'buff[sg_used]' using memset(0). Cc: [email protected] Fixes: edd163687ea5 ("[SCSI] hpsa: add driver for HP Smart Array controllers.") Signed-off-by: Thorsten Blum <[email protected]> Acked-by: Don Brace <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John Garry <[email protected]> Date: Tue Oct 18 19:15:57 2022 +0800 scsi: libsas: Add sas_task_find_rq() [ Upstream commit a9ee3f840646e2ec419c734e592ffe997195435e ] blk-mq already provides a unique tag per request. Some libsas LLDDs - like hisi_sas - already use this tag as the unique per-I/O HW tag. Add a common function to provide the request associated with a sas_task for all libsas LLDDs. Signed-off-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jack Wang <[email protected]> Reviewed-by: Jason Yan <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Mon Sep 22 15:21:10 2025 +0530 scsi: mpt3sas: Fix crash in transport port remove by using ioc_info() [ Upstream commit 1703fe4f8ae50d1fb6449854e1fcaed1053e3a14 ] During mpt3sas_transport_port_remove(), messages were logged with dev_printk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device. Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal. [83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__dev_printk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] <TASK> [83428.295850] _dev_printk+0x5c/0x80 [83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas] [83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas] [83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas] [83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas] [83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas] [83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas] [83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pci_device_remove+0x3b/0xb0 [83428.295962] device_release_driver_internal+0x193/0x200 [83428.295968] driver_detach+0x44/0x90 [83428.295971] bus_remove_driver+0x69/0xf0 [83428.295975] pci_unregister_driver+0x2a/0xb0 [83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas] [83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310 [83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296000] ? __x64_sys_getdents64+0x9a/0x110 [83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296009] ? syscall_trace_enter+0xf6/0x1b0 [83428.296014] do_syscall_64+0x7b/0x2c0 [83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5 [83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Tue Oct 18 19:16:02 2022 +0800 scsi: mvsas: Delete mvs_tag_init() [ Upstream commit ffc9f9bf3f14876d019f67ef17d41138802529a8 ] All mvs_tag_init() does is zero the tag bitmap, but this is already done with the kzalloc() call to alloc the tags, so delete this unneeded function. Signed-off-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Sat Sep 20 21:42:01 2025 +0800 scsi: mvsas: Fix use-after-free bugs in mvs_work_queue [ Upstream commit 60cd16a3b7439ccb699d0bf533799eeb894fd217 ] During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis. Fixes: 20b09c2992fe ("[SCSI] mvsas: add support for 94xx; layout change; bug fixes") Signed-off-by: Duoming Zhou <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Tue Oct 18 19:16:03 2022 +0800 scsi: mvsas: Use sas_task_find_rq() for tagging [ Upstream commit 2acf97f199f9eba8321390325519e9b6bff60108 ] The request associated with a SCSI command coming from the block layer has a unique tag, so use that when possible for getting a slot. Unfortunately we don't support reserved commands in the SCSI midlayer yet. As such, SMP tasks - as an example - will not have a request associated, so in the interim continue to manage those tags for that type of sas_task internally. We reserve an arbitrary 4 tags for these internal tags. Indeed, we already decrement MVS_RSVD_SLOTS by 2 for the shost can_queue when flag MVF_FLAG_SOC is set. This change was made in commit 20b09c2992fe ("[SCSI] mvsas: add support for 94xx; layout change; bug fixes"), but what those 2 slots are used for is not obvious. Also make the tag management functions static, where possible. Signed-off-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue") Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Fri Jul 25 10:31:06 2025 +0200 scsi: myrs: Fix dma_alloc_coherent() error check [ Upstream commit edb35b1ffc686fd9b5a91902f034eb9f4d2c9f6b ] Check for NULL return value with dma_alloc_coherent(), because DMA address is not always set by dma_alloc_coherent() on failure. Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)") Signed-off-by: Thomas Fourier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niklas Cassel <[email protected]> Date: Thu Aug 14 19:32:17 2025 +0200 scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod [ Upstream commit 251be2f6037fb7ab399f68cd7428ff274133d693 ] Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]' on rmmod when using an expander. For a direct attached device, attached_phy contains the local phy id. For a device behind an expander, attached_phy contains the remote phy id, not the local phy id. I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a device behind an expander, attached_phy can be much larger than pm8001_ha->chip->n_phy (depending on the amount of phys of the expander). E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the ports has an expander connected. The expander has 31 phys with phy ids 0-30. The pm8001_ha->phy array only contains the phys of the HBA. It does not contain the phys of the expander. Thus, it is wrong to use attached_phy to index the pm8001_ha->phy array for a device behind an expander. Thus, we can only clear phy_attached for devices that are directly attached. Fixes: f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when device is gone") Reviewed-by: Igor Pylypiv <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Damien Le Moal <[email protected]> Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Haoran <[email protected]> Date: Sat Sep 20 15:44:41 2025 +0800 scsi: target: target_core_configfs: Add length check to avoid buffer overflow commit 27e06650a5eafe832a90fd2604f0c5e920857fae upstream. A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow. Reported-by: Wang Haoran <[email protected]> Reported-by: ziiiro <[email protected]> Signed-off-by: Wang Haoran <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexey Simakov <[email protected]> Date: Tue Oct 21 16:00:36 2025 +0300 sctp: avoid NULL dereference when chunk data buffer is missing [ Upstream commit 441f0647f7673e0e64d4910ef61a5fb8f16bfb82 ] chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only. chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition. Fixes: 90017accff61 ("sctp: Add GSO support") Signed-off-by: Alexey Simakov <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Mon Aug 18 13:54:23 2025 -0700 sctp: Fix MAC comparison to be constant-time commit dd91c79e4f58fbe2898dac84858033700e0e99fb upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Eric Biggers <[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: Akhilesh Patil <[email protected]> Date: Sun Sep 14 20:58:41 2025 +0530 selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported [ Upstream commit e8cfc524eaf3c0ed88106177edb6961e202e6716 ] Check if watchdog device supports WDIOF_KEEPALIVEPING option before entering keep_alive() ping test loop. Fix watchdog-test silently looping if ioctl based ping is not supported by the device. Exit from test in such case instead of getting stuck in loop executing failing keep_alive() watchdog_info: identity: m41t93 rtc Watchdog firmware_version: 0 Support/Status: Set timeout (in seconds) Support/Status: Watchdog triggers a management or other external alarm not a reboot Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. WDIOC_KEEPALIVE not supported by this device without this change Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. Watchdog Ticking Away! (Where test stuck here forver silently) Updated change log at commit time: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: d89d08ffd2c5 ("selftests: watchdog: Fix ioctl SET* error paths to take oneshot exit path") Signed-off-by: Akhilesh Patil <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Thu Aug 7 18:54:37 2025 +0300 serial: max310x: Add error checking in probe() [ Upstream commit 672a37ba8af1f2ebcedeb94aea2cdd047f805f30 ] Check if devm_i2c_new_dummy_device() fails. Fixes: 2e1f2d9a9bdb ("serial: max310x: implement I2C support") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sneh Mankad <[email protected]> Date: Mon Aug 25 11:53:50 2025 +0530 soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS [ Upstream commit f87412d18edb5b8393eb8cb1c2d4a54f90185a21 ] Unconditionally clear the TCS_AMC_MODE_TRIGGER bit when a transaction completes. Previously this bit was only cleared when a wake TCS was borrowed as an AMC TCS but not for dedicated AMC TCS. Leaving this bit set for AMC TCS and entering deeper low power modes can generate a false completion IRQ. Prevent this scenario by always clearing the TCS_AMC_MODE_TRIGGER bit upon receiving a completion IRQ. Fixes: 15b3bf61b8d4 ("soc: qcom: rpmh-rsc: Clear active mode configuration for wake TCS") Signed-off-by: Sneh Mankad <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anthony Yznaga <[email protected]> Date: Tue Jul 15 18:24:46 2025 -0700 sparc64: fix hugetlb for sun4u commit 6fd44a481b3c6111e4801cec964627791d0f3ec5 upstream. An attempt to exercise sparc hugetlb code in a sun4u-based guest running under qemu results in the guest hanging due to being stuck in a trap loop. This is due to invalid hugetlb TTEs being installed that do not have the expected _PAGE_PMD_HUGE and page size bits set. Although the breakage has gone apparently unnoticed for several years, fix it now so there is the option to exercise sparc hugetlb code under qemu. This can be useful because sun4v support in qemu does not support linux guests currently and sun4v-based hardware resources may not be readily available. Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs tests on a qemu guest running Debian 13. Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support") Cc: [email protected] Signed-off-by: Anthony Yznaga <[email protected]> Tested-by: John Paul Adrian Glaubitz <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Karcher <[email protected]> Date: Fri Sep 5 00:03:33 2025 +0200 sparc: fix accurate exception reporting in copy_to_user for Niagara 4 [ Upstream commit 5a746c1a2c7980de6c888b6373299f751ad7790b ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a bad calculation. This will fix the return value of copy_to_user in a specific faulting case. The behaviour of memcpy stays unchanged. Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Oracle SPARC T4-1 Signed-off-by: Michael Karcher <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-4-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Karcher <[email protected]> Date: Fri Sep 5 00:03:34 2025 +0200 sparc: fix accurate exception reporting in copy_{from,to}_user for M7 [ Upstream commit 936fb512752af349fc30ccbe0afe14a2ae6d7159 ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: 34060b8fffa7 ("arch/sparc: Add accurate exception reporting in M7memcpy") Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Oracle SPARC S7 Tested-by: Tony Rodriguez <[email protected]> # S7, see https://lore.kernel.org/r/98564e2e68df2dda0e00c67a75c7f7dfedb33c7e.camel@physik.fu-berlin.de Signed-off-by: Michael Karcher <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-5-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Karcher <[email protected]> Date: Fri Sep 5 00:03:32 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara [ Upstream commit 0b67c8fc10b13a9090340c5f8a37d308f4e1571c ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations and a broken epilogue in the exception handlers. This will prevent crashes and ensure correct return values of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz <[email protected]> # on SPARC T4 with modified kernel to use Niagara 1 code Tested-by: Magnus Lindholm <[email protected]> # on Sun Fire T2000 Signed-off-by: Michael Karcher <[email protected]> Tested-by: Ethan Hawke <[email protected]> # on Sun Fire T2000 Tested-by: Ken Link <[email protected]> # on Sun Fire T1000 Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-3-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Karcher <[email protected]> Date: Fri Sep 5 00:03:30 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC [ Upstream commit 4fba1713001195e59cfc001ff1f2837dab877efb ] The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz <[email protected]> # on QEMU 10.0.3 Tested-by: René Rebe <[email protected]> # on Ultra 5 UltraSparc IIi Tested-by: Jonathan 'theJPster' Pallant <[email protected]> # on Sun Netra T1 Signed-off-by: Michael Karcher <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-1-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Karcher <[email protected]> Date: Fri Sep 5 00:03:31 2025 +0200 sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III [ Upstream commit 47b49c06eb62504075f0f2e2227aee2e2c2a58b3 ] Anthony Yznaga tracked down that a BUG_ON in ext4 code with large folios enabled resulted from copy_from_user() returning impossibly large values greater than the size to be copied. This lead to __copy_from_iter() returning impossible values instead of the actual number of bytes it was able to copy. The BUG_ON has been reported in https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. The exception handlers expect that %o2 has already been masked during the bulk copy loop, but the masking was performed after that loop. This will fix the return value of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.") Tested-by: John Paul Adrian Glaubitz <[email protected]> # on Sun Netra 240 Reviewed-by: Anthony Yznaga <[email protected]> Tested-by: René Rebe <[email protected]> # on UltraSparc III+ and UltraSparc IIIi Signed-off-by: Michael Karcher <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-2-1ca72dda195b@mkarcher.dialup.fu-berlin.de Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ma Ke <[email protected]> Date: Sat Sep 20 20:53:12 2025 +0800 sparc: fix error handling in scan_one_device() commit 302c04110f0ce70d25add2496b521132548cd408 upstream. Once of_device_register() failed, we should call put_device() to decrement reference count for cleanup. Or it could cause memory leak. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). Calling path: of_device_register() -> of_device_add() -> device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: [email protected] Fixes: cf44bbc26cf1 ("[SPARC]: Beginnings of generic of_device framework.") Signed-off-by: Ma Ke <[email protected]> Reviewed-by: Andreas Larsson <[email protected]> Signed-off-by: Andreas Larsson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pratyush Yadav <[email protected]> Date: Tue Oct 21 14:14:06 2025 -0400 spi: cadence-quadspi: Flush posted register writes before DAC access [ Upstream commit 1ad55767e77a853c98752ed1e33b68049a243bd7 ] cqspi_read_setup() and cqspi_write_setup() program the address width as the last step in the setup. This is likely to be immediately followed by a DAC region read/write. On TI K3 SoCs the DAC region is on a different endpoint from the register region. This means that the order of the two operations is not guaranteed, and they might be reordered at the interconnect level. It is possible that the DAC read/write goes through before the address width update goes through. In this situation if the previous command used a different address width the OSPI command is sent with the wrong number of address bytes, resulting in an invalid command and undefined behavior. Read back the size register to make sure the write gets flushed before accessing the DAC region. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") CC: [email protected] Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Pratyush Yadav <[email protected]> Signed-off-by: Santhosh Kumar K <[email protected]> Message-ID: <[email protected]> Signed-off-by: Mark Brown <[email protected]> [ backported to drivers/mtd/spi-nor ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pratyush Yadav <[email protected]> Date: Tue Oct 21 14:23:26 2025 -0400 spi: cadence-quadspi: Flush posted register writes before INDAC access [ Upstream commit 29e0b471ccbd674d20d4bbddea1a51e7105212c5 ] cqspi_indirect_read_execute() and cqspi_indirect_write_execute() first set the enable bit on APB region and then start reading/writing to the AHB region. On TI K3 SoCs these regions lie on different endpoints. This means that the order of the two operations is not guaranteed, and they might be reordered at the interconnect level. It is possible for the AHB write to be executed before the APB write to enable the indirect controller, causing the transaction to be invalid and the write erroring out. Read back the APB region write before accessing the AHB region to make sure the write got flushed and the race condition is eliminated. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") CC: [email protected] Reviewed-by: Pratyush Yadav <[email protected]> Signed-off-by: Pratyush Yadav <[email protected]> Signed-off-by: Santhosh Kumar K <[email protected]> Message-ID: <[email protected]> Signed-off-by: Mark Brown <[email protected]> [ applied changes to drivers/mtd/spi-nor/cadence-quadspi.c instead of drivers/spi/spi-cadence-quadspi.c ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Phillip Lougher <[email protected]> Date: Mon Oct 13 18:11:49 2025 -0400 Squashfs: add additional inode sanity checking [ Upstream commit 9ee94bfbe930a1b39df53fa2d7b31141b780eb5a ] Patch series "Squashfs: performance improvement and a sanity check". This patchset adds an additional sanity check when reading regular file inodes, and adds support for SEEK_DATA/SEEK_HOLE lseek() whence values. This patch (of 2): Add an additional sanity check when reading regular file inodes. A regular file if the file size is an exact multiple of the filesystem block size cannot have a fragment. This is because by definition a fragment block stores tailends which are not a whole block in size. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Phillip Lougher <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: 9f1c14c1de1b ("Squashfs: reject negative file sizes in squashfs_read_inode()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Phillip Lougher <[email protected]> Date: Fri Sep 19 00:33:08 2025 +0100 Squashfs: fix uninit-value in squashfs_get_parent commit 74058c0a9fc8b2b4d5f4a0ef7ee2cfa66a9e49cf upstream. Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. Link: https://lkml.kernel.org/r/[email protected] Fixes: 122601408d20 ("Squashfs: export operations") Signed-off-by: Phillip Lougher <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Phillip Lougher <[email protected]> Date: Mon Oct 13 18:11:50 2025 -0400 Squashfs: reject negative file sizes in squashfs_read_inode() [ Upstream commit 9f1c14c1de1bdde395f6cc893efa4f80a2ae3b2b ] Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [[email protected]: only need to check 64 bit quantity] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 6545b246a2c8 ("Squashfs: inode operations") Signed-off-by: Phillip Lougher <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Cc: Amir Goldstein <[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: Ovidiu Panait <[email protected]> Date: Sun Aug 17 20:13:50 2025 +0300 staging: axis-fifo: fix maximum TX packet length check commit 52ff2b840bc723f3be1f096f8017c78e0515858c upstream. Since commit 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation"), write() operations with packets larger than 'tx_fifo_depth - 4' words are no longer rejected with -EINVAL. Fortunately, the packets are not actually getting transmitted to hardware, otherwise they would be raising a 'Transmit Packet Overrun Error' interrupt, which requires a reset of the TX circuit to recover from. Instead, the request times out inside wait_event_interruptible_timeout() and always returns -EAGAIN, since the wake up condition can never be true for these packets. But still, they unnecessarily block other tasks from writing to the FIFO and the EAGAIN return code signals userspace to retry the write() call, even though it will always fail and time out. According to the AXI4-Stream FIFO reference manual (PG080), the maximum valid packet length is 'tx_fifo_depth - 4' words, so attempting to send larger packets is invalid and should not be happening in the first place: > The maximum packet that can be transmitted is limited by the size of > the FIFO, which is (C_TX_FIFO_DEPTH–4)*(data interface width/8) bytes. Therefore, bring back the old behavior and outright reject packets larger than 'tx_fifo_depth - 4' with -EINVAL. Add a comment to explain why the check is necessary. The dev_err() message was removed to avoid cluttering the dmesg log if an invalid packet is received from userspace. Fixes: 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation") Cc: [email protected] Signed-off-by: Ovidiu Panait <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Fri Sep 12 13:13:22 2025 +0300 staging: axis-fifo: flush RX FIFO on read errors commit 82a051e2553b9e297cba82a975d9c538b882c79e upstream. Flush stale data from the RX FIFO in case of errors, to avoid reading old data when new packets arrive. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") removed full FIFO resets from the read error paths, which fixed potential TX data losses, but introduced this RX issue. Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") Cc: [email protected] Signed-off-by: Ovidiu Panait <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Wed Oct 1 23:37:54 2025 +0000 tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). [ Upstream commit 2e7cbbbe3d61c63606994b7ff73c72537afe2e1c ] syzbot reported the splat below in tcp_conn_request(). [0] If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket. After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk. Let's remove reqsk_fastopen_remove() in tcp_conn_request(). Note that other callers make sure tp->fastopen_rsk is not NULL. [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:refcount_warn_saturate (lib/refcount.c:28) Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6 RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246 RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900 RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100 R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8 FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0 Call Trace: <IRQ> tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480) </IRQ> Fixes: 45c8a6cc2bcd ("tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().") Reported-by: syzkaller <[email protected]> Signed-off-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: Eric Dumazet <[email protected]> Date: Wed Sep 3 08:47:18 2025 +0000 tcp: fix __tcp_close() to only send RST when required [ Upstream commit 5f9238530970f2993b23dd67fdaffc552a2d2e98 ] If the receive queue contains payload that was already received, __tcp_close() can send an unexpected RST. Refine the code to take tp->copied_seq into account, as we already do in tcp recvmsg(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Neal Cardwell <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Jason Xing <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sat Oct 11 11:57:42 2025 +0000 tcp: fix tcp_tso_should_defer() vs large RTT [ Upstream commit 295ce1eb36ae47dc862d6c8a1012618a25516208 ] Neal reported that using neper tcp_stream with TCP_TX_DELAY set to 50ms would often lead to flows stuck in a small cwnd mode, regardless of the congestion control. While tcp_stream sets TCP_TX_DELAY too late after the connect(), it highlighted two kernel bugs. The following heuristic in tcp_tso_should_defer() seems wrong for large RTT: delta = tp->tcp_clock_cache - head->tstamp; /* If next ACK is likely to come too late (half srtt), do not defer */ if ((s64)(delta - (u64)NSEC_PER_USEC * (tp->srtt_us >> 4)) < 0) goto send_now; If next ACK is expected to come in more than 1 ms, we should not defer because we prefer a smooth ACK clocking. While blamed commit was a step in the good direction, it was not generic enough. Another patch fixing TCP_TX_DELAY for established flows will be proposed when net-next reopens. Fixes: 50c8339e9299 ("tcp: tso: restore IW10 after TSO autosizing") Reported-by: Neal Cardwell <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Neal Cardwell <[email protected]> Tested-by: Neal Cardwell <[email protected]> Link: https://patch.msgid.link/[email protected] [[email protected]: fixed whitespace issue] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Simakov <[email protected]> Date: Tue Oct 14 19:47:38 2025 +0300 tg3: prevent use of uninitialized remote_adv and local_adv variables [ Upstream commit 0c3f2e62815a43628e748b1e4ad97a1c46cce703 ] Some execution paths that jump to the fiber_setup_done label could leave the remote_adv and local_adv variables uninitialized and then use it. Initialize this variables at the point of definition to avoid this. Fixes: 85730a631f0c ("tg3: Add SGMII phy support for 5719/5718 serdes") Co-developed-by: Alexandr Sapozhnikov <[email protected]> Signed-off-by: Alexandr Sapozhnikov <[email protected]> Signed-off-by: Alexey Simakov <[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: Sabrina Dubroca <[email protected]> Date: Tue Oct 14 11:16:58 2025 +0200 tls: always set record_type in tls_process_cmsg [ Upstream commit b6fe4c29bb51cf239ecf48eacf72b924565cb619 ] When userspace wants to send a non-DATA record (via the TLS_SET_RECORD_TYPE cmsg), we need to send any pending data from a previous MSG_MORE send() as a separate DATA record. If that DATA record is encrypted asynchronously, tls_handle_open_record will return -EINPROGRESS. This is currently treated as an error by tls_process_cmsg, and it will skip setting record_type to the correct value, but the caller (tls_sw_sendmsg_locked) handles that return value correctly and proceeds with sending the new message with an incorrect record_type (DATA instead of whatever was requested in the cmsg). Always set record_type before handling the open record. If tls_handle_open_record returns an error, record_type will be ignored. If it succeeds, whether with synchronous crypto (returning 0) or asynchronous (returning -EINPROGRESS), the caller will proceed correctly. Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Reported-by: Jann Horn <[email protected]> Signed-off-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/0457252e578a10a94e40c72ba6288b3a64f31662.1760432043.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sabrina Dubroca <[email protected]> Date: Tue Oct 14 11:17:00 2025 +0200 tls: don't rely on tx_work during send() [ Upstream commit 7f846c65ca11e63d2409868ff039081f80e42ae4 ] With async crypto, we rely on tx_work to actually transmit records once encryption completes. But while send() is running, both the tx_lock and socket lock are held, so tx_work_handler cannot process the queue of encrypted records, and simply reschedules itself. During a large send(), this could last a long time, and use a lot of memory. Transmit any pending encrypted records before restarting the main loop of tls_sw_sendmsg_locked. Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Reported-by: Jann Horn <[email protected]> Signed-off-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/8396631478f70454b44afb98352237d33f48d34d.1760432043.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Yan <[email protected]> Date: Mon Oct 6 17:21:23 2025 +0100 tools build: Align warning options with perf [ Upstream commit 53d067feb8c4f16d1f24ce3f4df4450bb18c555f ] The feature test programs are built without enabling '-Wall -Werror' options. As a result, a feature may appear to be available, but later building in perf can fail with stricter checks. Make the feature test program use the same warning options as perf. Fixes: 1925459b4d92 ("tools build: Fix feature Makefile issues with 'O='") Signed-off-by: Leo Yan <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: Palmer Dabbelt <[email protected]> Cc: Albert Ou <[email protected]> Cc: Alexandre Ghiti <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: James Clark <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Paul Walmsley <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lino Sanfilippo <[email protected]> Date: Thu Nov 24 14:55:29 2022 +0100 tpm, tpm_tis: Claim locality before writing interrupt registers [ Upstream commit 15d7aa4e46eba87242a320f39773aa16faddadee ] In tpm_tis_probe_single_irq() interrupt registers TPM_INT_VECTOR, TPM_INT_STATUS and TPM_INT_ENABLE are modified to setup the interrupts. Currently these modifications are done without holding a locality thus they have no effect. Fix this by claiming the (default) locality before the registers are written. Since now tpm_tis_gen_interrupt() is called with the locality already claimed remove locality request and release from this function. Signed-off-by: Lino Sanfilippo <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Stable-dep-of: 8a81236f2cb0 ("tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single") Signed-off-by: Sasha Levin <[email protected]>
Author: Gunnar Kudrjavets <[email protected]> Date: Thu Sep 18 18:49:40 2025 +0300 tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single [ Upstream commit 8a81236f2cb0882c7ea6c621ce357f7f3f601fe5 ] The tpm_tis_write8() call specifies arguments in wrong order. Should be (data, addr, value) not (data, value, addr). The initial correct order was changed during the major refactoring when the code was split. Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy") Signed-off-by: Gunnar Kudrjavets <[email protected]> Reviewed-by: Justinien Bouron <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuan Chen <[email protected]> Date: Tue Oct 14 09:00:26 2025 -0400 tracing: Fix race condition in kprobe initialization causing NULL pointer dereference [ Upstream commit 9cf9aa7b0acfde7545c1a1d912576e9bab28dc6f ] There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec <kprobe_perf_func+0x2c>: ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 <kprobe_perf_func+0x30>: ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: return 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read and write memory barriers to guarantee that if CPU1 sees that kprobe functionality is enabled, it must also see that perf_events has been assigned. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 50d780560785 ("tracing/kprobes: Add probe handler dispatcher to support perf and ftrace concurrent use") Cc: [email protected] Signed-off-by: Yuan Chen <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> [ Dropped ftrace changes + context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Tue Apr 1 11:44:43 2025 -0700 udp: Fix memory accounting leak. commit df207de9d9e7a4d92f8567e2c539d9c8c12fd99d upstream. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data) Fixes: f970bd9e3a06 ("udp: implement memory accounting helpers") Reported-by: Matt Dowling <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> [ Yifei: resolve minor conflicts ] Signed-off-by: Yifei Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naman Jain <[email protected]> Date: Thu Aug 28 10:12:00 2025 +0530 uio_hv_generic: Let userspace take care of interrupt mask commit b15b7d2a1b09ef5428a8db260251897405a19496 upstream. Remove the logic to set interrupt mask by default in uio_hv_generic driver as the interrupt mask value is supposed to be controlled completely by the user space. If the mask bit gets changed by the driver, concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, and the user-mode driver will miss an interrupt which will cause a hang. For eg- when the driver sets inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. So let’s assume that happens, the host puts a message into the ring buffer but does not interrupt. Subsequently, the user space code in the guest sets the inbound ring buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”. User space code then calls pread() to wait for an interrupt. Then one of two things happens: * The host never sends another message. So the pread() waits forever. * The host does send another message. But because there’s already a message in the ring buffer, it doesn’t generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever. This could be easily reproduced in hv_fcopy_uio_daemon if we delay setting interrupt mask to 0. Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1, there’s a race condition. Once user space empties the inbound ring buffer, but before user space sets interrupt_mask to 0, the host could put another message in the ring buffer but it wouldn’t interrupt. Then the next pread() would hang. Fix these by removing all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX. Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Suggested-by: John Starks <[email protected]> Signed-off-by: Naman Jain <[email protected]> Cc: [email protected] Reviewed-by: Michael Kelley <[email protected]> Reviewed-by: Long Li <[email protected]> Reviewed-by: Tianyu Lan <[email protected]> Tested-by: Tianyu Lan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tim Guttzeit <[email protected]> Date: Mon Oct 20 15:39:04 2025 +0200 usb/core/quirks: Add Huawei ME906S to wakeup quirk commit dfc2cf4dcaa03601cd4ca0f7def88b2630fca6ab upstream. The list of Huawei LTE modules needing the quirk fixing spurious wakeups was missing the IDs of the Huawei ME906S module, therefore suspend did not work. Cc: stable <[email protected]> Signed-off-by: Tim Guttzeit <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Wu <[email protected]> Date: Fri Aug 22 11:36:09 2025 +0800 usb: gadget: configfs: Correctly set use_os_string at bind [ Upstream commit e271cc0d25015f4be6c88bd7731444644eb352c2 ] Once the use_os_string flag is set to true for some functions (e.g. adb/mtp) which need to response the OS string, and then if we re-bind the ConfigFS gadget to use the other functions (e.g. hid) which should not to response the OS string, however, because the use_os_string flag is still true, so the usb gadget response the OS string descriptor incorrectly, this can cause the USB device to be unrecognizable on the Windows system. An example of this as follows: echo 1 > os_desc/use ln -s functions/ffs.adb configs/b.1/function0 start adbd echo "<udc device>" > UDC #succeed stop adbd rm configs/b.1/function0 echo 0 > os_desc/use ln -s functions/hid.gs0 configs/b.1/function0 echo "<udc device>" > UDC #fail to connect on Windows This patch sets the use_os_string flag to false at bind if the functions not support OS Descriptors. Signed-off-by: William Wu <[email protected]> Fixes: 87213d388e92 ("usb: gadget: configfs: OS String support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Thu Aug 7 18:55:00 2025 +0300 usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup [ Upstream commit 186e8f2bdba551f3ae23396caccd452d985c23e3 ] The kthread_run() function returns error pointers so the max3421_hcd->spi_thread pointer can be either error pointers or NULL. Check for both before dereferencing it. Fixes: 05dfa5c9bc37 ("usb: host: max3421-hcd: fix "spi_rd8" uses dynamic stack allocation warning") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xichao Zhao <[email protected]> Date: Fri Aug 22 17:22:24 2025 +0800 usb: phy: twl6030: Fix incorrect type for ret [ Upstream commit b570b346ddd727c4b41743a6a2f49e7217c5317f ] In the twl6030_usb_probe(), the variable ret is declared as a u32 type. However, since ret may receive -ENODEV when accepting the return value of omap_usb2_set_comparator().Therefore, its type should be changed to int. Fixes: 0e98de67bacba ("usb: otg: make twl6030_usb as a comparator driver to omap_usb2") Signed-off-by: Xichao Zhao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Reinhard Speyerer <[email protected]> Date: Wed Oct 22 16:17:26 2025 +0200 USB: serial: option: add Quectel RG255C commit 89205c60c0fc96b73567a2e9fe27ee3f59d01193 upstream. Add support for Quectel RG255C devices to complement commit 5c964c8a97c1 ("net: usb: qmi_wwan: add Quectel RG255C"). The composition is DM / NMEA / AT / QMI. T: Bus=01 Lev=02 Prnt=99 Port=01 Cnt=02 Dev#=110 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0316 Rev= 5.15 S: Manufacturer=Quectel S: Product=RG255C-GL S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaowei Li <[email protected]> Date: Wed Sep 24 11:16:50 2025 +0800 USB: serial: option: add SIMCom 8230C compositions commit 0e0ba0ecec3d6e819e0c2348331ff99afe2eb5d5 upstream. Add support for SIMCom 8230C which is based on Qualcomm SDX35 chip. USB Device Listings: 0x9071: tty (DM) + tty (NMEA) + tty (AT) + rmnet (QMI mode) + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9071 Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x9078: tty (DM) + tty (NMEA) + tty (AT) + ECM + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9078 Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether 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=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x907b: RNDIS + tty (DM) + tty (NMEA) + tty (AT) + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=907b Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=ef(misc ) Sub=04 Prot=01 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host 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=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 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= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 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=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Xiaowei Li <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: LI Qingwu <[email protected]> Date: Thu Oct 23 03:44:22 2025 +0000 USB: serial: option: add Telit FN920C04 ECM compositions commit 622865c73ae30f254abdf182f4b66cccbe3e0f10 upstream. Add support for the Telit Cinterion FN920C04 module when operating in ECM (Ethernet Control Model) mode. The following USB product IDs are used by the module when AT#USBCFG is set to 3 or 7. 0x10A3: ECM + tty (NMEA) + tty (DUN) [+ tty (DIAG)] T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a3 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether 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= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 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= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(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=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x10A8: ECM + tty (DUN) + tty (AUX) [+ tty (DIAG)] T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a8 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether 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= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 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= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(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=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Adding these IDs allows the option driver to automatically create the corresponding /dev/ttyUSB* ports under ECM mode. Tested with FN920C04 under ECM configuration (USBCFG=3 and 7). Signed-off-by: LI Qingwu <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Renjun Wang <[email protected]> Date: Sun Oct 19 18:44:38 2025 +0800 USB: serial: option: add UNISOC UIS7720 commit 71c07570b918f000de5d0f7f1bf17a2887e303b5 upstream. Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB Signed-off-by: Renjun Wang <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Tue Sep 2 15:15:46 2025 +0300 usb: vhci-hcd: Prevent suspending virtually attached devices [ Upstream commit e40b984b6c4ce3f80814f39f86f87b2a48f2e662 ] The VHCI platform driver aims to forbid entering system suspend when at least one of the virtual USB ports are bound to an active USB/IP connection. However, in some cases, the detection logic doesn't work reliably, i.e. when all devices attached to the virtual root hub have been already suspended, leading to a broken suspend state, with unrecoverable resume. Ensure the virtually attached devices do not enter suspend by setting the syscore PM flag. Note this is currently limited to the client side only, since the server side doesn't implement system suspend prevention. Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver") Signed-off-by: Cristian Ciocaltea <[email protected]> Acked-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Oct 20 21:19:11 2025 -0400 vfs: Don't leak disconnected dentries on umount [ Upstream commit 56094ad3eaa21e6621396cc33811d8f72847a834 ] When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well. Reported-by: [email protected] Fixes: f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") CC: [email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Christian Brauner <[email protected]> [ relocated DCACHE_DISCONNECTED propagation from d_alloc_parallel() to d_alloc() ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Tue Aug 12 14:51:26 2025 +0200 watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the watchdog [ Upstream commit 7dfd80f70ef00d871df5af7c391133f7ba61ad9b ] When the watchdog gets enabled with this driver, it leaves enough time for the core watchdog subsystem to start pinging it. But when the watchdog is already started by hardware or by the boot loader, little time remains before it fires and it happens that the core watchdog subsystem doesn't have time to start pinging it. Until commit 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker function") pinging was managed by the driver itself and the watchdog was immediately pinged by setting the timer expiry to 0. So restore similar behaviour by pinging it when enabling it so that if it was already enabled the watchdog timer counter is reloaded. Fixes: 19ce9490aa84 ("watchdog: mpc8xxx: use the core worker function") Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Wed Jul 9 20:25:30 2025 +0530 wifi: mt76: fix potential memory leak in mt76_wmac_probe() [ Upstream commit 42754b7de2b1a2cf116c5e3f1e8e78392f4ed700 ] In mt76_wmac_probe(), when the mt76_alloc_device() call succeeds, memory is allocated for both struct ieee80211_hw and a workqueue. However, on the error path, the workqueue is not freed. Fix that by calling mt76_free_device() on the error path. Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688") Signed-off-by: Abdun Nihaal <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Kerkmann <[email protected]> Date: Mon Aug 4 16:16:59 2025 +0200 wifi: mwifiex: send world regulatory domain to driver [ Upstream commit 56819d00bc2ebaa6308913c28680da5d896852b8 ] The world regulatory domain is a restrictive subset of channel configurations which allows legal operation of the adapter all over the world. Changing to this domain should not be prevented. Fixes: dd4a9ac05c8e1 ("mwifiex: send regulatory domain info to firmware only if alpha2 changed") changed Signed-off-by: Stefan Kerkmann <[email protected]> Reviewed-by: Jeff Chen <[email protected]> Link: https://patch.msgid.link/20250804-fix-mwifiex-regulatory-domain-v1-1-e4715c770c4d@pengutronix.de Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Mon Aug 11 18:32:55 2025 +0300 wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188 commit e798f2ac6040f46a04795d7de977341fa9aeabae upstream. This ID appears to be RTL8188SU, not RTL8188CU. This is the wrong driver for RTL8188SU. The r8712u driver from staging used to handle this ID. Closes: https://lore.kernel.org/linux-wireless/[email protected]/ Cc: [email protected] Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Aug 8 10:23:56 2025 -0700 x86/umip: Check that the instruction opcode is at least two bytes commit 32278c677947ae2f042c9535674a7fff9a245dd3 upstream. When checking for a potential UMIP violation on #GP, verify the decoder found at least two opcode bytes to avoid false positives when the kernel encounters an unknown instruction that starts with 0f. Because the array of opcode.bytes is zero-initialized by insn_init(), peeking at bytes[1] will misinterpret garbage as a potential SLDT or STR instruction, and can incorrectly trigger emulation. E.g. if a VPALIGNR instruction 62 83 c5 05 0f 08 ff vpalignr xmm17{k5},xmm23,XMMWORD PTR [r8],0xff hits a #GP, the kernel emulates it as STR and squashes the #GP (and corrupts the userspace code stream). Arguably the check should look for exactly two bytes, but no three byte opcodes use '0f 00 xx' or '0f 01 xx' as an escape, i.e. it should be impossible to get a false positive if the first two opcode bytes match '0f 00' or '0f 01'. Go with a more conservative check with respect to the existing code to minimize the chances of breaking userspace, e.g. due to decoder weirdness. Analyzed by Nick Bray <[email protected]>. Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") Reported-by: Dan Snyder <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Aug 8 10:23:57 2025 -0700 x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT aliases) commit 27b1fd62012dfe9d3eb8ecde344d7aa673695ecf upstream. Filter out the register forms of 0F 01 when determining whether or not to emulate in response to a potential UMIP violation #GP, as SGDT and SIDT only accept memory operands. The register variants of 0F 01 are used to encode instructions for things like VMX and SGX, i.e. not checking the Mod field would cause the kernel to incorrectly emulate on #GP, e.g. due to a CPL violation on VMLAUNCH. Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uros Bizjak <[email protected]> Date: Mon Jun 16 11:52:57 2025 +0200 x86/vdso: Fix output operand size of RDPID [ Upstream commit ac9c408ed19d535289ca59200dd6a44a6a2d6036 ] RDPID instruction outputs to a word-sized register (64-bit on x86_64 and 32-bit on x86_32). Use an unsigned long variable to store the correct size. LSL outputs to 32-bit register, use %k operand prefix to always print the 32-bit name of the register. Use RDPID insn mnemonic while at it as the minimum binutils version of 2.30 supports it. [ bp: Merge two patches touching the same function into a single one. ] Fixes: ffebbaedc861 ("x86/vdso: Introduce helper functions for CPU and node number") Signed-off-by: Uros Bizjak <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Andryuk <[email protected]> Date: Fri Oct 17 08:41:17 2025 -0400 xen/events: Cleanup find_virq() return codes [ Upstream commit 08df2d7dd4ab2db8a172d824cda7872d5eca460a ] rc is overwritten by the evtchn_status hypercall in each iteration, so the return value will be whatever the last iteration is. This could incorrectly return success even if the event channel was not found. Change to an explicit -ENOENT for an un-found virq and return 0 on a successful match. Fixes: 62cc5fc7b2e0 ("xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports") Cc: [email protected] Signed-off-by: Jason Andryuk <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> [ converted evtchn pointer output parameter to direct port return value ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Andryuk <[email protected]> Date: Fri Oct 17 11:02:13 2025 -0400 xen/events: Update virq_to_irq on migration [ Upstream commit 3fcc8e146935415d69ffabb5df40ecf50e106131 ] VIRQs come in 3 flavors, per-VPU, per-domain, and global, and the VIRQs are tracked in per-cpu virq_to_irq arrays. Per-domain and global VIRQs must be bound on CPU 0, and bind_virq_to_irq() sets the per_cpu virq_to_irq at registration time Later, the interrupt can migrate, and info->cpu is updated. When calling __unbind_from_irq(), the per-cpu virq_to_irq is cleared for a different cpu. If bind_virq_to_irq() is called again with CPU 0, the stale irq is returned. There won't be any irq_info for the irq, so things break. Make xen_rebind_evtchn_to_cpu() update the per_cpu virq_to_irq mappings to keep them update to date with the current cpu. This ensures the correct virq_to_irq is cleared in __unbind_from_irq(). Fixes: e46cdb66c8fc ("xen: event channels") Cc: [email protected] Signed-off-by: Jason Andryuk <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> [ Adjust context ] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Thu Sep 4 15:11:09 2025 +0200 xen/manage: Fix suspend error path commit f770c3d858687252f1270265ba152d5c622e793f upstream. The device power management API has the following asymmetry: * dpm_suspend_start() does not clean up on failure (it requires a call to dpm_resume_end()) * dpm_suspend_end() does clean up on failure (it does not require a call to dpm_resume_start()) The asymmetry was introduced by commit d8f3de0d2412 ("Suspend-related patches for 2.6.27") in June 2008: It removed a call to device_resume() from device_suspend() (which was later renamed to dpm_suspend_start()). When Xen began using the device power management API in May 2008 with commit 0e91398f2a5d ("xen: implement save/restore"), the asymmetry did not yet exist. But since it was introduced, a call to dpm_resume_end() is missing in the error path of dpm_suspend_start(). Fix it. Fixes: d8f3de0d2412 ("Suspend-related patches for 2.6.27") Signed-off-by: Lukas Wunner <[email protected]> Cc: [email protected] # v2.6.27 Reviewed-by: "Rafael J. Wysocki (Intel)" <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Message-ID: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mathias Nyman <[email protected]> Date: Tue Oct 14 01:55:42 2025 +0300 xhci: dbc: enable back DbC in resume if it was enabled before suspend commit 2bbd38fcd29670e46c0fdb9cd0e90507a8a1bf6a upstream. DbC is currently only enabled back if it's in configured state during suspend. If system is suspended after DbC is enabled, but before the device is properly enumerated by the host, then DbC would not be enabled back in resume. Always enable DbC back in resume if it's suspended in enabled, connected, or configured state Cc: stable <[email protected]> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>