Author: Shuai Xue <[email protected]> Date: Sat Sep 13 10:32:24 2025 +0800 acpi,srat: Fix incorrect device handle check for Generic Initiator [ Upstream commit 7c3643f204edf1c5edb12b36b34838683ee5f8dc ] The Generic Initiator Affinity Structure in SRAT table uses device handle type field to indicate the device type. According to ACPI specification, the device handle type value of 1 represents PCI device, not 0. Fixes: 894c26a1c274 ("ACPI: Support Generic Initiator only domains") Reported-by: Wu Zongyong <[email protected]> Signed-off-by: Shuai Xue <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Jiang <[email protected]> Date: Wed Nov 5 16:51:15 2025 -0700 acpi/hmat: Fix lockdep warning for hmem_register_resource() [ Upstream commit 214291cbaaceeb28debd773336642b1fca393ae0 ] The following lockdep splat was observed while kernel auto-online a CXL memory region: ====================================================== WARNING: possible circular locking dependency detected 6.17.0djtest+ #53 Tainted: G W ------------------------------------------------------ systemd-udevd/3334 is trying to acquire lock: ffffffff90346188 (hmem_resource_lock){+.+.}-{4:4}, at: hmem_register_resource+0x31/0x50 but task is already holding lock: ffffffff90338890 ((node_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x2e/0x70 which lock already depends on the new lock. [..] Chain exists of: hmem_resource_lock --> mem_hotplug_lock --> (node_chain).rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock((node_chain).rwsem); lock(mem_hotplug_lock); lock((node_chain).rwsem); lock(hmem_resource_lock); The lock ordering can cause potential deadlock. There are instances where hmem_resource_lock is taken after (node_chain).rwsem, and vice versa. Split out the target update section of hmat_register_target() so that hmat_callback() only envokes that section instead of attempt to register hmem devices that it does not need to. [ dj: Fix up comment to be closer to 80cols. (Jonathan) ] Fixes: cf8741ac57ed ("ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device") Reviewed-by: Jonathan Cameron <[email protected]> Tested-by: Smita Koralahalli <[email protected]> Reviewed-by: Smita Koralahalli <[email protected]> Reviewed-by: Dan Williams <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:42 2025 +0530 ACPI: CPPC: Check _CPC validity for only the online CPUs [ Upstream commit 6dd3b8a709a130a4d55c866af9804c81b8486d28 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function acpi_cpc_valid() checks for the validity of the _CPC object for all the present CPUs. This breaks when the kernel is booted with "nosmt=force". Hence check the validity of the _CPC objects of only the online CPUs. Fixes: 2aeca6bd0277 ("ACPI: CPPC: Check present CPUs for determining _CPC is valid") Reported-by: Christopher Harris <[email protected]> Closes: https://lore.kernel.org/lkml/CAM+eXpdDT7KjLV0AxEwOLkSJ2QtrsvGvjA2cCHvt1d0k2_C4Cw@mail.gmail.com/ Suggested-by: Mario Limonciello <[email protected]> Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Tested-by: Chrisopher Harris <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:41 2025 +0530 ACPI: CPPC: Detect preferred core availability on online CPUs [ Upstream commit 4fe5934db4a7187d358f1af1b3ef9b6dd59bce58 ] Commit 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") introduced the ability to detect the preferred core on AMD platforms by checking if there at least two distinct highest_perf values. However, it uses for_each_present_cpu() to iterate through all the CPUs in the platform, which is problematic when the kernel is booted with "nosmt=force" commandline option. Hence limit the search to only the online CPUs. Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") Reported-by: Christopher Harris <[email protected]> Closes: https://lore.kernel.org/lkml/CAM+eXpdDT7KjLV0AxEwOLkSJ2QtrsvGvjA2cCHvt1d0k2_C4Cw@mail.gmail.com/ Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Tested-by: Chrisopher Harris <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:44 2025 +0530 ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs [ Upstream commit 0fce75870666b46b700cfbd3216380b422f975da ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPU via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function cppc_perf_ctrs_in_pcc() checks if the CPPC perf-ctrs are in a PCC region for all the present CPUs, which breaks when the kernel is booted with "nosmt=force". Hence, limit the check only to the online CPUs. Fixes: ae2df912d1a5 ("ACPI: CPPC: Disable FIE if registers in PCC regions") Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Fri Nov 7 13:11:43 2025 +0530 ACPI: CPPC: Perform fast check switch only for online CPUs [ Upstream commit 8821c8e80a65bc4eb73daf63b34aac6b8ad69461 ] per_cpu(cpc_desc_ptr, cpu) object is initialized for only the online CPUs via acpi_soft_cpu_online() --> __acpi_processor_start() --> acpi_cppc_processor_probe(). However the function cppc_allow_fast_switch() checks for the validity of the _CPC object for all the present CPUs. This breaks when the kernel is booted with "nosmt=force". Check fast_switch capability only on online CPUs Fixes: 15eece6c5b05 ("ACPI: CPPC: Fix NULL pointer dereference when nosmp is used") Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Sun Nov 9 02:52:22 2025 +0000 af_unix: Initialise scc_index in unix_add_edge(). [ Upstream commit 60e6489f8e3b086bd1130ad4450a2c112e863791 ] Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments. Fixes: ad081928a8b0 ("af_unix: Avoid Tarjan's algorithm if unnecessary.") Reported-by: Quang Le <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Wed Oct 22 19:48:32 2025 +0100 afs: Fix dynamic lookup to fail on cell lookup failure [ Upstream commit 330e2c514823008b22e6afd2055715bc46dd8d55 ] When a process tries to access an entry in /afs, normally what happens is that an automount dentry is created by ->lookup() and then triggered, which jumps through the ->d_automount() op. Currently, afs_dynroot_lookup() does not do cell DNS lookup, leaving that to afs_d_automount() to perform - however, it is possible to use access() or stat() on the automount point, which will always return successfully, have briefly created an afs_cell record if one did not already exist. This means that something like: test -d "/afs/.west" && echo Directory exists will print "Directory exists" even though no such cell is configured. This breaks the "west" python module available on PIP as it expects this access to fail. Now, it could be possible to make afs_dynroot_lookup() perform the DNS[*] lookup, but that would make "ls --color /afs" do this for each cell in /afs that is listed but not yet probed. kafs-client, probably wrongly, preloads the entire cell database and all the known cells are then listed in /afs - and doing ls /afs would be very, very slow, especially if any cell supplied addresses but was wholly inaccessible. [*] When I say "DNS", actually read getaddrinfo(), which could use any one of a host of mechanisms. Could also use static configuration. To fix this, make the following changes: (1) Create an enum to specify the origination point of a call to afs_lookup_cell() and pass this value into that function in place of the "excl" parameter (which can be derived from it). There are six points of origination: - Cell preload through /proc/net/afs/cells - Root cell config through /proc/net/afs/rootcell - Lookup in dynamic root - Automount trigger - Direct mount with mount() syscall - Alias check where YFS tells us the cell name is different (2) Add an extra state into the afs_cell state machine to indicate a cell that's been initialised, but not yet looked up. This is separate from one that can be considered active and has been looked up at least once. (3) Make afs_lookup_cell() vary its behaviour more, depending on where it was called from: If called from preload or root cell config, DNS lookup will not happen until we definitely want to use the cell (dynroot mount, automount, direct mount or alias check). The cell will appear in /afs but stat() won't trigger DNS lookup. If the cell already exists, dynroot will not wait for the DNS lookup to complete. If the cell did not already exist, dynroot will wait. If called from automount, direct mount or alias check, it will wait for the DNS lookup to complete. (4) Make afs_lookup_cell() return an error if lookup failed in one way or another. We try to return -ENOENT if the DNS says the cell does not exist and -EDESTADDRREQ if we couldn't access the DNS. Reported-by: Markus Suvanto <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220685 Signed-off-by: David Howells <[email protected]> Link: https://patch.msgid.link/[email protected] Fixes: 1d0b929fc070 ("afs: Change dynroot to create contents on demand") Tested-by: Markus Suvanto <[email protected]> cc: Marc Dionne <[email protected]> cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Nov 6 11:46:45 2025 +0100 ALSA: hda/hdmi: Fix breakage at probing nvhdmi-mcp driver commit 82420bd4e17bdaba8453fbf9e10c58c9ed0c9727 upstream. After restructuring and splitting the HDMI codec driver code, each HDMI codec driver contains the own build_controls and build_pcms ops. A copy-n-paste error put the wrong entries for nvhdmi-mcp driver; both build_controls and build_pcms are swapped. Unfortunately both callbacks have the very same form, and the compiler didn't complain it, either. This resulted in a NULL dereference because the PCM instance hasn't been initialized at calling the build_controls callback. Fix it by passing the proper entries. Fixes: ad781b550f9a ("ALSA: hda/hdmi: Rewrite to new probe method") Cc: <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220743 Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dawn Gardner <[email protected]> Date: Thu Oct 16 15:42:06 2025 -0300 ALSA: hda/realtek: Fix mute led for HP Omen 17-cb0xxx [ Upstream commit 2a786348004b34c5f61235d51c40c1c718b1f8f9 ] This laptop uses the ALC285 codec, fixed by enabling the ALC285_FIXUP_HP_MUTE_LED quirk Signed-off-by: Dawn Gardner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haein Lee <[email protected]> Date: Wed Nov 12 00:37:54 2025 +0900 ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd [ Upstream commit 632108ec072ad64c8c83db6e16a7efee29ebfb74 ] In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor. Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support") Signed-off-by: Haein Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Sun Nov 9 10:12:07 2025 +0100 ALSA: usb-audio: Fix potential overflow of PCM transfer buffer commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf upstream. The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0]. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7 Link: https://lore.kernel.org/[email protected] Cc: Lizhi Xu <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: João Paulo Gonçalves <[email protected]> Date: Tue Oct 14 09:56:43 2025 -0300 arm64: dts: imx8-ss-img: Avoid gpio0_mipi_csi GPIOs being deferred [ Upstream commit ec4daace64a44b53df76f0629e82684ef09ce869 ] The gpio0_mipi_csi DT nodes are enabled by default, but they are dependent on the irqsteer_csi nodes, which are not enabled. This causes the gpio0_mipi_csi GPIOs to be probe deferred. Since these GPIOs can be used independently of the CSI controller, enable irqsteer_csi by default too to prevent them from being deferred and to ensure they work out of the box. Fixes: 2217f8243714 ("arm64: dts: imx8: add capture controller for i.MX8's img subsystem") Signed-off-by: João Paulo Gonçalves <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frieder Schrempf <[email protected]> Date: Mon Oct 20 15:21:51 2025 +0200 arm64: dts: imx8mp-kontron: Fix USB OTG role switching [ Upstream commit 6504297872c7a5d0d06247970d32940eba26b8b3 ] The VBUS supply regulator is currently assigned to the PHY node. This causes the VBUS to be always on, even when the controller needs to be switched to peripheral mode. Fix the OTG role switching by adding a connector node and moving the VBUS supply regulator to that node. This way the VBUS gets correctly switched according to the current role. Fixes: 946ab10e3f40 ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chukun Pan <[email protected]> Date: Sat Nov 1 22:01:01 2025 +0800 arm64: dts: rockchip: drop reset from rk3576 i2c9 node [ Upstream commit 264152a97edf9f1b7ed5372e4033e46108e41422 ] The reset property is not part of the binding, so drop it. It is also not used by the driver, so it was likely copied from some vendor-kernel node. Fixes: 57b1ce903966 ("arm64: dts: rockchip: Add rk3576 SoC base DT") Signed-off-by: Chukun Pan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrey Leonchikov <[email protected]> Date: Sun Oct 12 14:33:36 2025 +0200 arm64: dts: rockchip: Fix PCIe power enable pin for BigTreeTech CB2 and Pi2 [ Upstream commit e179de737d13ad99bd19ea0fafab759d4074a425 ] Fix typo into regulator GPIO definition. With current definition, PCIe doesn't start up. Valid definition is already used in "pinctrl" section, "pcie_drv" (gpio4, RK_PB1). Fixes: bfbc663d2733a ("arm64: dts: rockchip: Add BigTreeTech CB2 and Pi2") Signed-off-by: Andrey Leonchikov <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrey Leonchikov <[email protected]> Date: Wed Nov 5 22:07:33 2025 +0100 arm64: dts: rockchip: Fix USB power enable pin for BTT CB2 and Pi2 [ Upstream commit a59e927ff46a967f84ddf94e89cbb045810e8974 ] Fix typo into regulator GPIO definition. With current definition - USB powered off. Valid definition can be found on "pinctrl" section: vcc5v0_usb2t_en: vcc5v0-usb2t-en { rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>; }; vcc5v0_usb2b_en: vcc5v0-usb2b-en { rockchip,pins = <4 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>; }; Fixes: bfbc663d2733a ("arm64: dts: rockchip: Add BigTreeTech CB2 and Pi2") Signed-off-by: Andrey Leonchikov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dragan Simic <[email protected]> Date: Sat Sep 6 12:01:22 2025 +0200 arm64: dts: rockchip: Make RK3588 GPU OPP table naming less generic [ Upstream commit b3fd04e23f6e4496f5a2279466a33fbdc83500f0 ] Unify the naming of the existing GPU OPP table nodes found in the RK3588 and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes, following the more "modern" node naming scheme. Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j") Signed-off-by: Dragan Simic <[email protected]> [opp-table also is way too generic on systems with like 4-5 opp-tables] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anand Moon <[email protected]> Date: Mon Oct 13 20:50:03 2025 +0530 arm64: dts: rockchip: Set correct pinctrl for I2S1 8ch TX on odroid-m1 [ Upstream commit d425aef66e62221fa6bb0ccb94296df29e4cc107 ] Enable proper pin multiplexing for the I2S1 8-channel transmit interface by adding the default pinctrl configuration which esures correct signal routing and avoids pinmux conflicts during audio playback. Changes fix the error [ 116.856643] [ T782] rockchip-pinctrl pinctrl: pin gpio1-10 already requested by affinity_hint; cannot claim for fe410000.i2s [ 116.857567] [ T782] rockchip-pinctrl pinctrl: error -EINVAL: pin-42 (fe410000.i2s) [ 116.857618] [ T782] rockchip-pinctrl pinctrl: error -EINVAL: could not request pin 42 (gpio1-10) from group i2s1m0-sdi1 on device rockchip-pinctrl [ 116.857659] [ T782] rockchip-i2s-tdm fe410000.i2s: Error applying setting, reverse things back I2S1 on the M1 to the codec in the RK809 only uses the SCLK, LRCK, SDI0 and SDO0 signals, so limit the claimed pins to those. With this change audio output works as expected: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDMI], device 0: fe400000.i2s-i2s-hifi i2s-hifi-0 [fe400000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: RK817 [Analog RK817], device 0: fe410000.i2s-rk817-hifi rk817-hifi-0 [fe410000.i2s-rk817-hifi rk817-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Fixes: 78f858447cb7 ("arm64: dts: rockchip: Add analog audio on ODROID-M1") Cc: Aurelien Jarno <[email protected]> Signed-off-by: Anand Moon <[email protected]> [adapted the commit message a bit] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Shi <[email protected]> Date: Tue Nov 4 13:49:47 2025 -0800 arm64: kprobes: check the return value of set_memory_rox() [ Upstream commit 0ec364c0c95fc85bcbc88f1a9a06ebe83c88e18c ] Since commit a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full"), __change_memory_common has more chance to fail due to memory allocation failure when splitting page table. So check the return value of set_memory_rox(), then bail out if it fails otherwise we may have RW memory mapping for kprobes insn page. Fixes: 195a1b7d8388 ("arm64: kprobes: call set_memory_rox() for kprobe page") Reviewed-by: Ryan Roberts <[email protected]> Reviewed-by: Dev Jain <[email protected]> Signed-off-by: Yang Shi <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Thu Oct 2 21:48:52 2025 +0200 ARM: dts: BCM53573: Fix address of Luxul XAP-1440's Ethernet PHY [ Upstream commit 3d1c795bdef43363ed1ff71e3f476d86c22e059b ] Luxul XAP-1440 has BCM54210E PHY at address 25. Fixes: 44ad82078069 ("ARM: dts: BCM53573: Fix Ethernet info for Luxul devices") Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jihed Chaibi <[email protected]> Date: Tue Sep 16 00:06:55 2025 +0200 ARM: dts: imx51-zii-rdu1: Fix audmux node names [ Upstream commit f31e261712a0d107f09fb1d3dc8f094806149c83 ] Rename the 'ssi2' and 'aud3' nodes to 'mux-ssi2' and 'mux-aud3' in the audmux configuration of imx51-zii-rdu1.dts to comply with the naming convention in imx-audmux.yaml. This fixes the following dt-schema warning: imx51-zii-rdu1.dtb: audmux@83fd0000 (fsl,imx51-audmux): 'aud3', 'ssi2' do not match any of the regexes: '^mux-[0-9a-z]*$', '^pinctrl-[0-9]+$' Fixes: ceef0396f367f ("ARM: dts: imx: add ZII RDU1 board") Signed-off-by: Jihed Chaibi <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dario Binacchi <[email protected]> Date: Sat Sep 13 11:16:31 2025 +0200 ARM: dts: imx6ull-engicam-microgea-rmm: fix report-rate-hz value [ Upstream commit 62bf7708fe80ec0db14b9179c25eeeda9f81e9d0 ] The 'report-rate-hz' property for the edt-ft5x06 driver was added and handled in the Linux kernel by me with patches [1] and [2] for this specific board. The v1 upstream version, which was the one applied to the customer's kernel, used the 'report-rate' property, which was written directly to the controller register. During review, the 'hz' suffix was added, changing its handling so that writing the value directly to the register was no longer possible for the M06 controller. Once the patches were accepted in mainline, I did not reapply them to the customer's kernel, and when upstreaming the DTS for this board, I forgot to correct the 'report-rate-hz' property value. The property must be set to 60 because this board uses the M06 controller, which expects the report rate in units of 10 Hz, meaning the actual value written to the register is 6. [1] 625f829586ea ("dt-bindings: input: touchscreen: edt-ft5x06: add report-rate-hz") [2] 5bcee83a406c ("Input: edt-ft5x06 - set report rate by dts property") Fixes: ffea3cac94ba ("ARM: dts: imx6ul: support Engicam MicroGEA RMM board") Co-developed-by: Michael Trimarchi <[email protected]> Signed-off-by: Michael Trimarchi <[email protected]> Signed-off-by: Dario Binacchi <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Thu Nov 6 22:31:14 2025 +0800 ASoC: codecs: va-macro: fix resource leak in probe error path [ Upstream commit 3dc8c73365d3ca25c99e7e1a0f493039d7291df5 ] In the commit referenced by the Fixes tag, clk_hw_get_clk() was added in va_macro_probe() to get the fsgen clock, but forgot to add the corresponding clk_put() in va_macro_remove(). This leads to a clock reference leak when the driver is unloaded. Switch to devm_clk_hw_get_clk() to automatically manage the clock resource. Fixes: 30097967e056 ("ASoC: codecs: va-macro: use fsgen as clock") Suggested-by: Konrad Dybcio <[email protected]> Signed-off-by: Haotian Zhang <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Wed Nov 5 14:22:46 2025 +0800 ASoC: cs4271: Fix regulator leak on probe failure [ Upstream commit 6b6eddc63ce871897d3a5bc4f8f593e698aef104 ] The probe function enables regulators at the beginning but fails to disable them in its error handling path. If any operation after enabling the regulators fails, the probe will exit with an error, leaving the regulators permanently enabled, which could lead to a resource leak. Add a proper error handling path to call regulator_bulk_disable() before returning an error. Fixes: 9a397f473657 ("ASoC: cs4271: add regulator consumer support") Signed-off-by: Haotian Zhang <[email protected]> Reviewed-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Thu Nov 20 21:04:05 2025 -0500 ASoC: da7213: Convert to DEFINE_RUNTIME_DEV_PM_OPS() [ Upstream commit 2aa28b748fc967a2f2566c06bdad155fba8af7d8 ] Convert the Dialog DA7213 CODEC driver from an open-coded dev_pm_ops structure to DEFINE_RUNTIME_DEV_PM_OPS(), to simplify the code. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/0c001e0f7658c2d5f33faea963d6ca64f60ccea8.1756999876.git.geert+renesas@glider.be Signed-off-by: Mark Brown <[email protected]> Stable-dep-of: 249d96b492ef ("ASoC: da7213: Use component driver suspend/resume") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Nov 20 21:04:06 2025 -0500 ASoC: da7213: Use component driver suspend/resume [ Upstream commit 249d96b492efb7a773296ab2c62179918301c146 ] Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), and snd_soc_pm_ops is associated with the soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between the soc_driver and the DA7213 codec driver, the power management subsystem does not enforce a specific suspend/resume order between the DA7213 driver and the soc_driver. Because of this, the different codec component functionalities, called from snd_soc_resume() to reconfigure various functions, can race with the DA7213 struct dev_pm_ops::resume function, leading to misapplied configuration. This occasionally results in clipped sound. Fix this by dropping the struct dev_pm_ops::{suspend, resume} and use instead struct snd_soc_component_driver::{suspend, resume}. This ensures the proper configuration sequence is handled by the ASoC subsystem. Cc: [email protected] Fixes: 431e040065c8 ("ASoC: da7213: Add suspend to RAM support") Signed-off-by: Claudiu Beznea <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sharique Mohammad <[email protected]> Date: Wed Oct 15 15:42:15 2025 +0200 ASoC: max98090/91: fixed max98091 ALSA widget powering up/down [ Upstream commit 7a37291ed40a33a5f6c3d370fdde5ee0d8f7d0e4 ] The widgets DMIC3_ENA and DMIC4_ENA must be defined in the DAPM suppy widget, just like DMICL_ENA and DMICR_ENA. Whenever they are turned on or off, the required startup or shutdown sequences must be taken care by the max98090_shdn_event. Signed-off-by: Sharique Mohammad <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cristian Ciocaltea <[email protected]> Date: Fri Oct 3 21:03:27 2025 +0300 ASoC: nau8821: Avoid unnecessary blocking in IRQ handler [ Upstream commit ee70bacef1c6050e4836409927294d744dbcfa72 ] The interrupt handler offloads the microphone detection logic to nau8821_jdet_work(), which implies a sleep operation. However, before being able to process any subsequent hotplug event, the interrupt handler needs to wait for any prior scheduled work to complete. Move the sleep out of jdet_work by converting it to a delayed work. This eliminates the undesired blocking in the interrupt handler when attempting to cancel a recently scheduled work item and should help reducing transient input reports that might confuse user-space. Signed-off-by: Cristian Ciocaltea <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Wed Nov 12 14:57:09 2025 +0800 ASoC: rsnd: fix OF node reference leak in rsnd_ssiu_probe() [ Upstream commit 360b3730f8eab6c4467c6cca4cb0e30902174a63 ] rsnd_ssiu_probe() leaks an OF node reference obtained by rsnd_ssiu_of_node(). The node reference is acquired but never released across all return paths. Fix it by declaring the device node with the __free(device_node) cleanup construct to ensure automatic release when the variable goes out of scope. Fixes: 4e7788fb8018 ("ASoC: rsnd: add SSIU BUSIF support") Signed-off-by: Haotian Zhang <[email protected]> Acked-by: Kuninori Morimoto <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed Oct 29 15:17:58 2025 +0800 ASoC: sdw_utils: fix device reference leak in is_sdca_endpoint_present() commit 1a58d865f423f4339edf59053e496089075fa950 upstream. The bus_find_device_by_name() function returns a device pointer with an incremented reference count, but the original code was missing put_device() calls in some return paths, leading to reference count leaks. Fix this by ensuring put_device() is called before function exit after bus_find_device_by_name() succeeds This follows the same pattern used elsewhere in the kernel where bus_find_device_by_name() is properly paired with put_device(). Found via static analysis and code review. Fixes: 4f8ef33dd44a ("ASoC: soc_sdw_utils: skip the endpoint that doesn't present") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shenghao Ding <[email protected]> Date: Fri Nov 7 13:49:59 2025 +0800 ASoC: tas2781: fix getting the wrong device number [ Upstream commit 29528c8e643bb0c54da01237a35010c6438423d2 ] The return value of device_property_read_u32_array used for getting the property is the status instead of the number of the property. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zilin Guan <[email protected]> Date: Wed Nov 5 02:29:23 2025 +0000 binfmt_misc: restore write access before closing files opened by open_exec() [ Upstream commit 90f601b497d76f40fa66795c3ecf625b6aced9fd ] bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed. However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail. Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly. Fixes: e7850f4d844e ("binfmt_misc: fix possible deadlock in bm_register_write") Signed-off-by: Zilin Guan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:49 2025 +0200 Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions [ Upstream commit 98454bc812f3611551e4b1f81732da4aa7b9597e ] disconnect_all_peers() calls sleeping function (l2cap_chan_close) under spinlock. Holding the lock doesn't actually do any good -- we work on a local copy of the list, and the lock doesn't protect against peer->chan having already been freed. Fix by taking refcounts of peer->chan instead. Clean up the code and old comments a bit. Take devices_lock instead of RCU, because the kfree_rcu(); l2cap_chan_put(); construct in chan_close_cb() does not guarantee peer->chan is necessarily valid in RCU. Also take l2cap_chan_lock() which is required for l2cap_chan_close(). Log: (bluez 6lowpan-tester Client Connect - Disable) ------ BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 ... <TASK> ... l2cap_send_disconn_req (net/bluetooth/l2cap_core.c:938 net/bluetooth/l2cap_core.c:1495) ... ? __pfx_l2cap_chan_close (net/bluetooth/l2cap_core.c:809) do_enable_set (net/bluetooth/6lowpan.c:1048 net/bluetooth/6lowpan.c:1068) ------ Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:47 2025 +0200 Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion [ Upstream commit b454505bf57a2e4f5d49951d4deb03730a9348d9 ] Bluetooth 6lowpan.c confuses BDADDR_LE and ADDR_LE_DEV address types, e.g. debugfs "connect" command takes the former, and "disconnect" and "connect" to already connected device take the latter. This is due to using same value both for l2cap_chan_connect and hci_conn_hash_lookup_le which take different dst_type values. Fix address type passed to hci_conn_hash_lookup_le(). Retain the debugfs API difference between "connect" and "disconnect" commands since it's been like this since 2015 and nobody apparently complained. Fixes: f5ad4ffceba0 ("Bluetooth: 6lowpan: Use hci_conn_hash_lookup_le() when possible") Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:46 2025 +0200 Bluetooth: 6lowpan: reset link-local header on ipv6 recv path [ Upstream commit 3b78f50918276ab28fb22eac9aa49401ac436a3b ] Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: <IRQ> ... packet_rcv (net/packet/af_packet.c:2152) ... <TASK> __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------ Fixes: 18722c247023 ("Bluetooth: Enable 6LoWPAN support for BT LE devices") Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raphael Pinsonneault-Thibeault <[email protected]> Date: Wed Nov 5 14:28:41 2025 -0500 Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF [ Upstream commit 23d22f2f71768034d6ef86168213843fc49bf550 ] There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling "usb_driver_release_interface(&btusb_driver, data->intf)" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=2fc81b50a4f8263a159b Tested-by: [email protected] Fixes: fd913ef7ce619 ("Bluetooth: btusb: Add out-of-band wakeup support") Signed-off-by: Raphael Pinsonneault-Thibeault <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Tue Nov 4 17:02:04 2025 -0500 Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections [ Upstream commit 41bf23338a501e745c398e0faee948dd05d0be98 ] Contrary to what was stated on d36349ea73d8 ("Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK") the PA_LINK does in fact needs to run bis_cleanup in order to terminate the PA Sync, since that is bond to the listening socket which is the entity that controls the lifetime of PA Sync, so if it is closed/released the PA Sync shall be terminated, terminating the PA Sync shall not result in the BIG Sync being terminated since once the later is established it doesn't depend on the former anymore. If the use user wants to reconnect/rebind a number of BIS(s) it shall keep the socket open until it no longer needs the PA Sync, which means it retains full control of the lifetime of both PA and BIG Syncs. Fixes: d36349ea73d8 ("Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK") Fixes: a7bcffc673de ("Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Thu Nov 6 13:05:35 2025 -0500 Bluetooth: hci_event: Fix not handling PA Sync Lost event [ Upstream commit 485e0626e58768f3c53ba61ab9e09d6b60a455f4 ] This handles PA Sync Lost event which previously was assumed to be handled with BIG Sync Lost but their lifetime are not the same thus why there are 2 different events to inform when each sync is lost. Fixes: b2a5f2e1c127 ("Bluetooth: hci_event: Add support for handling LE BIG Sync Lost event") Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Mon Nov 3 20:29:48 2025 +0200 Bluetooth: L2CAP: export l2cap_chan_hold for modules [ Upstream commit e060088db0bdf7932e0e3c2d24b7371c4c5b867c ] l2cap_chan_put() is exported, so export also l2cap_chan_hold() for modules. l2cap_chan_hold() has use case in net/bluetooth/6lowpan.c Signed-off-by: Pauli Virtanen <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pauli Virtanen <[email protected]> Date: Sun Nov 2 20:16:12 2025 +0200 Bluetooth: MGMT: cancel mesh send timer when hdev removed [ Upstream commit 55fb52ffdd62850d667ebed842815e072d3c9961 ] mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------ Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Link: https://lore.kernel.org/linux-bluetooth/[email protected]/ Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eduard Zingerman <[email protected]> Date: Thu Nov 13 18:57:29 2025 -0800 bpf: account for current allocated stack depth in widen_imprecise_scalars() [ Upstream commit b0c8e6d3d866b6a7f73877f71968dbffd27b7785 ] The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds. Fixes: 2793a8b015f7 ("bpf: exact states comparison for iterator convergence checks") Reported-by: Emil Tsalapatis <[email protected]> Signed-off-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Nov 12 12:55:16 2025 +0000 bpf: Add bpf_prog_run_data_pointers() [ Upstream commit 4ef92743625818932b9c320152b58274c05e5053 ] syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end. Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block") Reported-by: syzbot <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Wed Oct 29 13:05:32 2025 +0000 btrfs: do not update last_log_commit when logging inode due to a new name commit bfe3d755ef7cec71aac6ecda34a107624735aac7 upstream. When logging that a new name exists, we skip updating the inode's last_log_commit field to prevent a later explicit fsync against the inode from doing nothing (as updating last_log_commit makes btrfs_inode_in_log() return true). We are detecting, at btrfs_log_inode(), that logging a new name is happening by checking the logging mode is not LOG_INODE_EXISTS, but that is not enough because we may log parent directories when logging a new name of a file in LOG_INODE_ALL mode - we need to check that the logging_new_name field of the log context too. An example scenario where this results in an explicit fsync against a directory not persisting changes to the directory is the following: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/foo $ sync $ mkdir /mnt/dir # Write some data to our file and fsync it. $ xfs_io -c "pwrite -S 0xab 0 64K" -c "fsync" /mnt/foo # Add a new link to our file. Since the file was logged before, we # update it in the log tree by calling btrfs_log_new_name(). $ ln /mnt/foo /mnt/dir/bar # fsync the root directory - we expect it to persist the dentry for # the new directory "dir". $ xfs_io -c "fsync" /mnt <power fail> After mounting the fs the entry for directory "dir" does not exists, despite the explicit fsync on the root directory. Here's why this happens: 1) When we fsync the file we log the inode, so that it's present in the log tree; 2) When adding the new link we enter btrfs_log_new_name(), and since the inode is in the log tree we proceed to updating the inode in the log tree; 3) We first set the inode's last_unlink_trans to the current transaction (early in btrfs_log_new_name()); 4) We then eventually enter btrfs_log_inode_parent(), and after logging the file's inode, we call btrfs_log_all_parents() because the inode's last_unlink_trans matches the current transaction's ID (updated in the previous step); 5) So btrfs_log_all_parents() logs the root directory by calling btrfs_log_inode() for the root's inode with a log mode of LOG_INODE_ALL so that new dentries are logged; 6) At btrfs_log_inode(), because the log mode is LOG_INODE_ALL, we update root inode's last_log_commit to the last transaction that changed the inode (->last_sub_trans field of the inode), which corresponds to the current transaction's ID; 7) Then later when user space explicitly calls fsync against the root directory, we enter btrfs_sync_file(), which calls skip_inode_logging() and that returns true, since its call to btrfs_inode_in_log() returns true and there are no ordered extents (it's a directory, never has ordered extents). This results in btrfs_sync_file() returning without syncing the log or committing the current transaction, so all the updates we did when logging the new name, including logging the root directory, are not persisted. So fix this by but updating the inode's last_log_commit if we are sure we are not logging a new name (if ctx->logging_new_name is false). A test case for fstests will follow soon. Reported-by: Vyacheslav Kovalevsky <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 130341be7ffa ("btrfs: always update the logged transaction when logging new names") CC: [email protected] # 6.1+ Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zilin Guan <[email protected]> Date: Wed Nov 5 02:37:22 2025 +0000 btrfs: release root after error in data_reloc_print_warning_inode() commit c367af440e03eba7beb0c9f3fe540f9bcb69134a upstream. data_reloc_print_warning_inode() calls btrfs_get_fs_root() to obtain local_root, but fails to release its reference when paths_from_inode() returns an error. This causes a potential memory leak. Add a missing btrfs_put_root() call in the error path to properly decrease the reference count of local_root. Fixes: b9a9a85059cde ("btrfs: output affected files when relocation fails") CC: [email protected] # 6.6+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Zilin Guan <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zilin Guan <[email protected]> Date: Wed Nov 5 03:53:21 2025 +0000 btrfs: scrub: put bio after errors in scrub_raid56_parity_stripe() commit 5fea61aa1ca70c4b3738eebad9ce2d7e7938ebbd upstream. scrub_raid56_parity_stripe() allocates a bio with bio_alloc(), but fails to release it on some error paths, leading to a potential memory leak. Add the missing bio_put() calls to properly drop the bio reference in those error cases. Fixes: 1009254bf22a3 ("btrfs: scrub: use scrub_stripe to implement RAID56 P/Q scrub") CC: [email protected] # 6.6+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Zilin Guan <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Fri Sep 12 15:43:21 2025 +0900 btrfs: zoned: fix conventional zone capacity calculation commit 94f54924b96d3565c6b559294b3401b5496c21ac upstream. When a block group contains both conventional zone and sequential zone, the capacity of the block group is wrongly set to the block group's full length. The capacity should be calculated in btrfs_load_block_group_* using the last allocation offset. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree") CC: [email protected] # v6.12+ Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Tue Sep 16 11:46:11 2025 +0900 btrfs: zoned: fix stripe width calculation commit 6a1ab50135ce829b834b448ce49867b5210a1641 upstream. The stripe offset calculation in the zoned code for raid0 and raid10 wrongly uses map->stripe_size to calculate it. In fact, map->stripe_size is the size of the device extent composing the block group, which always is the zone_size on the zoned setup. Fix it by using BTRFS_STRIPE_LEN and BTRFS_STRIPE_LEN_SHIFT. Also, optimize the calculation a bit by doing the common calculation only once. Fixes: c0d90a79e8e6 ("btrfs: zoned: fix alloc_offset calculation for partly conventional block groups") CC: [email protected] # 6.17+ Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Fri Nov 7 22:01:39 2025 +0800 cifs: client: fix memory leak in smb3_fs_context_parse_param commit e8c73eb7db0a498cd4b22d2819e6ab1a6f506bd6 upstream. The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=72afd4c236e6bc3f4bac Cc: [email protected] Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Edward Adam Davis <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hao Ge <[email protected]> Date: Wed Oct 29 09:43:17 2025 +0800 codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext commit 1abbdf3d57aa964e572940d67c9ec5dc87710738 upstream. When alloc_slab_obj_exts() fails and then later succeeds in allocating a slab extension vector, it calls handle_failed_objexts_alloc() to mark all objects in the vector as empty. As a result all objects in this slab (slabA) will have their extensions set to CODETAG_EMPTY. Later on if this slabA is used to allocate a slabobj_ext vector for another slab (slabB), we end up with the slabB->obj_exts pointing to a slabobj_ext vector that itself has a non-NULL slabobj_ext equal to CODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called to free slabB->obj_exts vector. free_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which will generate a warning because it expects slabobj_ext vectors to have a NULL obj_ext, not CODETAG_EMPTY. Modify mark_objexts_empty() to skip the warning and setting the obj_ext value if it's already set to CODETAG_EMPTY. To quickly detect this WARN, I modified the code from WARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1); We then obtained this message: [21630.898561] ------------[ cut here ]------------ [21630.898596] kernel BUG at mm/slub.c:2050! [21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject] [21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G W 6.18.0-rc1+ #74 PREEMPT(voluntary) [21630.910495] Tainted: [W]=WARN [21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [21630.912392] pc : __free_slab+0x228/0x250 [21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0 [21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40 [21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40 [21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40 [21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000 [21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66 [21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc [21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000 [21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007 [21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001 [21630.921810] Call trace: [21630.922130] __free_slab+0x228/0x250 (P) [21630.922669] free_slab+0x38/0x118 [21630.923079] free_to_partial_list+0x1d4/0x340 [21630.923591] __slab_free+0x24c/0x348 [21630.924024] ___cache_free+0xf0/0x110 [21630.924468] qlist_free_all+0x78/0x130 [21630.924922] kasan_quarantine_reduce+0x114/0x148 [21630.925525] __kasan_slab_alloc+0x7c/0xb0 [21630.926006] kmem_cache_alloc_noprof+0x164/0x5c8 [21630.926699] __alloc_object+0x44/0x1f8 [21630.927153] __create_object+0x34/0xc8 [21630.927604] kmemleak_alloc+0xb8/0xd8 [21630.928052] kmem_cache_alloc_noprof+0x368/0x5c8 [21630.928606] getname_flags.part.0+0xa4/0x610 [21630.929112] getname_flags+0x80/0xd8 [21630.929557] vfs_fstatat+0xc8/0xe0 [21630.929975] __do_sys_newfstatat+0xa0/0x100 [21630.930469] __arm64_sys_newfstatat+0x90/0xd8 [21630.931046] invoke_syscall+0xd4/0x258 [21630.931685] el0_svc_common.constprop.0+0xb4/0x240 [21630.932467] do_el0_svc+0x48/0x68 [21630.932972] el0_svc+0x40/0xe0 [21630.933472] el0t_64_sync_handler+0xa0/0xe8 [21630.934151] el0t_64_sync+0x1ac/0x1b0 [21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000) [21630.936461] SMP: stopping secondary CPUs [21630.939550] Starting crashdump kernel... [21630.940108] Bye! Link: https://lkml.kernel.org/r/[email protected] Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Signed-off-by: Hao Ge <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Cc: Christoph Lameter (Ampere) <[email protected]> Cc: David Rientjes <[email protected]> Cc: gehao <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Thu Nov 6 11:50:00 2025 +0100 compiler_types: Move unused static inline functions warning to W=2 [ Upstream commit 9818af18db4bfefd320d0fef41390a616365e6f7 ] Per Nathan, clang catches unused "static inline" functions in C files since commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Linus said: > So I entirely ignore W=1 issues, because I think so many of the extra > warnings are bogus. > > But if this one in particular is causing more problems than most - > some teams do seem to use W=1 as part of their test builds - it's fine > to send me a patch that just moves bad warnings to W=2. > > And if anybody uses W=2 for their test builds, that's THEIR problem.. Here is the change to bump the warning from W=1 to W=2. Fixes: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Signed-off-by: Peter Zijlstra <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] [nathan: Adjust comment as well] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Pandruvada <[email protected]> Date: Mon Nov 10 17:08:40 2025 -0800 cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writes [ Upstream commit 4b747cc628d8f500d56cf1338280eacc66362ff3 ] Commit ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") introduced a check for feature X86_FEATURE_IDA to verify turbo mode support. Although this is the correct way to check for turbo mode support, it causes issues on some platforms that disable turbo during OS boot, but enable it later [1]. Before adding this feature check, users were able to get turbo mode frequencies by writing 0 to /sys/devices/system/cpu/intel_pstate/no_turbo post-boot. To restore the old behavior on the affected systems while still addressing the unchecked MSR issue on some Skylake-X systems, check X86_FEATURE_IDA only immediately before updates of MSR_IA32_PERF_CTL that may involve setting the Turbo Engage Bit (bit 32). Fixes: ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") Reported-by: Aaron Rainbolt <[email protected]> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122531 [1] Tested-by: Aaron Rainbolt <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sourabh Jain <[email protected]> Date: Sun Nov 2 01:07:41 2025 +0530 crash: fix crashkernel resource shrink commit 00fbff75c5acb4755f06f08bd1071879c63940c5 upstream. When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...> This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory. Link: https://lkml.kernel.org/r/[email protected] Fixes: 16c6006af4d4 ("kexec: enable kexec_crash_size to support two crash kernel regions") Signed-off-by: Sourabh Jain <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Zhen Lei <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Oct 27 23:09:34 2025 +0800 crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value commit 59b0afd01b2ce353ab422ea9c8375b03db313a21 upstream. The qm_get_qos_value() function calls bus_find_device_by_name() which increases the device reference count, but fails to call put_device() to balance the reference count and lead to a device reference leak. Add put_device() calls in both the error path and success path to properly balance the reference count. Found via static analysis. Fixes: 22d7a6c39cab ("crypto: hisilicon/qm - add pci bdf number check") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Longfang Liu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qinxin Xia <[email protected]> Date: Tue Oct 28 20:08:59 2025 +0800 dma-mapping: benchmark: Restore padding to ensure uABI remained consistent commit 23ee8a2563a0f24cf4964685ced23c32be444ab8 upstream. The padding field in the structure was previously reserved to maintain a stable interface for potential new fields, ensuring compatibility with user-space shared data structures. However,it was accidentally removed by tiantao in a prior commit, which may lead to incompatibility between user space and the kernel. This patch reinstates the padding to restore the original structure layout and preserve compatibility. Fixes: 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition") Cc: [email protected] Acked-by: Barry Song <[email protected]> Signed-off-by: Qinxin Xia <[email protected]> Reported-by: Barry Song <[email protected]> Closes: https://lore.kernel.org/lkml/CAGsJ_4waiZ2+NBJG+SCnbNk+nQ_ZF13_Q5FHJqZyxyJTcEop2A@mail.gmail.com/ Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sultan Alsawaf <[email protected]> Date: Fri Nov 7 13:07:13 2025 -0500 drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BO [ Upstream commit 7132f7e025f9382157543dd86a62d161335b48b9 ] When the BO pointer provided to amdgpu_bo_create_kernel() points to non-NULL, amdgpu_bo_create_kernel() takes it as a hint to pin that address rather than allocate a new BO. This functionality is never desired for allocating ISP buffers. A new BO should always be created when isp_kernel_buffer_alloc() is called, per the description for isp_kernel_buffer_alloc(). Ensure this by zeroing *bo right before the amdgpu_bo_create_kernel() call. Fixes: 55d42f616976 ("drm/amd/amdgpu: Add helper functions for isp buffers") Reviewed-by: Mario Limonciello (AMD) <[email protected]> Reviewed-by: Pratap Nirujogi <[email protected]> Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 73c8c29baac7f0c7e703d92eba009008cbb5228e) Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Tue Sep 9 16:17:50 2025 +0200 drm/amd/display: Add pixel_clock to amd_pp_display_configuration [ Upstream commit b515dcb0dc4e85d8254f5459cfb32fce88dacbfb ] This commit adds the pixel_clock field to the display config struct so that power management (DPM) can use it. We currently don't have a proper bandwidth calculation on old GPUs with DCE 6-10 because dce_calcs only supports DCE 11+. So the power management (DPM) on these GPUs may need to make ad-hoc decisions for display based on the pixel clock. Also rename sym_clock to pixel_clock in dm_pp_single_disp_config to avoid confusion with other code where the sym_clock refers to the DisplayPort symbol clock. Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Mon Aug 25 23:56:29 2025 +0200 drm/amd/display: Disable fastboot on DCE 6 too [ Upstream commit 7495962cbceb967e095233a5673ea71f3bcdee7e ] It already didn't work on DCE 8, so there is no reason to assume it would on DCE 6. Signed-off-by: Timur Kristóf <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Alex Hung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Thu Oct 30 14:39:43 2025 -0500 drm/amd/display: Don't stretch non-native images by default in eDP [ Upstream commit 3362692fea915ce56345366364a501c629c9ff17 ] commit 978fa2f6d0b12 ("drm/amd/display: Use scaling for non-native resolutions on eDP") started using the GPU scaler hardware to scale when a non-native resolution was picked on eDP. This scaling was done to fill the screen instead of maintain aspect ratio. The idea was supposed to be that if a different scaling behavior is preferred then the compositor would request it. The not following aspect ratio behavior however isn't desirable, so adjust it to follow aspect ratio and still try to fill screen. Note: This will lead to black bars in some cases for non-native resolutions. Compositors can request the previous behavior if desired. Fixes: 978fa2f6d0b1 ("drm/amd/display: Use scaling for non-native resolutions on eDP") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4538 Signed-off-by: Mario Limonciello (AMD) <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 825df7ff4bb1a383ad4827545e09aec60d230770) Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Fri Sep 26 20:26:12 2025 +0200 drm/amd/pm: Disable MCLK switching on SI at high pixel clocks [ Upstream commit 5c05bcf6ae7732da1bd4dc1958d527b5f07f216a ] On various SI GPUs, a flickering can be observed near the bottom edge of the screen when using a single 4K 60Hz monitor over DP. Disabling MCLK switching works around this problem. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Tue Sep 9 16:17:51 2025 +0200 drm/amd/pm: Use pm_display_cfg in legacy DPM (v2) [ Upstream commit 9d73b107a61b73e7101d4b728ddac3d2c77db111 ] This commit is necessary for DC to function well with chips that use the legacy power management code, ie. SI and KV. Communicate display information from DC to the legacy PM code. Currently DC uses pm_display_cfg to communicate power management requirements from the display code to the DPM code. However, the legacy (non-DC) code path used different fields and therefore could not take into account anything from DC. Change the legacy display code to fill the same pm_display_cfg struct as DC and use the same in the legacy DPM code. To ease review and reduce churn, this commit does not yet delete the now unneeded code, that is done in the next commit. v2: Rebase. Fix single_display in amdgpu_dpm_pick_power_state. Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Timur Kristóf <[email protected]> Date: Fri Sep 26 20:26:13 2025 +0200 drm/amd: Disable ASPM on SI [ Upstream commit 7bdd91abf0cb3ea78160e2e78fb58b12f6a38d55 ] Enabling ASPM causes randoms hangs on Tahiti and Oland on Zen4. It's unclear if this is a platform-specific or GPU-specific issue. Disable ASPM on SI for the time being. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Tue Nov 4 13:38:02 2025 -0600 drm/amd: Fix suspend failure with secure display TA [ Upstream commit b09cb2996cdf50cd1ab4020e002c95d742c81313 ] commit c760bcda83571 ("drm/amd: Check whether secure display TA loaded successfully") attempted to fix extra messages, but failed to port the cleanup that was in commit 5c6d52ff4b61e ("drm/amd: Don't try to enable secure display TA multiple times") to prevent multiple tries. Add that to the failure handling path even on a quick failure. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4679 Fixes: c760bcda8357 ("drm/amd: Check whether secure display TA loaded successfully") Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4104c0a454f6a4d1e0d14895d03c0e7bdd0c8240) Signed-off-by: Sasha Levin <[email protected]>
Author: Vitaly Prosyak <[email protected]> Date: Thu Nov 6 12:35:53 2025 -0500 drm/amdgpu: disable peer-to-peer access for DCC-enabled GC12 VRAM surfaces commit 22a36e660d014925114feb09a2680bb3c2d1e279 upstream. Certain multi-GPU configurations (especially GFX12) may hit data corruption when a DCC-compressed VRAM surface is shared across GPUs using peer-to-peer (P2P) DMA transfers. Such surfaces rely on device-local metadata and cannot be safely accessed through a remote GPU’s page tables. Attempting to import a DCC-enabled surface through P2P leads to incorrect rendering or GPU faults. This change disables P2P for DCC-enabled VRAM buffers that are contiguous and allocated on GFX12+ hardware. In these cases, the importer falls back to the standard system-memory path, avoiding invalid access to compressed surfaces. Future work could consider optional migration (VRAM→System→VRAM) if a performance regression is observed when `attach->peer2peer = false`. Tested on: - Dual RX 9700 XT (Navi4x) setup - GNOME and Wayland compositor scenarios - Confirmed no corruption after disabling P2P under these conditions v2: Remove check TTM_PL_VRAM & TTM_PL_FLAG_CONTIGUOUS. v3: simplify for upsteam and fix ip version check (Alex) Suggested-by: Christian König <[email protected]> Signed-off-by: Vitaly Prosyak <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 9dff2bb709e6fbd97e263fd12bf12802d2b5a0cf) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse.Zhang <[email protected]> Date: Fri Oct 24 16:09:25 2025 +0800 drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_process commit 6623c5f9fd877868fba133b4ae4dab0052e82dad upstream. Fix a potential deadlock caused by inconsistent spinlock usage between interrupt and process contexts in the userq fence driver. The issue occurs when amdgpu_userq_fence_driver_process() is called from both: - Interrupt context: gfx_v11_0_eop_irq() -> amdgpu_userq_fence_driver_process() - Process context: amdgpu_eviction_fence_suspend_worker() -> amdgpu_userq_fence_driver_force_completion() -> amdgpu_userq_fence_driver_process() In interrupt context, the spinlock was acquired without disabling interrupts, leaving it in {IN-HARDIRQ-W} state. When the same lock is acquired in process context, the kernel detects inconsistent locking since the process context acquisition would enable interrupts while holding a lock previously acquired in interrupt context. Kernel log shows: [ 4039.310790] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 4039.310804] kworker/7:2/409 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 4039.310818] ffff9284e1bed000 (&fence_drv->fence_list_lock){?...}-{3:3}, [ 4039.310993] {IN-HARDIRQ-W} state was registered at: [ 4039.311004] lock_acquire+0xc6/0x300 [ 4039.311018] _raw_spin_lock+0x39/0x80 [ 4039.311031] amdgpu_userq_fence_driver_process.part.0+0x30/0x180 [amdgpu] [ 4039.311146] amdgpu_userq_fence_driver_process+0x17/0x30 [amdgpu] [ 4039.311257] gfx_v11_0_eop_irq+0x132/0x170 [amdgpu] Fix by using spin_lock_irqsave()/spin_unlock_irqrestore() to properly manage interrupt state regardless of calling context. Reviewed-by: Christian König <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit ded3ad780cf97a04927773c4600823b84f7f3cc2) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jesse.Zhang <[email protected]> Date: Mon Oct 13 13:46:12 2025 +0800 drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices [ Upstream commit 883f309add55060233bf11c1ea6947140372920f ] Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian) Reviewed-by: Christian König <[email protected]> Suggested-by: Lijo Lazar <[email protected]> Signed-off-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian König <[email protected]> Date: Tue Oct 7 10:10:52 2025 +0200 drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM [ Upstream commit 33cc891b56b93cad1a83263eaf2e417436f70c82 ] Otherwise accessing them can cause a crash. Signed-off-by: Christian König <[email protected]> Tested-by: Mangesh Gadre <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Arunpravin Paneer Selvam <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian König <[email protected]> Date: Wed Aug 27 14:47:23 2025 +0200 drm/amdgpu: remove two invalid BUG_ON()s [ Upstream commit 5d55ed19d4190d2c210ac05ac7a53f800a8c6fe5 ] Those can be triggered trivially by userspace. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Acked-by: Timur Kristóf <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Tue Oct 14 16:45:17 2025 -0400 drm/amdgpu: set default gfx reset masks for gfx6-8 [ Upstream commit 90b75e12a6e831c8516498f690058d4165d5a5d6 ] These were not set so soft recovery was inadvertantly disabled. Fixes: 6ac55eab4fc4 ("drm/amdgpu: move reset support type checks into the caller") Reviewed-by: Jesse Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 1972763505d728c604b537180727ec8132e619df) Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Kim <[email protected]> Date: Wed Jun 18 10:31:15 2025 -0400 drm/amdkfd: fix suspend/resume all calls in mes based eviction path [ Upstream commit 079ae5118e1f0dcf5b1ab68ffdb5760b06ed79a2 ] Suspend/resume all gangs should be done with the device lock is held. Signed-off-by: Jonathan Kim <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Kim <[email protected]> Date: Thu Nov 6 10:17:06 2025 -0500 drm/amdkfd: relax checks for over allocation of save area commit d15deafab5d722afb9e2f83c5edcdef9d9d98bd1 upstream. Over allocation of save area is not fatal, only under allocation is. ROCm has various components that independently claim authority over save area size. Unless KFD decides to claim single authority, relax size checks. Signed-off-by: Jonathan Kim <[email protected]> Reviewed-by: Philip Yang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 15bd4958fe38e763bc17b607ba55155254a01f55) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Tue Nov 11 17:09:20 2025 -0800 drm/client: fix MODULE_PARM_DESC string for "active" [ Upstream commit 0a4a18e888ae8c8004582f665c5792c84a681668 ] The MODULE_PARM_DESC string for the "active" parameter is missing a space and has an extraneous trailing ']' character. Correct these. Before patch: $ modinfo -p ./drm_client_lib.ko active:Choose which drm client to start, default isfbdev] (string) After patch: $ modinfo -p ./drm_client_lib.ko active:Choose which drm client to start, default is fbdev (string) Fixes: f7b42442c4ac ("drm/log: Introduce a new boot logger to draw the kmsg on the screen") Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jani Nikula <[email protected]> Date: Thu Nov 6 22:00:00 2025 +0200 drm/i915/psr: fix pipe to vblank conversion commit 994dec10991b53beac3e16109d876ae363e8a329 upstream. First, we can't assume pipe == crtc index. If a pipe is fused off in between, it no longer holds. intel_crtc_for_pipe() is the only proper way to get from a pipe to the corresponding crtc. Second, drivers aren't supposed to access or index drm->vblank[] directly. There's drm_crtc_vblank_crtc() for this. Use both functions to fix the pipe to vblank conversion. Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <[email protected]> Cc: [email protected] # v6.16+ Reviewed-by: Jouni Högander <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jani Nikula <[email protected]> (cherry picked from commit 2750f6765d6974f7e163c5d540a96c8703f6d8dd) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Janusz Krzysztofik <[email protected]> Date: Thu Oct 23 10:25:19 2025 +0200 drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD [ Upstream commit 84bbe327a5cbb060f3321c9d9d4d53936fc1ef9b ] On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x1635/0x2810 [86.863152] lock_acquire+0xc4/0x2f0 [86.863166] cpus_read_lock+0x41/0x100 [86.863180] stop_machine+0x1c/0x50 [86.863194] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.863987] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.864735] __vma_bind+0x55/0x70 [i915] [86.865510] fence_work+0x26/0xa0 [i915] [86.866248] fence_notify+0xa1/0x140 [i915] [86.866983] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.867719] i915_sw_fence_commit+0x39/0x60 [i915] [86.868453] i915_vma_pin_ww+0x462/0x1360 [i915] [86.869228] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.870001] initial_plane_vma+0x307/0x840 [i915] [86.870774] intel_initial_plane_config+0x33f/0x670 [i915] [86.871546] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.872330] i915_driver_probe+0x7fa/0xe80 [i915] [86.873057] i915_pci_probe+0xe6/0x220 [i915] [86.873782] local_pci_probe+0x47/0xb0 [86.873802] pci_device_probe+0xf3/0x260 [86.873817] really_probe+0xf1/0x3c0 [86.873833] __driver_probe_device+0x8c/0x180 [86.873848] driver_probe_device+0x24/0xd0 [86.873862] __driver_attach+0x10f/0x220 [86.873876] bus_for_each_dev+0x7f/0xe0 [86.873892] driver_attach+0x1e/0x30 [86.873904] bus_add_driver+0x151/0x290 [86.873917] driver_register+0x5e/0x130 [86.873931] __pci_register_driver+0x7d/0x90 [86.873945] i915_pci_register_driver+0x23/0x30 [i915] [86.874678] i915_init+0x37/0x120 [i915] [86.875347] do_one_initcall+0x60/0x3f0 [86.875369] do_init_module+0x97/0x2a0 [86.875385] load_module+0x2c54/0x2d80 [86.875398] init_module_from_file+0x96/0xe0 [86.875413] idempotent_init_module+0x117/0x330 [86.875426] __x64_sys_finit_module+0x77/0x100 [86.875440] x64_sys_call+0x24de/0x2660 [86.875454] do_syscall_64+0x91/0xe90 [86.875470] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.875486] other info that might help us debug this: [86.875502] Chain exists of: cpu_hotplug_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [86.875539] Possible unsafe locking scenario: [86.875552] CPU0 CPU1 [86.875563] ---- ---- [86.875573] lock(reservation_ww_class_mutex); [86.875588] lock(reservation_ww_class_acquire); [86.875606] lock(reservation_ww_class_mutex); [86.875624] rlock(cpu_hotplug_lock); [86.875637] *** DEADLOCK *** [86.875650] 3 locks held by i915_module_loa/1432: [86.875663] #0: ffff888101f5c1b0 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x104/0x220 [86.875699] #1: ffffc90002e0b4a0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.876512] #2: ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.877305] stack backtrace: [86.877326] CPU: 0 UID: 0 PID: 1432 Comm: i915_module_loa Tainted: G U 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 PREEMPT(voluntary) [86.877334] Tainted: [U]=USER [86.877336] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0079.2020.0420.1316 04/20/2020 [86.877339] Call Trace: [86.877344] <TASK> [86.877353] dump_stack_lvl+0x91/0xf0 [86.877364] dump_stack+0x10/0x20 [86.877369] print_circular_bug+0x285/0x360 [86.877379] check_noncircular+0x135/0x150 [86.877390] __lock_acquire+0x1635/0x2810 [86.877403] lock_acquire+0xc4/0x2f0 [86.877408] ? stop_machine+0x1c/0x50 [86.877422] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878173] cpus_read_lock+0x41/0x100 [86.878182] ? stop_machine+0x1c/0x50 [86.878191] ? __pfx_bxt_vtd_ggtt_insert_entries__cb+0x10/0x10 [i915] [86.878916] stop_machine+0x1c/0x50 [86.878927] bxt_vtd_ggtt_insert_entries__BKL+0x3b/0x60 [i915] [86.879652] intel_ggtt_bind_vma+0x43/0x70 [i915] [86.880375] __vma_bind+0x55/0x70 [i915] [86.881133] fence_work+0x26/0xa0 [i915] [86.881851] fence_notify+0xa1/0x140 [i915] [86.882566] __i915_sw_fence_complete+0x8f/0x270 [i915] [86.883286] i915_sw_fence_commit+0x39/0x60 [i915] [86.884003] i915_vma_pin_ww+0x462/0x1360 [i915] [86.884756] ? i915_vma_pin.constprop.0+0x6c/0x1d0 [i915] [86.885513] i915_vma_pin.constprop.0+0x133/0x1d0 [i915] [86.886281] initial_plane_vma+0x307/0x840 [i915] [86.887049] intel_initial_plane_config+0x33f/0x670 [i915] [86.887819] intel_display_driver_probe_nogem+0x1c6/0x260 [i915] [86.888587] i915_driver_probe+0x7fa/0xe80 [i915] [86.889293] ? mutex_unlock+0x12/0x20 [86.889301] ? drm_privacy_screen_get+0x171/0x190 [86.889308] ? acpi_dev_found+0x66/0x80 [86.889321] i915_pci_probe+0xe6/0x220 [i915] [86.890038] local_pci_probe+0x47/0xb0 [86.890049] pci_device_probe+0xf3/0x260 [86.890058] really_probe+0xf1/0x3c0 [86.890067] __driver_probe_device+0x8c/0x180 [86.890072] driver_probe_device+0x24/0xd0 [86.890078] __driver_attach+0x10f/0x220 [86.890083] ? __pfx___driver_attach+0x10/0x10 [86.890088] bus_for_each_dev+0x7f/0xe0 [86.890097] driver_attach+0x1e/0x30 [86.890101] bus_add_driver+0x151/0x290 [86.890107] driver_register+0x5e/0x130 [86.890113] __pci_register_driver+0x7d/0x90 [86.890119] i915_pci_register_driver+0x23/0x30 [i915] [86.890833] i915_init+0x37/0x120 [i915] [86.891482] ? __pfx_i915_init+0x10/0x10 [i915] [86.892135] do_one_initcall+0x60/0x3f0 [86.892145] ? __kmalloc_cache_noprof+0x33f/0x470 [86.892157] do_init_module+0x97/0x2a0 [86.892164] load_module+0x2c54/0x2d80 [86.892168] ? __kernel_read+0x15c/0x300 [86.892185] ? kernel_read_file+0x2b1/0x320 [86.892195] init_module_from_file+0x96/0xe0 [86.892199] ? init_module_from_file+0x96/0xe0 [86.892211] idempotent_init_module+0x117/0x330 [86.892224] __x64_sys_finit_module+0x77/0x100 [86.892230] x64_sys_call+0x24de/0x2660 [86.892236] do_syscall_64+0x91/0xe90 [86.892243] ? irqentry_exit+0x77/0xb0 [86.892249] ? sysvec_apic_timer_interrupt+0x57/0xc0 [86.892256] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.892261] RIP: 0033:0x7303e1b2725d [86.892271] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8b bb 0d 00 f7 d8 64 89 01 48 [86.892276] RSP: 002b:00007ffddd1fdb38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [86.892281] RAX: ffffffffffffffda RBX: 00005d771d88fd90 RCX: 00007303e1b2725d [86.892285] RDX: 0000000000000000 RSI: 00005d771d893aa0 RDI: 000000000000000c [86.892287] RBP: 00007ffddd1fdbf0 R08: 0000000000000040 R09: 00007ffddd1fdb80 [86.892289] R10: 00007303e1c03b20 R11: 0000000000000246 R12: 00005d771d893aa0 [86.892292] R13: 0000000000000000 R14: 00005d771d88f0d0 R15: 00005d771d895710 [86.892304] </TASK> Call asynchronous variant of dma_fence_work_commit() in that case. v3: Provide more verbose in-line comment (Andi), - mention target environments in commit message. Fixes: 7d1c2618eac59 ("drm/i915: Take reservation lock around i915_vma_pin.") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14985 Cc: Andi Shyti <[email protected]> Signed-off-by: Janusz Krzysztofik <[email protected]> Reviewed-by: Sebastian Brzezinka <[email protected]> Reviewed-by: Krzysztof Karas <[email protected]> Acked-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 648ef1324add1c2e2b6041cdf0b28d31fbca5f13) Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Umesh Nerlige Ramappa <[email protected]> Date: Wed Oct 15 17:03:51 2025 -0700 drm/i915: Fix conversion between clock ticks and nanoseconds [ Upstream commit 7d44ad6b43d0be43d080180413a1b6c24cfbd266 ] When tick values are large, the multiplication by NSEC_PER_SEC is larger than 64 bits and results in bad conversions. The issue is seen in PMU busyness counters that look like they have wrapped around due to bad conversion. i915 PMU implementation returns monotonically increasing counters. If a count is lesser than previous one, it will only return the larger value until the smaller value catches up. The user will see this as zero delta between two measurements even though the engines are busy. Fix it by using mul_u64_u32_div() Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14955 Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 2ada9cb1df3f5405a01d013b708b1b0914efccfe) Signed-off-by: Rodrigo Vivi <[email protected]> [Rodrigo: Added the Fixes tag while cherry-picking to fixes] Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH Lin <[email protected]> Date: Fri Aug 29 17:15:59 2025 +0800 drm/mediatek: Add pm_runtime support for GCE power control [ Upstream commit afcfb6c8474d9e750880aaa77952cc588f859613 ] Call pm_runtime_resume_and_get() before accessing GCE hardware in mbox_send_message(), and invoke pm_runtime_put_autosuspend() in the cmdq callback to release the PM reference and start autosuspend for GCE. This ensures correct power management for the GCE device. Fixes: 8afe816b0c99 ("mailbox: mtk-cmdq-mailbox: Implement Runtime PM with autosuspend") Signed-off-by: Jason-JH Lin <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Boris Brezillon <[email protected]> Date: Fri Nov 7 18:12:14 2025 +0100 drm/panthor: Flush shmem writes before mapping buffers CPU-uncached [ Upstream commit 576c930e5e7dcb937648490611a83f1bf0171048 ] The shmem layer zeroes out the new pages using cached mappings, and if we don't CPU-flush we might leave dirty cachelines behind, leading to potential data leaks and/or asynchronous buffer corruption when dirty cachelines are evicted. Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Mon Nov 3 14:19:20 2025 -0600 drm/vmwgfx: Restore Guest-Backed only cursor plane support [ Upstream commit eef295a8508202e750e4f103a97447f3c9d5e3d0 ] The referenced fixes commit broke the cursor plane for configurations which have Guest-Backed surfaces but no cursor MOB support. Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Signed-off-by: Ian Forbes <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Forbes <[email protected]> Date: Tue Oct 21 14:01:28 2025 -0500 drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE [ Upstream commit 32b415a9dc2c212e809b7ebc2b14bc3fbda2b9af ] This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access. Fixes: 8ce75f8ab904 ("drm/vmwgfx: Update device includes for DX device functionality") Reported-by: Rohit Keshri <[email protected]> Signed-off-by: Ian Forbes <[email protected]> Reviewed-by: Maaz Mombasawala <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Balasubramani Vivekanandan <[email protected]> Date: Mon Nov 3 18:01:47 2025 +0530 drm/xe/guc: Synchronize Dead CT worker with unbind [ Upstream commit 95af8f4fdce8349a5fe75264007f1af2aa1082ea ] Cancel and wait for any Dead CT worker to complete before continuing with device unbinding. Else the worker will end up using resources freed by the undind operation. Cc: Zhanjun Dong <[email protected]> Fixes: d2c5a5a926f4 ("drm/xe/guc: Dead CT helper") Signed-off-by: Balasubramani Vivekanandan <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit 492671339114e376aaa38626d637a2751cdef263) Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nitin Gote <[email protected]> Date: Mon Oct 27 14:56:43 2025 +0530 drm/xe/xe3: Add WA_14024681466 for Xe3_LPG commit 0b2f7be548006b0651e1e8320790f49723265cbc upstream. Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05. v2: (Matthew Roper) - Remove stepping filter as workaround applies to all steppings. - Add an engine class filter so it only applies to the RENDER engine. Signed-off-by: Nitin Gote <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> (cherry picked from commit 071089a69e199bd810ff31c4c933bd528e502743) Cc: [email protected] # v6.16+ Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tangudu Tilak Tirumalesh <[email protected]> Date: Thu Oct 30 21:16:26 2025 +0530 drm/xe/xe3: Extend wa_14023061436 commit fa3376319b83ba8b7fd55f2c1a268dcbf9d6eedc upstream. Extend wa_14023061436 to Graphics Versions 30.03, 30.04 and 30.05. Signed-off-by: Tangudu Tilak Tirumalesh <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> (cherry picked from commit 0dd656d06f50ae4cedf160634cf13fd9e0944cf7) Cc: [email protected] # v6.17+ Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nitin Gote <[email protected]> Date: Thu Nov 6 15:35:17 2025 +0530 drm/xe/xe3lpg: Extend Wa_15016589081 for xe3lpg commit 240372edaf854c9136f5ead45f2d8cd9496a9cb3 upstream. Wa_15016589081 applies to Xe3_LPG renderCS Signed-off-by: Nitin Gote <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Roper <[email protected]> (cherry picked from commit 715974499a2199bd199fb4630501f55545342ea4) Cc: [email protected] # v6.16+ Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jouni Högander <[email protected]> Date: Fri Oct 31 14:23:11 2025 +0200 drm/xe: Do clean shutdown also when using flr [ Upstream commit b11a020d914c3b7628f56a9ea476a5b03679489b ] Currently Xe driver is triggering flr without any clean-up on shutdown. This is causing random warnings from pending related works as the underlying hardware is reset in the middle of their execution. Fix this by performing clean shutdown also when using flr. Fixes: 501d799a47e2 ("drm/xe: Wire up device shutdown handler") Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Jouni Högander <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Maarten Lankhorst <[email protected]> (cherry picked from commit a4ff26b7c8ef38e4dd34f77cbcd73576fdde6dd4) Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tejas Upadhyay <[email protected]> Date: Tue Oct 7 15:32:08 2025 +0530 drm/xe: Move declarations under conditional branch [ Upstream commit 9cd27eec872f0b95dcdd811edc39d2d32e4158c8 ] The xe_device_shutdown() function was needing a few declarations that were only required under a specific condition. This change moves those declarations to be within that conditional branch to avoid unnecessary declarations. Reviewed-by: Nitin Gote <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Tejas Upadhyay <[email protected]> (cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b) Signed-off-by: Lucas De Marchi <[email protected]> Stable-dep-of: b11a020d914c ("drm/xe: Do clean shutdown also when using flr") Signed-off-by: Sasha Levin <[email protected]>
Author: Niravkumar L Rabara <[email protected]> Date: Tue Nov 11 16:08:01 2025 +0800 EDAC/altera: Handle OCRAM ECC enable after warm reset commit fd3ecda38fe0cb713d167b5477d25f6b350f0514 upstream. The OCRAM ECC is always enabled either by the BootROM or by the Secure Device Manager (SDM) during a power-on reset on SoCFPGA. However, during a warm reset, the OCRAM content is retained to preserve data, while the control and status registers are reset to their default values. As a result, ECC must be explicitly re-enabled after a warm reset. Fixes: 17e47dc6db4f ("EDAC/altera: Add Stratix10 OCRAM ECC support") Signed-off-by: Niravkumar L Rabara <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Dinh Nguyen <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Niravkumar L Rabara <[email protected]> Date: Tue Nov 11 16:13:33 2025 +0800 EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection commit 281326be67252ac5794d1383f67526606b1d6b13 upstream. The current single-bit error injection mechanism flips bits directly in ECC RAM by performing write and read operations. When the ECC RAM is actively used by the Ethernet or USB controller, this approach sometimes trigger a false double-bit error. Switch both Ethernet and USB EDAC devices to use the INTTEST register (altr_edac_a10_device_inject_fops) for single-bit error injection, similar to the existing double-bit error injection method. Fixes: 064acbd4f4ab ("EDAC, altera: Add Stratix10 peripheral support") Signed-off-by: Niravkumar L Rabara <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Dinh Nguyen <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gao Xiang <[email protected]> Date: Fri Oct 31 13:47:39 2025 +0800 erofs: avoid infinite loop due to incomplete zstd-compressed data [ Upstream commit f2a12cc3b97f062186568a7b94ddb7aa2ef68140 ] Currently, the decompression logic incorrectly spins if compressed data is truncated in crafted (deliberately corrupted) images. Fixes: 7c35de4df105 ("erofs: Zstandard compression support") Reported-by: Robert Morris <[email protected]> Closes: https://lore.kernel.org/r/50958.1761605413@localhost Signed-off-by: Gao Xiang <[email protected]> Reviewed-by: Chunhai Guo <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jaehun Gou <[email protected]> Date: Tue Oct 14 22:01:46 2025 +0900 exfat: fix improper check of dentry.stream.valid_size [ Upstream commit 82ebecdc74ff555daf70b811d854b1f32a296bea ] We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability. Co-developed-by: Seunghun Han <[email protected]> Signed-off-by: Seunghun Han <[email protected]> Co-developed-by: Jihoon Kwon <[email protected]> Signed-off-by: Jihoon Kwon <[email protected]> Signed-off-by: Jaehun Gou <[email protected]> Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrei Vagin <[email protected]> Date: Tue Nov 11 06:28:15 2025 +0000 fs/namespace: correctly handle errors returned by grab_requested_mnt_ns [ Upstream commit 78f0e33cd6c939a555aa80dbed2fec6b333a7660 ] grab_requested_mnt_ns was changed to return error codes on failure, but its callers were not updated to check for error pointers, still checking only for a NULL return value. This commit updates the callers to use IS_ERR() or IS_ERR_OR_NULL() and PTR_ERR() to correctly check for and propagate errors. This also makes sure that the logic actually works and mount namespace file descriptors can be used to refere to mounts. Christian Brauner <[email protected]> says: Rework the patch to be more ergonomic and in line with our overall error handling patterns. Fixes: 7b9d14af8777 ("fs: allow mount namespace fd") Cc: Christian Brauner <[email protected]> Signed-off-by: Andrei Vagin <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wei Yang <[email protected]> Date: Sat Oct 25 10:42:33 2025 +0800 fs/proc: fix uaf in proc_readdir_de() commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream. Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Wei Yang <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: wangzijie <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrey Albershteyn <[email protected]> Date: Wed Oct 8 14:44:18 2025 +0200 fs: return EOPNOTSUPP from file_setattr/file_getattr syscalls [ Upstream commit d90ad28e8aa482e397150e22f3762173d918a724 ] These syscalls call to vfs_fileattr_get/set functions which return ENOIOCTLCMD if filesystem doesn't support setting file attribute on an inode. For syscalls EOPNOTSUPP would be more appropriate return error. Signed-off-by: Andrey Albershteyn <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Song Liu <[email protected]> Date: Mon Oct 27 10:50:21 2025 -0700 ftrace: Fix BPF fexit with livepatch commit 56b3c85e153b84f27e6cff39623ba40a1ad299d3 upstream. When livepatch is attached to the same function as bpf trampoline with a fexit program, bpf trampoline code calls register_ftrace_direct() twice. The first time will fail with -EAGAIN, and the second time it will succeed. This requires register_ftrace_direct() to unregister the address on the first attempt. Otherwise, the bpf trampoline cannot attach. Here is an easy way to reproduce this issue: insmod samples/livepatch/livepatch-sample.ko bpftrace -e 'fexit:cmdline_proc_show {}' ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... Fix this by cleaning up the hash when register_ftrace_function_nolock hits errors. Also, move the code that resets ops->func and ops->trampoline to the error path of register_ftrace_direct(); and add a helper function reset_direct() in register_ftrace_direct() and unregister_ftrace_direct(). Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Cc: [email protected] # v6.6+ Reported-by: Andrey Grodzovsky <[email protected]> Closes: https://lore.kernel.org/live-patching/[email protected]/ Cc: Steven Rostedt (Google) <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Acked-and-tested-by: Andrey Grodzovsky <[email protected]> Signed-off-by: Song Liu <[email protected]> Reviewed-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Wed Jul 16 16:29:46 2025 +0200 futex: Optimize per-cpu reference counting [ Upstream commit 4cb5ac2626b5704ed712ac1d46b9d89fdfc12c5d ] Shrikanth noted that the per-cpu reference counter was still some 10% slower than the old immutable option (which removes the reference counting entirely). Further optimize the per-cpu reference counter by: - switching from RCU to preempt; - using __this_cpu_*() since we now have preempt disabled; - switching from smp_load_acquire() to READ_ONCE(). This is all safe because disabling preemption inhibits the RCU grace period exactly like rcu_read_lock(). Having preemption disabled allows using __this_cpu_*() provided the only access to the variable is in task context -- which is the case here. Furthermore, since we know changing fph->state to FR_ATOMIC demands a full RCU grace period we can rely on the implied smp_mb() from that to replace the acquire barrier(). This is very similar to the percpu_down_read_internal() fast-path. The reason this is significant for PowerPC is that it uses the generic this_cpu_*() implementation which relies on local_irq_disable() (the x86 implementation relies on it being a single memop instruction to be IRQ-safe). Switching to preempt_disable() and __this_cpu*() avoids this IRQ state swizzling. Also, PowerPC needs LWSYNC for the ACQUIRE barrier, not having to use explicit barriers safes a bunch. Combined this reduces the performance gap by half, down to some 5%. Fixes: 760e6f7befba ("futex: Remove support for IMMUTABLE") Reported-by: Shrikanth Hegde <[email protected]> Tested-by: Shrikanth Hegde <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Oberparleiter <[email protected]> Date: Tue Oct 28 12:51:25 2025 +0100 gcov: add support for GCC 15 commit ec4d11fc4b2dd4a2fa8c9d801ee9753b74623554 upstream. Using gcov on kernels compiled with GCC 15 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 15. Tested with GCC 14.3.0 and GCC 15.2.0. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Oberparleiter <[email protected]> Reported-by: Matthieu Baerts <[email protected]> Closes: https://github.com/linux-test-project/lcov/issues/445 Tested-by: Matthieu Baerts <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sami Tolvanen <[email protected]> Date: Mon Nov 10 14:19:13 2025 +0100 gendwarfksyms: Skip files with no exports commit fdf302e6bea1822a9144a0cc2e8e17527e746162 upstream. Starting with Rust 1.91.0 (released 2025-10-30), in upstream commit ab91a63d403b ("Ignore intrinsic calls in cross-crate-inlining cost model") [1][2], `bindings.o` stops containing DWARF debug information because the `Default` implementations contained `write_bytes()` calls which are now ignored in that cost model (note that `CLIPPY=1` does not reproduce it). This means `gendwarfksyms` complains: RUSTC L rust/bindings.o error: gendwarfksyms: process_module: dwarf_get_units failed: no debugging information? There are several alternatives that would work here: conditionally skipping in the cases needed (but that is subtle and brittle), forcing DWARF generation with e.g. a dummy `static` (ugly and we may need to do it in several crates), skipping the call to the tool in the Kbuild command when there are no exports (fine) or teaching the tool to do so itself (simple and clean). Thus do the last one: don't attempt to process files if we have no symbol versions to calculate. [ I used the commit log of my patch linked below since it explained the root issue and expanded it a bit more to summarize the alternatives. - Miguel ] Cc: [email protected] # Needed in 6.17.y. Reported-by: Haiyue Wang <[email protected]> Closes: https://lore.kernel.org/rust-for-linux/[email protected]/ Suggested-by: Miguel Ojeda <[email protected]> Link: https://lore.kernel.org/rust-for-linux/CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N0w6GqTF-kJOeiSw@mail.gmail.com/ Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a72984ed99 [1] Link: https://github.com/rust-lang/rust/pull/145910 [2] Signed-off-by: Sami Tolvanen <[email protected]> Tested-by: Haiyue Wang <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Ichikawa <[email protected]> Date: Sun Sep 21 14:31:02 2025 +0900 HID: hid-ntrig: Prevent memory leak in ntrig_report_version() [ Upstream commit 53f731f5bba0cf03b751ccceb98b82fadc9ccd1e ] Use a scope-based cleanup helper for the buffer allocated with kmalloc() in ntrig_report_version() to simplify the cleanup logic and prevent memory leaks (specifically the !hid_is_usb()-case one). [[email protected]: elaborate on the actual existing leak] Fixes: 185c926283da ("HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()") Signed-off-by: Masami Ichikawa <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhishek Tamboli <[email protected]> Date: Wed Sep 24 10:07:20 2025 +0530 HID: intel-thc-hid: intel-quickspi: Add ARL PCI Device Id's [ Upstream commit 50f1f782f8d621a90108340c632bcb6ab4307d2e ] Add the missing PCI ID for the quickspi device used on the Lenovo Yoga Pro 9i 16IAH10. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=220567 Signed-off-by: Abhishek Tamboli <[email protected]> Reviewed-by: Even Xu <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stuart Hayhurst <[email protected]> Date: Mon Oct 6 02:05:49 2025 +0100 HID: logitech-hidpp: Add HIDPP_QUIRK_RESET_HI_RES_SCROLL [ Upstream commit ed80cc4667ac997b84546e6d35f0a0ae525d239c ] The Logitech G502 Hero Wireless's high resolution scrolling resets after being unplugged without notifying the driver, causing extremely slow scrolling. The only indication of this is a battery update packet, so add a quirk to detect when the device is unplugged and re-enable the scrolling. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218037 Signed-off-by: Stuart Hayhurst <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vicki Pfau <[email protected]> Date: Mon Oct 6 18:05:32 2025 -0700 HID: nintendo: Wait longer for initial probe [ Upstream commit b73bc6a51f0c0066912c7e181acee41091c70fe6 ] Some third-party controllers, such as the PB Tails CHOC, won't always respond quickly on startup. Since this packet is needed for probe, and only once during probe, let's just wait an extra second, which makes connecting consistent. Signed-off-by: Vicki Pfau <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Mon Nov 10 22:45:50 2025 +0530 HID: playstation: Fix memory leak in dualshock4_get_calibration_data() [ Upstream commit 8513c154f8ad7097653dd9bf43d6155e5aad4ab3 ] The memory allocated for buf is not freed in the error paths when ps_get_report() fails. Free buf before jumping to transfer_failed label Fixes: 947992c7fa9e ("HID: playstation: DS4: Fix calibration workaround for clone devices") Signed-off-by: Abdun Nihaal <[email protected]> Reviewed-by: Silvan Jegen <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleg Makarenko <[email protected]> Date: Mon Sep 29 18:46:11 2025 +0300 HID: quirks: Add ALWAYS_POLL quirk for VRS R295 steering wheel [ Upstream commit 1141ed52348d3df82d3fd2316128b3fc6203a68c ] This patch adds ALWAYS_POLL quirk for the VRS R295 steering wheel joystick. This device reboots itself every 8-10 seconds if it is not polled. Signed-off-by: Oleg Makarenko <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tristan Lobb <[email protected]> Date: Sun Sep 28 18:25:43 2025 +0200 HID: quirks: avoid Cooler Master MM712 dongle wakeup bug [ Upstream commit 0be4253bf878d9aaa2b96031ac8683fceeb81480 ] The Cooler Master Mice Dongle includes a vendor defined HID interface alongside its mouse interface. Not polling it will cause the mouse to stop responding to polls on any interface once woken up again after going into power saving mode. Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and the Dongle's PID. Signed-off-by: Tristan Lobb <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Mon Nov 10 22:59:41 2025 +0530 HID: uclogic: Fix potential memory leak in error path [ Upstream commit a78eb69d60ce893de48dd75f725ba21309131fc2 ] In uclogic_params_ugee_v2_init_event_hooks(), the memory allocated for event_hook is not freed in the next error path. Fix that by freeing it. Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection") Signed-off-by: Abdun Nihaal <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hongbo Li <[email protected]> Date: Sat Oct 11 09:22:35 2025 +0000 hostfs: Fix only passing host root in boot stage with new mount [ Upstream commit 2c2b67af5f5f77fc68261a137ad65dcfb8e52506 ] In the old mount proceedure, hostfs could only pass root directory during boot. This is because it constructed the root directory using the @root_ino event without any mount options. However, when using it with the new mount API, this step is no longer triggered. As a result, if users mounts without specifying any mount options, the @host_root_path remains uninitialized. To prevent this issue, the @host_root_path should be initialized at the time of allocation. Reported-by: Geoffrey Thorpe <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: cd140ce9f611 ("hostfs: convert hostfs to use the new mount API") Signed-off-by: Hongbo Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Maurer <[email protected]> Date: Tue Nov 11 17:29:32 2025 +0100 hsr: Fix supervision frame sending on HSRv0 [ Upstream commit 96a3a03abf3d8cc38cd9cb0d280235fbcf7c3f7f ] On HSRv0, no supervision frames were sent. The supervison frames were generated successfully, but failed the check for a sufficiently long mac header, i.e., at least sizeof(struct hsr_ethhdr), in hsr_fill_frame_info() because the mac header only contained the ethernet header. Fix this by including the HSR header in the mac header when generating HSR supervision frames. Note that the mac header now also includes the TLV fields. This matches how we set the headers on rx and also the size of struct hsrv0_ethhdr_sp. Reported-by: Hangbin Liu <[email protected]> Closes: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/ Fixes: 9cfb5e7f0ded ("net: hsr: fix hsr_init_sk() vs network/transport headers.") Signed-off-by: Felix Maurer <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Tested-by: Sebastian Andrzej Siewior <[email protected]> Link: https://patch.msgid.link/4354114fea9a642fe71f49aeeb6c6159d1d61840.1762876095.git.fmaurer@redhat.com Tested-by: Hangbin Liu <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Maurer <[email protected]> Date: Tue Nov 11 17:29:33 2025 +0100 hsr: Follow standard for HSRv0 supervision frames [ Upstream commit b2c26c82f7a94ec4da096f370e3612ee14424450 ] For HSRv0, the path_id has the following meaning: - 0000: PRP supervision frame - 0001-1001: HSR ring identifier - 1010-1011: Frames from PRP network (A/B, with RedBoxes) - 1111: HSR supervision frame Follow the IEC 62439-3:2010 standard more closely by setting the right path_id for HSRv0 supervision frames (actually, it is correctly set when the frame is constructed, but hsr_set_path_id() overwrites it) and set a fixed HSR ring identifier of 1. The ring identifier seems to be generally unused and we ignore it anyways on reception, but some fixed identifier is definitely better than using one identifier in one direction and a wrong identifier in the other. This was also the behavior before commit f266a683a480 ("net/hsr: Better frame dispatch") which introduced the alternating path_id. This was later moved to hsr_set_path_id() in commit 451d8123f897 ("net: prp: add packet handling support"). The IEC 62439-3:2010 also contains 6 unused bytes after the MacAddressA in the HSRv0 supervision frames. Adjust a TODO comment accordingly. Fixes: f266a683a480 ("net/hsr: Better frame dispatch") Fixes: 451d8123f897 ("net: prp: add packet handling support") Signed-off-by: Felix Maurer <[email protected]> Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Link: https://patch.msgid.link/ea0d5133cd593856b2fa673d6e2067bf1d4d1794.1762876095.git.fmaurer@redhat.com Tested-by: Hangbin Liu <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Caleb Sander Mateos <[email protected]> Date: Tue Nov 11 12:15:29 2025 -0700 io_uring/rsrc: don't use blk_rq_nr_phys_segments() as number of bvecs [ Upstream commit 2d0e88f3fd1dcb37072d499c36162baf5b009d41 ] io_buffer_register_bvec() currently uses blk_rq_nr_phys_segments() as the number of bvecs in the request. However, bvecs may be split into multiple segments depending on the queue limits. Thus, the number of segments may overestimate the number of bvecs. For ublk devices, the only current users of io_buffer_register_bvec(), virt_boundary_mask, seg_boundary_mask, max_segments, and max_segment_size can all be set arbitrarily by the ublk server process. Set imu->nr_bvecs based on the number of bvecs the rq_for_each_bvec() loop actually yields. However, continue using blk_rq_nr_phys_segments() as an upper bound on the number of bvecs when allocating imu to avoid needing to iterate the bvecs a second time. Link: https://lore.kernel.org/io-uring/[email protected]/ Signed-off-by: Caleb Sander Mateos <[email protected]> Fixes: 27cb27b6d5ea ("io_uring: add support for kernel registered bvecs") Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Mon Nov 10 14:30:41 2025 -0700 io_uring/rw: ensure allocated iovec gets cleared for early failure commit d3c9c213c0b86ac5dd8fe2c53c24db20f1f510bc upstream. A previous commit reused the recyling infrastructure for early cleanup, but this is not enough for the case where our internal caches have overflowed. If this happens, then the allocated iovec can get leaked if the request is also aborted early. Reinstate the previous forced free of the iovec for that situation. Cc: [email protected] Reported-by: [email protected] Tested-by: [email protected] Fixes: 9ac273ae3dc2 ("io_uring/rw: use io_rw_recycle() from cleanup path") Link: https://lore.kernel.org/io-uring/[email protected]/ Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Wed Oct 15 13:10:31 2025 +0100 io_uring: fix unexpected placement on same size resizing [ Upstream commit 437c23357d897f5b5b7d297c477da44b56654d46 ] There might be many reasons why a user is resizing a ring, e.g. moving to huge pages or for some memory compaction using IORING_SETUP_NO_MMAP. Don't bypass resizing, the user will definitely be surprised seeing 0 while the rings weren't actually moved to a new place. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolin Chen <[email protected]> Date: Tue Oct 14 14:48:46 2025 -0700 iommufd/selftest: Fix ioctl return value in _test_cmd_trigger_vevents() [ Upstream commit b09ed52db1e688eb8205b1939ca1345179ecd515 ] The ioctl returns 0 upon success, so !0 returning -1 breaks the selftest. Drop the '!' to fix it. Fixes: 1d235d849425 ("iommu/selftest: prevent use of uninitialized variable") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Nicolin Chen <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Tue Nov 4 14:11:49 2025 -0400 iommufd: Make vfio_compat's unmap succeed if the range is already empty [ Upstream commit afb47765f9235181fddc61c8633b5a8cfae29fd2 ] iommufd returns ENOENT when attempting to unmap a range that is already empty, while vfio type1 returns success. Fix vfio_compat to match. Fixes: d624d6652a65 ("iommufd: vfio container FD ioctl compatibility") Link: https://patch.msgid.link/r/[email protected] Reviewed-by: Nicolin Chen <[email protected]> Reviewed-by: Alex Mastro <[email protected]> Reported-by: Alex Mastro <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuang Wang <[email protected]> Date: Tue Nov 11 14:43:24 2025 +0800 ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe commit ac1499fcd40fe06479e9b933347b837ccabc2a40 upstream. The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1 Cc: [email protected] Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible") Signed-off-by: Chuang Wang <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nick Hu <[email protected]> Date: Fri Nov 14 15:28:44 2025 +0800 irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops [ Upstream commit 14473a1f88596fd729e892782efc267c0097dd1d ] The irq_domain_free_irqs() helper requires that the irq_domain_ops->free callback is implemented. Otherwise, the kernel reports the warning message "NULL pointer, cannot free irq" when irq_dispose_mapping() is invoked to release the per-HART local interrupts. Set irq_domain_ops->free to irq_domain_free_irqs_top() to cure that. Fixes: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs") Signed-off-by: Nick Hu <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Abdun Nihaal <[email protected]> Date: Thu Oct 30 09:55:22 2025 +0530 isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() commit 3f978e3f1570155a1327ffa25f60968bc7b9398f upstream. In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool. Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver") Signed-off-by: Abdun Nihaal <[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: Jedrzej Jagielski <[email protected]> Date: Thu Oct 9 17:03:50 2025 -0700 ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd [ Upstream commit 823be089f9c8ab136ba382b516aedd3f7ac854bd ] Send to VF information about features supported by the PF driver. Increase API version to 1.7. Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Signed-off-by: Jedrzej Jagielski <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jedrzej Jagielski <[email protected]> Date: Thu Oct 9 17:03:48 2025 -0700 ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation [ Upstream commit f7f97cbc03a470ce405d48dedb7f135713caa0fa ] Update supported API version and provide handler for IXGBE_VF_GET_PF_LINK_STATE cmd. Simply put stored values of link speed and link_up from adapter context. Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Signed-off-by: Jedrzej Jagielski <[email protected]> Link: https://lore.kernel.org/stable/20250828095227.1857066-3-jedrzej.jagielski%40intel.com Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pratyush Yadav <[email protected]> Date: Mon Nov 3 19:02:32 2025 +0100 kho: warn and exit when unpreserved page wasn't preserved commit b05addf6f0596edb1f82ab4059438c7ef2d2686d upstream. Calling __kho_unpreserve() on a pair of (pfn, end_pfn) that wasn't preserved is a bug. Currently, if that is done, the physxa or bits can be NULL. This results in a soft lockup since a NULL physxa or bits results in redoing the loop without ever making any progress. Return when physxa or bits are not found, but WARN first to loudly indicate invalid behaviour. Link: https://lkml.kernel.org/r/[email protected] Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation") Signed-off-by: Pratyush Yadav <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Baoquan He <[email protected]> Cc: Pasha Tatashin <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pedro Demarchi Gomes <[email protected]> Date: Wed Oct 22 12:30:59 2025 -0300 ksm: use range-walk function to jump over holes in scan_get_next_rmap_item commit f5548c318d6520d4fa3c5ed6003eeb710763cbc5 upstream. Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include <unistd.h> #include <stdio.h> #include <sys/mman.h> /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/linux-mm/[email protected]/ [1] Fixes: 31dbd01f3143 ("ksm: Kernel SamePage Merging") Signed-off-by: Pedro Demarchi Gomes <[email protected]> Co-developed-by: David Hildenbrand <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Reported-by: craftfever <[email protected]> Closes: https://lkml.kernel.org/r/[email protected] Suggested-by: David Hildenbrand <[email protected]> Acked-by: David Hildenbrand <[email protected]> Cc: Chengming Zhou <[email protected]> Cc: xu xin <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joshua Rogers <[email protected]> Date: Sat Nov 8 22:59:23 2025 +0800 ksmbd: close accepted socket when per-IP limit rejects connection commit 98a5fd31cbf72d46bf18e50b3ab0ce86d5f319a9 upstream. When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath. Cc: [email protected] Signed-off-by: Joshua Rogers <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Thu Oct 30 12:27:05 2025 +0000 KVM: arm64: Make all 32bit ID registers fully writable commit 3f9eacf4f0705876a5d6526d7d320ca91d7d7a16 upstream. 32bit ID registers aren't getting much love these days, and are often missed in updates. One of these updates broke restoring a GICv2 guest on a GICv3 machine. Instead of performing a piecemeal fix, just bite the bullet and make all 32bit ID regs fully writable. KVM itself never relies on them for anything, and if the VMM wants to mess up the guest, so be it. Fixes: 5cb57a1aff755 ("KVM: arm64: Zero ID_AA64PFR0_EL1.GIC when no GICv3 is presented to the guest") Reported-by: Peter Maydell <[email protected]> Cc: [email protected] Reviewed-by: Oliver Upton <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon Nov 3 17:12:05 2025 -0800 KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dying commit ae431059e75d36170a5ae6b44cc4d06d43613215 upstream. When unbinding a memslot from a guest_memfd instance, remove the bindings even if the guest_memfd file is dying, i.e. even if its file refcount has gone to zero. If the memslot is freed before the file is fully released, nullifying the memslot side of the binding in kvm_gmem_release() will write to freed memory, as detected by syzbot+KASAN: ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022 CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 __fput+0x44c/0xa70 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbeeff8efc9 </TASK> Allocated by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2533 [inline] slab_free mm/slub.c:6622 [inline] kfree+0x19a/0x6d0 mm/slub.c:6829 kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Deliberately don't acquire filemap invalid lock when the file is dying as the lifecycle of f_mapping is outside the purview of KVM. Dereferencing the mapping is *probably* fine, but there's no need to invalidate anything as memslot deletion is responsible for zapping SPTEs, and the only code that can access the dying file is kvm_gmem_release(), whose core code is mutually exclusive with unbinding. Note, the mutual exclusivity is also what makes it safe to access the bindings on a dying gmem instance. Unbinding either runs with slots_lock held, or after the last reference to the owning "struct kvm" is put, and kvm_gmem_release() nullifies the slot pointer under slots_lock, and puts its reference to the VM after that is done. Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected] Tested-by: [email protected] Fixes: a7800aa80ea4 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") Cc: [email protected] Cc: Hillf Danton <[email protected]> Reviewed-By: Vishal Annapurve <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Sat Nov 8 00:45:20 2025 +0000 KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv() commit fbe5e5f030c22ae717ee422aaab0e00ea84fab5e upstream. svm_update_lbrv() is called when MSR_IA32_DEBUGCTLMSR is updated, and on nested transitions where LBRV is used. It checks whether LBRV enablement needs to be changed in the current VMCB, and if it does, it also recalculate intercepts to LBR MSRs. However, there are cases where intercepts need to be updated even when LBRV enablement doesn't. Example scenario: - L1 has MSR_IA32_DEBUGCTLMSR cleared. - L1 runs L2 without LBR_CTL_ENABLE (no LBRV). - L2 sets DEBUGCTLMSR_LBR in MSR_IA32_DEBUGCTLMSR, svm_update_lbrv() sets LBR_CTL_ENABLE in VMCB02 and disables intercepts to LBR MSRs. - L2 exits to L1, svm_update_lbrv() is not called on this transition. - L1 clears MSR_IA32_DEBUGCTLMSR, svm_update_lbrv() finds that LBR_CTL_ENABLE is already cleared in VMCB01 and does nothing. - Intercepts remain disabled, L1 reads to LBR MSRs read the host MSRs. Fix it by always recalculating intercepts in svm_update_lbrv(). Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Sat Nov 8 00:45:21 2025 +0000 KVM: nSVM: Fix and simplify LBR virtualization handling with nested commit 8a4821412cf2c1429fffa07c012dd150f2edf78c upstream. The current scheme for handling LBRV when nested is used is very complicated, especially when L1 does not enable LBRV (i.e. does not set LBR_CTL_ENABLE_MASK). To avoid copying LBRs between VMCB01 and VMCB02 on every nested transition, the current implementation switches between using VMCB01 or VMCB02 as the source of truth for the LBRs while L2 is running. If L2 enables LBR, VMCB02 is used as the source of truth. When L2 disables LBR, the LBRs are copied to VMCB01 and VMCB01 is used as the source of truth. This introduces significant complexity, and incorrect behavior in some cases. For example, on a nested #VMEXIT, the LBRs are only copied from VMCB02 to VMCB01 if LBRV is enabled in VMCB01. This is because L2's writes to MSR_IA32_DEBUGCTLMSR to enable LBR are intercepted and propagated to VMCB01 instead of VMCB02. However, LBRV is only enabled in VMCB02 when L2 is running. This means that if L2 enables LBR and exits to L1, the LBRs will not be propagated from VMCB02 to VMCB01, because LBRV is disabled in VMCB01. There is no meaningful difference in CPUID rate in L2 when copying LBRs on every nested transition vs. the current approach, so do the simple and correct thing and always copy LBRs between VMCB01 and VMCB02 on nested transitions (when LBRV is disabled by L1). Drop the conditional LBRs copying in __svm_{enable/disable}_lbrv() as it is now unnecessary. VMCB02 becomes the only source of truth for LBRs when L2 is running, regardless of LBRV being enabled by L1, drop svm_get_lbr_vmcb() and use svm->vmcb directly in its place. Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Sat Nov 8 00:45:19 2025 +0000 KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is updated commit dc55b3c3f61246e483e50c85d8d5366f9567e188 upstream. The APM lists the DbgCtlMsr field as being tracked by the VMCB_LBR clean bit. Always clear the bit when MSR_IA32_DEBUGCTLMSR is updated. The history is complicated, it was correctly cleared for L1 before commit 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running"). At that point svm_set_msr() started to rely on svm_update_lbrv() to clear the bit, but when nested virtualization is enabled the latter does not always clear it even if MSR_IA32_DEBUGCTLMSR changed. Go back to clearing it directly in svm_set_msr(). Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Reported-by: Matteo Rizzo <[email protected]> Reported-by: [email protected] Co-developed-by: Jim Mattson <[email protected]> Signed-off-by: Jim Mattson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sukrit Bhatnagar <[email protected]> Date: Thu Nov 6 14:28:51 2025 +0900 KVM: VMX: Fix check for valid GVA on an EPT violation commit d0164c161923ac303bd843e04ebe95cfd03c6e19 upstream. On an EPT violation, bit 7 of the exit qualification is set if the guest linear-address is valid. The derived page fault error code should not be checked for this bit. Fixes: f3009482512e ("KVM: VMX: Set PFERR_GUEST_{FINAL,PAGE}_MASK if and only if the GVA is valid") Cc: [email protected] Signed-off-by: Sukrit Bhatnagar <[email protected]> Reviewed-by: Xiaoyao Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Nov 20 14:07:07 2025 -0500 KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL [ Upstream commit 9d7dfb95da2cb5c1287df2f3468bcb70d8b31087 ] Add VMX exit handlers for SEAMCALL and TDCALL to inject a #UD if a non-TD guest attempts to execute SEAMCALL or TDCALL. Neither SEAMCALL nor TDCALL is gated by any software enablement other than VMXON, and so will generate a VM-Exit instead of e.g. a native #UD when executed from the guest kernel. Note! No unprivileged DoS of the L1 kernel is possible as TDCALL and SEAMCALL #GP at CPL > 0, and the CPL check is performed prior to the VMX non-root (VM-Exit) check, i.e. userspace can't crash the VM. And for a nested guest, KVM forwards unknown exits to L1, i.e. an L2 kernel can crash itself, but not L1. Note #2! The Intel® Trust Domain CPU Architectural Extensions spec's pseudocode shows the CPL > 0 check for SEAMCALL coming _after_ the VM-Exit, but that appears to be a documentation bug (likely because the CPL > 0 check was incorrectly bundled with other lower-priority #GP checks). Testing on SPR and EMR shows that the CPL > 0 check is performed before the VMX non-root check, i.e. SEAMCALL #GPs when executed in usermode. Note #3! The aforementioned Trust Domain spec uses confusing pseudocode that says that SEAMCALL will #UD if executed "inSEAM", but "inSEAM" specifically means in SEAM Root Mode, i.e. in the TDX-Module. The long- form description explicitly states that SEAMCALL generates an exit when executed in "SEAM VMX non-root operation". But that's a moot point as the TDX-Module injects #UD if the guest attempts to execute SEAMCALL, as documented in the "Unconditionally Blocked Instructions" section of the TDX-Module base specification. Cc: [email protected] Cc: Kai Huang <[email protected]> Cc: Xiaoyao Li <[email protected]> Cc: Rick Edgecombe <[email protected]> Cc: Dan Williams <[email protected]> Cc: Binbin Wu <[email protected]> Reviewed-by: Kai Huang <[email protected]> Reviewed-by: Binbin Wu <[email protected]> Reviewed-by: Xiaoyao Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xin Li <[email protected]> Date: Thu Nov 20 14:07:06 2025 -0500 KVM: x86: Add support for RDMSR/WRMSRNS w/ immediate on Intel [ Upstream commit 885df2d2109a60f84d84639ce6d95a91045f6c45 ] Add support for the immediate forms of RDMSR and WRMSRNS (currently Intel-only). The immediate variants are only valid in 64-bit mode, and use a single general purpose register for the data (the register is also encoded in the instruction, i.e. not implicit like regular RDMSR/WRMSR). The immediate variants are primarily motivated by performance, not code size: by having the MSR index in an immediate, it is available *much* earlier in the CPU pipeline, which allows hardware much more leeway about how a particular MSR is handled. Intel VMX support for the immediate forms of MSR accesses communicates exit information to the host as follows: 1) The immediate form of RDMSR uses VM-Exit Reason 84. 2) The immediate form of WRMSRNS uses VM-Exit Reason 85. 3) For both VM-Exit reasons 84 and 85, the Exit Qualification field is set to the MSR index that triggered the VM-Exit. 4) Bits 3 ~ 6 of the VM-Exit Instruction Information field are set to the register encoding used by the immediate form of the instruction, i.e. the destination register for RDMSR, and the source for WRMSRNS. 5) The VM-Exit Instruction Length field records the size of the immediate form of the MSR instruction. To deal with userspace RDMSR exits, stash the destination register in a new kvm_vcpu_arch field, similar to cui_linear_rip, pio, etc. Alternatively, the register could be saved in kvm_run.msr or re-retrieved from the VMCS, but the former would require sanitizing the value to ensure userspace doesn't clobber the value to an out-of-bounds index, and the latter would require a new one-off kvm_x86_ops hook. Don't bother adding support for the instructions in KVM's emulator, as the only way for RDMSR/WRMSR to be encountered is if KVM is emulating large swaths of code due to invalid guest state, and a vCPU cannot have invalid guest state while in 64-bit mode. Signed-off-by: Xin Li (Intel) <[email protected]> [sean: minor tweaks, massage and expand changelog] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Stable-dep-of: 9d7dfb95da2c ("KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Nov 20 14:07:05 2025 -0500 KVM: x86: Rename local "ecx" variables to "msr" and "pmc" as appropriate [ Upstream commit ec400f6c2f2703cb6c698dd00b28cfdb8ee5cdcc ] Rename "ecx" variables in {RD,WR}MSR and RDPMC helpers to "msr" and "pmc" respectively, in anticipation of adding support for the immediate variants of RDMSR and WRMSRNS, and to better document what the variables hold (versus where the data originated). No functional change intended. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Stable-dep-of: 9d7dfb95da2c ("KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Nov 11 12:29:23 2025 -0800 lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream. On big endian arm kernels, the arm optimized Curve25519 code produces incorrect outputs and fails the Curve25519 test. This has been true ever since this code was added. It seems that hardly anyone (or even no one?) actually uses big endian arm kernels. But as long as they're ostensibly supported, we should disable this code on them so that it's not accidentally used. Note: for future-proofing, use !CPU_BIG_ENDIAN instead of CPU_LITTLE_ENDIAN. Both of these are arch-specific options that could get removed in the future if big endian support gets dropped. Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation") Cc: [email protected] Acked-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Nov 24 10:37:52 2025 +0100 Linux 6.17.9 Link: https://lore.kernel.org/r/[email protected] Tested-by: Jon Hunter <[email protected]> Tested-by: Jeffrin Jose T <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Dileep Malepu <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Jeffrin Jose T <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Ronald Warsow <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:00 2025 +0800 LoongArch: Consolidate early_ioremap()/ioremap_prot() commit 43a9e6a10bdde32445ad2725f568e08a94e51dc9 upstream. 1. Use phys_addr_t instead of u64, which can work for both 32/64 bits. 2. Check whether the input physical address is above TO_PHYS_MASK (and return NULL if yes) for the DMW version. Note: In theory early_ioremap() also need the TO_PHYS_MASK checking, but the UEFI BIOS pass some DMW virtual addresses. Cc: [email protected] Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:01 2025 +0800 LoongArch: Consolidate max_pfn & max_low_pfn calculation commit ce5ad03e459ecb3b4993a8f311fd4f2fb3e6ef81 upstream. Now there 5 places which calculate max_pfn & max_low_pfn: 1. in fdt_setup() for FDT systems; 2. in memblock_init() for ACPI systems; 3. in init_numa_memory() for NUMA systems; 4. in arch_mem_init() to recalculate for "mem=" cmdline; 5. in paging_init() to recalculate for NUMA systems. Since memblock_init() is called both for ACPI and FDT systems, move the calculation out of the for_each_efi_memory_desc() loop can eliminate the first case. The last case is very questionable (may be derived from the MIPS/Loongson code) and breaks the "mem=" cmdline, so should be removed. And then the NUMA version of paging_init() can be also eliminated. After consolidation there are 3 places of calculation: 1. in memblock_init() for both ACPI and FDT systems; 2. in init_numa_memory() to recalculate for NUMA systems; 3. in arch_mem_init() to recalculate for the "mem=" cmdline. For all cases the calculation is: max_pfn = PFN_DOWN(memblock_end_of_DRAM()); max_low_pfn = min(PFN_DOWN(HIGHMEM_START), max_pfn); Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Sun Nov 9 16:02:09 2025 +0800 LoongArch: KVM: Add delay until timer interrupt injected commit d3c9515e4f9d10ccb113adb4809db5cc31e7ef65 upstream. When timer is fired in oneshot mode, CSR.TVAL will stop with value -1 rather than 0. However when the register CSR.TVAL is restored, it will continue to count down rather than stop there. Now the method is to write 0 to CSR.TVAL, wait to count down for 1 cycle at least, which is 10ns with a timer freq 100MHz, and then retore timer interrupt status. Here add 2 cycles delay to assure that timer interrupt is injected. With this patch, timer selftest case passes to run always. Cc: [email protected] Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Sun Nov 9 16:02:09 2025 +0800 LoongArch: KVM: Fix max supported vCPUs set with EIOINTC commit 237e74bfa261fb0cf75bd08c9be0c5094018ee20 upstream. VM fails to boot with 256 vCPUs, the detailed command is qemu-system-loongarch64 -smp 256 and there is an error reported as follows: KVM_LOONGARCH_EXTIOI_INIT_NUM_CPU failed: Invalid argument There is typo issue in function kvm_eiointc_ctrl_access() when set max supported vCPUs. Cc: [email protected] Fixes: 47256c4c8b1b ("LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_eiointc_ctrl_access()") Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bibo Mao <[email protected]> Date: Sun Nov 9 16:02:09 2025 +0800 LoongArch: KVM: Restore guest PMU if it is enabled commit 5001bcf86edf2de02f025a0f789bcac37fa040e6 upstream. On LoongArch system, guest PMU hardware is shared by guest and host but PMU interrupt is separated. PMU is pass-through to VM, and there is PMU context switch when exit to host and return to guest. There is optimiation to check whether PMU is enabled by guest. If not, it is not necessary to return to guest. However, if it is enabled, PMU context for guest need switch on. Now KVM_REQ_PMU notification is set on vCPU context switch, but it is missing if there is no vCPU context switch while PMU is used by guest VM, so fix it. Cc: <[email protected]> Fixes: f4e40ea9f78f ("LoongArch: KVM: Add PMU support for guest") Signed-off-by: Bibo Mao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tianyang Zhang <[email protected]> Date: Sun Nov 9 16:02:01 2025 +0800 LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY commit a073d637c8cfbfbab39b7272226a3fbf3b887580 upstream. Now if the PTE/PMD is dirty with _PAGE_DIRTY but without _PAGE_MODIFIED, after {pte,pmd}_modify() we lose _PAGE_DIRTY, then {pte,pmd}_dirty() return false and lead to data loss. This can happen in certain scenarios such as HW PTW doesn't set _PAGE_MODIFIED automatically, so here we need _PAGE_MODIFIED to record the dirty status (_PAGE_DIRTY). The new modification involves checking whether the original PTE/PMD has the _PAGE_DIRTY flag. If it exists, the _PAGE_MODIFIED bit is also set, ensuring that the {pte,pmd}_dirty() interface can always return accurate information. Cc: [email protected] Co-developed-by: Liupu Wang <[email protected]> Signed-off-by: Liupu Wang <[email protected]> Signed-off-by: Tianyang Zhang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:01 2025 +0800 LoongArch: Use correct accessor to read FWPC/MWPC commit eeeeaafa62ea0cd4b86390f657dc0aea73bff4f5 upstream. CSR.FWPC and CSR.MWPC are 32bit registers, so use csr_read32() rather than csr_read64() to read the values of FWPC/MWPC. Cc: [email protected] Fixes: edffa33c7bb5a73 ("LoongArch: Add hardware breakpoints/watchpoints support") Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Nov 9 16:02:00 2025 +0800 LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY commit 4e67526840fc55917581b90f6a4b65849a616dd8 upstream. Now we use virtual addresses to fill CSR_MERRENTRY/CSR_TLBRENTRY, but hardware hope physical addresses. Now it works well because the high bits are ignored above PA_BITS (48 bits), but explicitly use physical addresses can avoid potential bugs. So fix it. Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Thu Oct 30 16:55:05 2025 +0100 maple_tree: fix tracepoint string pointers commit 91a54090026f84ceffaa12ac53c99b9f162946f6 upstream. maple_tree tracepoints contain pointers to function names. Such a pointer is saved when a tracepoint logs an event. There's no guarantee that it's still valid when the event is parsed later and the pointer is dereferenced. The kernel warns about these unsafe pointers. event 'ma_read' has unsafe pointer field 'fn' WARNING: kernel/trace/trace.c:3779 at ignore_event+0x1da/0x1e4 Mark the function names as tracepoint_string() to fix the events. One case that doesn't work without my patch would be trace-cmd record to save the binary ringbuffer and trace-cmd report to parse it in userspace. The address of __func__ can't be dereferenced from userspace but tracepoint_string will add an entry to /sys/kernel/tracing/printk_formats Link: https://lkml.kernel.org/r/[email protected] Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Martin Kaiser <[email protected]> Acked-by: Liam R. Howlett <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Akiva Goldberger <[email protected]> Date: Sun Nov 9 11:49:03 2025 +0200 mlx5: Fix default values in create CQ [ Upstream commit e5eba42f01340f73888dfe560be2806057c25913 ] Currently, CQs without a completion function are assigned the mlx5_add_cq_to_tasklet function by default. This is problematic since only user CQs created through the mlx5_ib driver are intended to use this function. Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5_cq_arm. However, the default CQ creation flow leaves a valid value in the CQ's arm_db field, allowing FW to send interrupts to polling-only CQs in certain corner cases. These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception. Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause. This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values. Callers of mlx5_core_create_cq are responsible for changing the completion function and arming the CQ per their needs. Fixes: cdd04f4d4d71 ("net/mlx5: Add support to create SQ and CQ for ASO") Signed-off-by: Akiva Goldberger <[email protected]> Reviewed-by: Moshe Shemesh <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Acked-by: Leon Romanovsky <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kairui Song <[email protected]> Date: Tue Nov 11 21:36:08 2025 +0800 mm, swap: fix potential UAF issue for VMA readahead commit 1c2a936edd71e133f2806e68324ec81a4eb07588 upstream. Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning"), the common helper for allocating and preparing a folio in the swap cache layer no longer tries to get a swap device reference internally, because all callers of __read_swap_cache_async are already holding a swap entry reference. The repeated swap device pinning isn't needed on the same swap device. Caller of VMA readahead is also holding a reference to the target entry's swap device, but VMA readahead walks the page table, so it might encounter swap entries from other devices, and call __read_swap_cache_async on another device without holding a reference to it. So it is possible to cause a UAF when swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A. It's not easy to trigger, but in theory, it could cause real issues. Make VMA readahead try to get the device reference first if the swap device is a different one from the target entry. Link: https://lkml.kernel.org/r/[email protected] Fixes: 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning") Suggested-by: Huang Ying <[email protected]> Signed-off-by: Kairui Song <[email protected]> Acked-by: Chris Li <[email protected]> Cc: Baoquan He <[email protected]> Cc: Barry Song <[email protected]> Cc: Kemeng Shi <[email protected]> Cc: Nhat Pham <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quanmin Yan <[email protected]> Date: Thu Oct 30 10:07:45 2025 +0800 mm/damon/stat: change last_refresh_jiffies to a global variable commit 2f6ce7e714ef842e43120ecd6a7ed287b502026d upstream. Patch series "mm/damon: fixes for the jiffies-related issues", v2. On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make jiffies wrap bugs appear earlier. However, this may cause the time_before() series of functions to return unexpected values, resulting in DAMON not functioning as intended. Meanwhile, similar issues exist in some specific user operation scenarios. This patchset addresses these issues. The first patch is about the DAMON_STAT module, and the second patch is about the core layer's sysfs. This patch (of 2): In DAMON_STAT's damon_stat_damon_call_fn(), time_before_eq() is used to avoid unnecessarily frequent stat update. On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make jiffies wrap bugs appear earlier. However, this causes time_before_eq() in DAMON_STAT to unexpectedly return true during the first 5 minutes after boot on 32-bit systems (see [1] for more explanation, which fixes another jiffies-related issue before). As a result, DAMON_STAT does not update any monitoring results during that period, which becomes more confusing when DAMON_STAT_ENABLED_DEFAULT is enabled. There is also an issue unrelated to the system's word size[2]: if the user stops DAMON_STAT just after last_refresh_jiffies is updated and restarts it after 5 seconds or a longer delay, last_refresh_jiffies will retain an older value, causing time_before_eq() to return false and the update to happen earlier than expected. Fix these issues by making last_refresh_jiffies a global variable and initializing it each time DAMON_STAT is started. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] [1] Link: https://lore.kernel.org/all/[email protected]/ [2] Fixes: fabdd1e911da ("mm/damon/stat: calculate and expose estimated memory bandwidth") Signed-off-by: Quanmin Yan <[email protected]> Suggested-by: SeongJae Park <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Cc: Kefeng Wang <[email protected]> Cc: ze zuo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quanmin Yan <[email protected]> Date: Thu Oct 30 10:07:46 2025 +0800 mm/damon/sysfs: change next_update_jiffies to a global variable commit 9fd7bb5083d1e1027b8ac1e365c29921ab88b177 upstream. In DAMON's damon_sysfs_repeat_call_fn(), time_before() is used to compare the current jiffies with next_update_jiffies to determine whether to update the sysfs files at this moment. On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make jiffies wrap bugs appear earlier. However, this causes time_before() in damon_sysfs_repeat_call_fn() to unexpectedly return true during the first 5 minutes after boot on 32-bit systems (see [1] for more explanation, which fixes another jiffies-related issue before). As a result, DAMON does not update sysfs files during that period. There is also an issue unrelated to the system's word size[2]: if the user stops DAMON just after next_update_jiffies is updated and restarts it after 'refresh_ms' or a longer delay, next_update_jiffies will retain an older value, causing time_before() to return false and the update to happen earlier than expected. Fix these issues by making next_update_jiffies a global variable and initializing it each time DAMON is started. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] [1] Link: https://lore.kernel.org/all/[email protected]/ [2] Fixes: d809a7c64ba8 ("mm/damon/sysfs: implement refresh_ms file internal work") Suggested-by: SeongJae Park <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Signed-off-by: Quanmin Yan <[email protected]> Cc: Kefeng Wang <[email protected]> Cc: ze zuo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zi Yan <[email protected]> Date: Thu Oct 16 21:36:30 2025 -0400 mm/huge_memory: do not change split_huge_page*() target order silently commit 77008e1b2ef73249bceb078a321a3ff6bc087afb upstream. Page cache folios from a file system that support large block size (LBS) can have minimal folio order greater than 0, thus a high order folio might not be able to be split down to order-0. Commit e220917fa507 ("mm: split a folio in minimum folio order chunks") bumps the target order of split_huge_page*() to the minimum allowed order when splitting a LBS folio. This causes confusion for some split_huge_page*() callers like memory failure handling code, since they expect after-split folios all have order-0 when split succeeds but in reality get min_order_for_split() order folios and give warnings. Fix it by failing a split if the folio cannot be split to the target order. Rename try_folio_split() to try_folio_split_to_order() to reflect the added new_order parameter. Remove its unused list parameter. [The test poisons LBS folios, which cannot be split to order-0 folios, and also tries to poison all memory. The non split LBS folios take more memory than the test anticipated, leading to OOM. The patch fixed the kernel warning and the test needs some change to avoid OOM.] Link: https://lkml.kernel.org/r/[email protected] Fixes: e220917fa507 ("mm: split a folio in minimum folio order chunks") Signed-off-by: Zi Yan <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Luis Chamberlain <[email protected]> Reviewed-by: Pankaj Raghav <[email protected]> Reviewed-by: Wei Yang <[email protected]> Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Reviewed-by: Miaohe Lin <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Barry Song <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Dev Jain <[email protected]> Cc: Jane Chu <[email protected]> Cc: Lance Yang <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Mariano Pache <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Christian Brauner <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zi Yan <[email protected]> Date: Wed Nov 5 11:29:10 2025 -0500 mm/huge_memory: fix folio split check for anon folios in swapcache commit f1d47cafe513b5552a5b20a7af0936d9070a8a78 upstream. Both uniform and non uniform split check missed the check to prevent splitting anon folios in swapcache to non-zero order. Splitting anon folios in swapcache to non-zero order can cause data corruption since swapcache only support PMD order and order-0 entries. This can happen when one use split_huge_pages under debugfs to split anon folios in swapcache. In-tree callers do not perform such an illegal operation. Only debugfs interface could trigger it. I will put adding a test case on my TODO list. Fix the check. Link: https://lkml.kernel.org/r/[email protected] Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()") Signed-off-by: Zi Yan <[email protected]> Reported-by: "David Hildenbrand (Red Hat)" <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Acked-by: David Hildenbrand (Red Hat) <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Barry Song <[email protected]> Cc: Dev Jain <[email protected]> Cc: Lance Yang <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Nico Pache <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Wei Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zi Yan <[email protected]> Date: Wed Oct 22 23:05:21 2025 -0400 mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order commit fa5a061700364bc28ee1cb1095372f8033645dcb upstream. folio split clears PG_has_hwpoisoned, but the flag should be preserved in after-split folios containing pages with PG_hwpoisoned flag if the folio is split to >0 order folios. Scan all pages in a to-be-split folio to determine which after-split folios need the flag. An alternatives is to change PG_has_hwpoisoned to PG_maybe_hwpoisoned to avoid the scan and set it on all after-split folios, but resulting false positive has undesirable negative impact. To remove false positive, caller of folio_test_has_hwpoisoned() and folio_contain_hwpoisoned_page() needs to do the scan. That might be causing a hassle for current and future callers and more costly than doing the scan in the split code. More details are discussed in [1]. This issue can be exposed via: 1. splitting a has_hwpoisoned folio to >0 order from debugfs interface; 2. truncating part of a has_hwpoisoned folio in truncate_inode_partial_folio(). And later accesses to a hwpoisoned page could be possible due to the missing has_hwpoisoned folio flag. This will lead to MCE errors. Link: https://lore.kernel.org/all/CAHbLzkoOZm0PXxE9qwtF4gKR=cpRXrSrJ9V9Pm2DJexs985q4g@mail.gmail.com/ [1] Link: https://lkml.kernel.org/r/[email protected] Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Zi Yan <[email protected]> Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Yang Shi <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Reviewed-by: Lance Yang <[email protected]> Reviewed-by: Miaohe Lin <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Reviewed-by: Wei Yang <[email protected]> Cc: Pankaj Raghav <[email protected]> Cc: Barry Song <[email protected]> Cc: Dev Jain <[email protected]> Cc: Jane Chu <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Luis Chamberalin <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Nico Pache <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksei Nikiforov <[email protected]> Date: Tue Sep 30 13:56:01 2025 +0200 mm/kmsan: fix kmsan kmalloc hook when no stack depots are allocated yet commit 7e76b75e5ab3339bebab3a4738226cd9b27d8c42 upstream. If no stack depot is allocated yet, due to masking out __GFP_RECLAIM flags kmsan called from kmalloc cannot allocate stack depot. kmsan fails to record origin and report issues. This may result in KMSAN failing to report issues. Reusing flags from kmalloc without modifying them should be safe for kmsan. For example, such chain of calls is possible: test_uninit_kmalloc -> kmalloc -> __kmalloc_cache_noprof -> slab_alloc_node -> slab_post_alloc_hook -> kmsan_slab_alloc -> kmsan_internal_poison_memory. Only when it is called in a context without flags present should __GFP_RECLAIM flags be masked. With this change all kmsan tests start working reliably. Eric reported: : Yes, KMSAN seems to be at least partially broken currently. Besides the : fact that the kmsan KUnit test is currently failing (which I reported at : https://lore.kernel.org/r/20250911175145.GA1376@sol), I've confirmed that : the poly1305 KUnit test causes a KMSAN warning with Aleksei's patch : applied but does not cause a warning without it. The warning did get : reached via syzbot somehow : (https://lore.kernel.org/r/751b3d80293a6f599bb07770afcef24f623c7da0.1761026343.git.xiaopei01@kylinos.cn/), : so KMSAN must still work in some cases. But it didn't work for me. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/20251022030213.GA35717@sol Fixes: 97769a53f117 ("mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation") Signed-off-by: Aleksei Nikiforov <[email protected]> Reviewed-by: Alexander Potapenko <[email protected]> Tested-by: Eric Biggers <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Dmitriy Vyukov <[email protected]> Cc: Ilya Leoshkevich <[email protected]> Cc: Marco Elver <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kiryl Shutsemau <[email protected]> Date: Mon Oct 27 11:56:35 2025 +0000 mm/memory: do not populate page table entries beyond i_size commit 74207de2ba10c2973334906822dc94d2e859ffc5 upstream. Patch series "Fix SIGBUS semantics with large folios", v3. Accessing memory within a VMA, but beyond i_size rounded up to the next page size, is supposed to generate SIGBUS. Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749 failed due to missing SIGBUS. This was caused by my recent changes that try to fault in the whole folio where possible: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") 357b92761d94 ("mm/filemap: map entire large folio faultaround") These changes did not consider i_size when setting up PTEs, leading to xfstest breakage. However, the problem has been present in the kernel for a long time - since huge tmpfs was introduced in 2016. The kernel happily maps PMD-sized folios as PMD without checking i_size. And huge=always tmpfs allocates PMD-size folios on any writes. I considered this corner case when I implemented a large tmpfs, and my conclusion was that no one in their right mind should rely on receiving a SIGBUS signal when accessing beyond i_size. I cannot imagine how it could be useful for the workload. But apparently filesystem folks care a lot about preserving strict SIGBUS semantics. Generic/749 was introduced last year with reference to POSIX, but no real workloads were mentioned. It also acknowledged the tmpfs deviation from the test case. POSIX indeed says[3]: References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. The patchset fixes the regression introduced by recent changes as well as more subtle SIGBUS breakage due to split failure on truncation. This patch (of 2): Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. Recent changes attempted to fault in full folio where possible. They did not respect i_size, which led to populating PTEs beyond i_size and breaking SIGBUS semantics. Darrick reported generic/749 breakage because of this. However, the problem existed before the recent changes. With huge=always tmpfs, any write to a file leads to PMD-size allocation. Following the fault-in of the folio will install PMD mapping regardless of i_size. Fix filemap_map_pages() and finish_fault() to not install: - PTEs beyond i_size; - PMD mappings across i_size; Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kiryl Shutsemau <[email protected]> Fixes: 6795801366da ("xfs: Support large folios") Reported-by: "Darrick J. Wong" <[email protected]> Cc: Al Viro <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Dave Chinner <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Kiryl Shutsemau <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Isaac J. Manjarres <[email protected]> Date: Tue Oct 28 12:10:12 2025 -0700 mm/mm_init: fix hash table order logging in alloc_large_system_hash() commit 0d6c356dd6547adac2b06b461528e3573f52d953 upstream. When emitting the order of the allocation for a hash table, alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log base 2 of the allocation size. This is not correct if the allocation size is smaller than a page, and yields a negative value for the order as seen below: TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear) Use get_order() to compute the order when emitting the hash table information to correctly handle cases where the allocation size is smaller than a page: TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear) Link: https://lkml.kernel.org/r/[email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Isaac J. Manjarres <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dev Jain <[email protected]> Date: Tue Oct 28 12:09:52 2025 +0530 mm/mremap: honour writable bit in mremap pte batching commit 04d1c9d60c6ec4c0003d433572eaa45f8b217788 upstream. Currently mremap folio pte batch ignores the writable bit during figuring out a set of similar ptes mapping the same folio. Suppose that the first pte of the batch is writable while the others are not - set_ptes will end up setting the writable bit on the other ptes, which is a violation of mremap semantics. Therefore, use FPB_RESPECT_WRITE to check the writable bit while determining the pte batch. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dev Jain <[email protected]> Fixes: f822a9a81a31 ("mm: optimize mremap() by PTE batching") Reported-by: David Hildenbrand <[email protected]> Debugged-by: David Hildenbrand <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Pedro Falcato <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Barry Song <[email protected]> Cc: Jann Horn <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> [6.17+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lance Yang <[email protected]> Date: Fri Oct 31 20:09:55 2025 +0800 mm/secretmem: fix use-after-free race in fault handler commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d upstream. When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lance Yang <[email protected]> Reported-by: Google Big Sleep <[email protected]> Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWKrdQJ-ATdg@mail.gmail.com/ Acked-by: David Hildenbrand <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kairui Song <[email protected]> Date: Wed Oct 22 18:57:19 2025 +0800 mm/shmem: fix THP allocation and fallback loop commit fc745ff317566ec299e16346ebb9eacc8fe5b9d2 upstream. The order check and fallback loop is updating the index value on every loop. This will cause the index to be wrongly aligned by a larger value while the loop shrinks the order. This may result in inserting and returning a folio of the wrong index and cause data corruption with some userspace workloads [1]. [[email protected]: introduce a temporary variable to improve code] Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/ [1] Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/ [1] Fixes: e7a2ab7b3bb5 ("mm: shmem: add mTHP support for anonymous shmem") Closes: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com/ Signed-off-by: Kairui Song <[email protected]> Acked-by: David Hildenbrand <[email protected]> Acked-by: Zi Yan <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Reviewed-by: Barry Song <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Dev Jain <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Nico Pache <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shawn Lin <[email protected]> Date: Tue Nov 4 11:51:23 2025 +0800 mmc: dw_mmc-rockchip: Fix wrong internal phase calculate commit 739f04f4a46237536aff07ff223c231da53ed8ce upstream. ciu clock is 2 times of io clock, but the sample clk used is derived from io clock provided to the card. So we should use io clock to calculate the phase. Fixes: 59903441f5e4 ("mmc: dw_mmc-rockchip: Add internal phase support") Signed-off-by: Shawn Lin <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rakuram Eswaran <[email protected]> Date: Thu Oct 23 20:24:32 2025 +0530 mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs commit 9e805625218b70d865fcee2105dbf835d473c074 upstream. This patch refactors pxamci_probe() to use devm-managed resource allocation (e.g. devm_dma_request_chan) and dev_err_probe() for improved readability and automatic cleanup on probe failure. It also removes redundant NULL assignments and manual resource release logic from pxamci_probe(), and eliminates the corresponding release calls from pxamci_remove(). Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper") Suggested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Rakuram Eswaran <[email protected]> Reviewed-by: Khalid Aziz <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shawn Lin <[email protected]> Date: Mon Oct 20 09:49:41 2025 +0800 mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4 commit a28352cf2d2f8380e7aca8cb61682396dca7a991 upstream. strbin signal delay under 0x8 configuration is not stable after massive test. The recommandation of it should be 0x4. Signed-off-by: Shawn Lin <[email protected]> Tested-by: Alexey Charkov <[email protected]> Tested-by: Hugh Cole-Baker <[email protected]> Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Nov 1 16:25:48 2025 +0300 mtd: onenand: Pass correct pointer to IRQ handler [ Upstream commit 97315e7c901a1de60e8ca9b11e0e96d0f9253e18 ] This was supposed to pass "onenand" instead of "&onenand" with the ampersand. Passing a random stack address which will be gone when the function ends makes no sense. However the good thing is that the pointer is never used, so this doesn't cause a problem at run time. Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zilin Guan <[email protected]> Date: Thu Nov 6 14:45:11 2025 +0000 net/handshake: Fix memory leak in tls_handshake_accept() [ Upstream commit 3072f00bba764082fa41b3c3a2a7b013335353d2 ] In tls_handshake_accept(), a netlink message is allocated using genlmsg_new(). In the error handling path, genlmsg_cancel() is called to cancel the message construction, but the message itself is not freed. This leads to a memory leak. Fix this by calling nlmsg_free() in the error path after genlmsg_cancel() to release the allocated memory. Fixes: 2fd5532044a89 ("net/handshake: Add a kernel API for requesting a TLSv1.3 handshake") Signed-off-by: Zilin Guan <[email protected]> Reviewed-by: Chuck Lever <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cosmin Ratiu <[email protected]> Date: Tue Sep 16 17:11:35 2025 +0300 net/mlx5: Fix typo of MLX5_EQ_DOORBEL_OFFSET [ Upstream commit 917449e7c3cdc7a0dfe429de997e39098d9cdd20 ] Also convert it to a simple define. Signed-off-by: Cosmin Ratiu <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e5eba42f0134 ("mlx5: Fix default values in create CQ") Signed-off-by: Sasha Levin <[email protected]>
Author: Cosmin Ratiu <[email protected]> Date: Tue Sep 16 17:11:38 2025 +0300 net/mlx5: Store the global doorbell in mlx5_priv [ Upstream commit aa4595d0ada65d5d44fa924a42a87c175d9d88e3 ] The global doorbell is used for more than just Ethernet resources, so move it out of mlx5e_hw_objs into a common place (mlx5_priv), to avoid non-Ethernet modules (e.g. HWS, ASO) depending on Ethernet structs. Use this opportunity to consolidate it with the 'uar' pointer already there, which was used as an RX doorbell. Underneath the 'uar' pointer is identical to 'bfreg->up', so store a single resource and use that instead. For CQ doorbells, care is taken to always use bfreg->up->index instead of bfreg->index, which may refer to a subsequent UAR page from the same ALLOC_UAR batch on some NICs. This paves the way for cleanly supporting multiple doorbells in the Ethernet driver. Signed-off-by: Cosmin Ratiu <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e5eba42f0134 ("mlx5: Fix default values in create CQ") Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:51 2025 +0200 net/mlx5e: Fix maxrate wraparound in threshold between units [ Upstream commit a7bf4d5063c7837096aab2853224eb23628514d9 ] The previous calculation used roundup() which caused an overflow for rates between 25.5Gbps and 26Gbps. For example, a rate of 25.6Gbps would result in using 100Mbps units with value of 256, which would overflow the 8 bits field. Simplify the upper_limit_mbps calculation by removing the unnecessary roundup, and adjust the comparison to use <= to correctly handle the boundary condition. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-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: Carolina Jubran <[email protected]> Date: Sun Nov 9 11:37:49 2025 +0200 net/mlx5e: Fix missing error assignment in mlx5e_xfrm_add_state() [ Upstream commit 0bcd5b3b50cc1fcbf775479322cc37c15d35a489 ] Assign the return value of mlx5_eswitch_block_mode() to 'err' before checking it to avoid returning an uninitialized error code. Fixes: 22239eb258bc ("net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Closes: http://lore.kernel.org/linux-rdma/[email protected]/ Signed-off-by: Carolina Jubran <[email protected]> Reviewed-by: Jianbo Liu <[email protected]> Signed-off-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: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:53 2025 +0200 net/mlx5e: Fix potentially misleading debug message [ Upstream commit 9fcc2b6c10523f7e75db6387946c86fcf19dc97e ] Change the debug message to print the correct units instead of always assuming Gbps, as the value can be in either 100 Mbps or 1 Gbps units. Fixes: 5da8bc3effb6 ("net/mlx5e: DCBNL, Add debug messages log") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-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: Gal Pressman <[email protected]> Date: Sun Nov 9 11:37:52 2025 +0200 net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps [ Upstream commit 43b27d1bd88a4bce34ec2437d103acfae9655f9e ] Add validation to reject rates exceeding 255 Gbps that would overflow the 8 bits max bandwidth field. Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Nimrod Oren <[email protected]> Signed-off-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: Cosmin Ratiu <[email protected]> Date: Tue Sep 16 17:11:40 2025 +0300 net/mlx5e: Prepare for using different CQ doorbells [ Upstream commit a315b723e87ba4e4573e1e5c759d512f38bdc0b3 ] Completion queues (CQs) in mlx5 use the same global doorbell, which may become contended when accessed concurrently from many cores. This patch prepares the CQ management code for supporting different doorbells per CQ. This will be used in downstream patches to allow separate doorbells to be used by channels CQs. The main change is moving the 'uar' pointer from struct mlx5_core_cq to struct mlx5e_cq, as the uar page to be used is better off stored directly there. Other users of mlx5_core_cq also store the UAR to be used separately and therefore the pointer being removed is dead weight for them. As evidence, in this patch there are two users which set the mcq.uar pointer but didn't use it, Software Steering and old Innova CQ creation code. Instead, they rang the doorbell directly from another pointer. The 'uar' pointer added to struct mlx5e_cq remains in a hot cacheline (as before), because it may get accessed for each packet. Signed-off-by: Cosmin Ratiu <[email protected]> Reviewed-by: Dragos Tatulea <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: e5eba42f0134 ("mlx5: Fix default values in create CQ") Signed-off-by: Sasha Levin <[email protected]>
Author: D. Wythe <[email protected]> Date: Fri Nov 7 10:40:29 2025 +0800 net/smc: fix mismatch between CLC header and proposal [ Upstream commit ec33f2e5a2d0dbbfd71435209aee812fdc9369b8 ] The current CLC proposal message construction uses a mix of `ini->smc_type_v1/v2` and `pclc_base->hdr.typev1/v2` to decide whether to include optional extensions (IPv6 prefix extension for v1, and v2 extension). This leads to a critical inconsistency: when `smc_clc_prfx_set()` fails - for example, in IPv6-only environments with only link-local addresses, or when the local IP address and the outgoing interface’s network address are not in the same subnet. As a result, the proposal message is assembled using the stale `ini->smc_type_v1` value—causing the IPv6 prefix extension to be included even though the header indicates v1 is not supported. The peer then receives a malformed CLC proposal where the header type does not match the payload, and immediately resets the connection. The fix ensures consistency between the CLC header flags and the actual payload by synchronizing `ini->smc_type_v1` with `pclc_base->hdr.typev1` when prefix setup fails. Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal") Signed-off-by: D. Wythe <[email protected]> Reviewed-by: Alexandra Winter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Gorski <[email protected]> Date: Sun Nov 9 14:46:35 2025 +0100 net: dsa: tag_brcm: do not mark link local traffic as offloaded [ Upstream commit 762e7e174da91cf4babfe77e45bc6b67334b1503 ] Broadcom switches locally terminate link local traffic and do not forward it, so we should not mark it as offloaded. In some situations we still want/need to flood this traffic, e.g. if STP is disabled, or it is explicitly enabled via the group_fwd_mask. But if the skb is marked as offloaded, the kernel will assume this was already done in hardware, and the packets never reach other bridge ports. So ensure that link local traffic is never marked as offloaded, so that the kernel can forward/flood these packets in software if needed. Since the local termination in not configurable, check the destination MAC, and never mark packets as offloaded if it is a link local ether address. While modern switches set the tag reason code to BRCM_EG_RC_PROT_TERM for trapped link local traffic, they also set it for link local traffic that is flooded (01:80:c2:00:00:10 to 01:80:c2:00:00:2f), so we cannot use it and need to look at the destination address for them as well. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Fixes: 0e62f543bed0 ("net: dsa: Fix duplicate frames flooded by learning") Signed-off-by: Jonas Gorski <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aksh Garg <[email protected]> Date: Thu Nov 6 14:53:05 2025 +0530 net: ethernet: ti: am65-cpsw-qos: fix IET verify retry mechanism [ Upstream commit d4b00d132d7cb70a74bc039c91c1d6120943c71b ] The am65_cpsw_iet_verify_wait() function attempts verification 20 times, toggling the AM65_CPSW_PN_IET_MAC_LINKFAIL bit in each iteration. When the LINKFAIL bit transitions from 1 to 0, the MAC merge layer initiates the verification process and waits for the timeout configured in MAC_VERIFY_CNT before automatically retransmitting. The MAC_VERIFY_CNT register is configured according to the user-defined verify/response timeout in am65_cpsw_iet_set_verify_timeout_count(). As per IEEE 802.3 Clause 99, the hardware performs this automatic retry up to 3 times. Current implementation toggles LINKFAIL after the user-configured verify/response timeout in each iteration, forcing the hardware to restart verification instead of respecting the MAC_VERIFY_CNT timeout. This bypasses the hardware's automatic retry mechanism. Fix this by moving the LINKFAIL bit toggle outside the retry loop and reducing the retry count from 20 to 3. The software now only monitors the status register while the hardware autonomously handles the 3 verification attempts at proper MAC_VERIFY_CNT intervals. Fixes: 49a2eb9068246 ("net: ethernet: ti: am65-cpsw-qos: Add Frame Preemption MAC Merge support") Signed-off-by: Aksh Garg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aksh Garg <[email protected]> Date: Thu Nov 6 14:53:04 2025 +0530 net: ethernet: ti: am65-cpsw-qos: fix IET verify/response timeout [ Upstream commit 49b3916465176a5abcb29a0e464825f553d55d58 ] The CPSW module uses the MAC_VERIFY_CNT bit field in the CPSW_PN_IET_VERIFY_REG_k register to set the verify/response timeout count. This register specifies the number of clock cycles to wait before resending a verify packet if the verification fails. The verify/response timeout count, as being set by the function am65_cpsw_iet_set_verify_timeout_count() is hardcoded for 125MHz clock frequency, which varies based on PHY mode and link speed. The respective clock frequencies are as follows: - RGMII mode: * 1000 Mbps: 125 MHz * 100 Mbps: 25 MHz * 10 Mbps: 2.5 MHz - QSGMII/SGMII mode: 125 MHz (all speeds) Fix this by adding logic to calculate the correct timeout counts based on the actual PHY interface mode and link speed. Fixes: 49a2eb9068246 ("net: ethernet: ti: am65-cpsw-qos: Add Frame Preemption MAC Merge support") Signed-off-by: Aksh Garg <[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 Nov 6 10:14:21 2025 +0800 net: fec: correct rx_bytes statistic for the case SHIFT16 is set [ Upstream commit ad17e7e92a7c52ce70bb764813fcf99464f96903 ] Two additional bytes in front of each frame received into the RX FIFO if SHIFT16 is set, so we need to subtract the extra two bytes from pkt_len to correct the statistic of rx_bytes. Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware") Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Buday Csaba <[email protected]> Date: Sat Nov 8 07:49:22 2025 +0100 net: mdio: fix resource leak in mdiobus_register_device() [ Upstream commit e6ca8f533ed41129fcf052297718f417f021cc7d ] Fix a possible leak in mdiobus_register_device() when both a reset-gpio and a reset-controller are present. Clean up the already claimed reset-gpio, when the registration of the reset-controller fails, so when an error code is returned, the device retains its state before the registration attempt. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 71dd6c0dff51 ("net: phy: add support for reset-controller") Signed-off-by: Buday Csaba <[email protected]> Link: https://patch.msgid.link/4b419377f8dd7d2f63f919d0f74a336c734f8fff.1762584481.git.buday.csaba@prolan.hu Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Breno Leitao <[email protected]> Date: Fri Nov 7 06:03:37 2025 -0800 net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 upstream. commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior. Cc: <[email protected]> # 3.17.x Cc: Jay Vosburgh <[email protected]> Fixes: efa95b01da18 ("netpoll: fix use after free") Signed-off-by: Breno Leitao <[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: Horatiu Vultur <[email protected]> Date: Thu Sep 25 08:47:02 2025 +0200 net: phy: micrel: Fix lan8814_config_init commit bf91f4bc9c1dfba75e457e6a5f11e3cda658729a upstream. The blamed commit introduced the function lanphy_modify_page_reg which as name suggests it, it modifies the registers. In the same commit we have started to use this function inside the drivers. The problem is that in the function lan8814_config_init we passed the wrong page number when disabling the aneg towards host side. We passed extended page number 4(LAN8814_PAGE_COMMON_REGS) instead of extended page 5(LAN8814_PAGE_PORT_REGS) Fixes: a0de636ed7a264 ("net: phy: micrel: Introduce lanphy_modify_page_reg") Signed-off-by: Horatiu Vultur <[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: Horatiu Vultur <[email protected]> Date: Mon Aug 18 09:51:19 2025 +0200 net: phy: micrel: Introduce lanphy_modify_page_reg [ Upstream commit a0de636ed7a264a329c6a9c7d50727af02138536 ] As the name suggests this function modifies the register in an extended page. It has the same parameters as phy_modify_mmd. This function was introduce because there are many places in the code where the registers was read then the value was modified and written back. So replace all this code with this function to make it clear. Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Horatiu Vultur <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Stable-dep-of: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface") Signed-off-by: Sasha Levin <[email protected]>
Author: Horatiu Vultur <[email protected]> Date: Thu Nov 6 10:06:37 2025 +0100 net: phy: micrel: lan8814 fix reset of the QSGMII interface [ Upstream commit 96a9178a29a6b84bb632ebeb4e84cf61191c73d5 ] The lan8814 is a quad-phy and it is using QSGMII towards the MAC. The problem is that everytime when one of the ports is configured then the PCS is reseted for all the PHYs. Meaning that the other ports can loose traffic until the link is establish again. To fix this, do the reset one time for the entire PHY package. Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") Signed-off-by: Horatiu Vultur <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Divya Koppera <[email protected] > Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Horatiu Vultur <[email protected]> Date: Mon Aug 18 09:51:20 2025 +0200 net: phy: micrel: Replace hardcoded pages with defines [ Upstream commit d471793a9b67bbe3d7198ff695004190fd7b6bc7 ] The functions lan_*_page_reg gets as a second parameter the page where the register is. In all the functions the page was hardcoded. Replace the hardcoded values with defines to make it more clear what are those parameters. Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Horatiu Vultur <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Stable-dep-of: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface") Signed-off-by: Sasha Levin <[email protected]>
Author: Ranganath V N <[email protected]> Date: Sun Nov 9 14:43:35 2025 +0530 net: sched: act_connmark: initialize struct tc_ife to fix kernel leak [ Upstream commit 62b656e43eaeae445a39cd8021a4f47065af4389 ] In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: [email protected] Fixes: 22a5dc0e5e3e ("net: sched: Introduce connmark action") Signed-off-by: Ranganath V N <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Cong Wang <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranganath V N <[email protected]> Date: Sun Nov 9 14:43:36 2025 +0530 net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak [ Upstream commit ce50039be49eea9b4cd8873ca6eccded1b4a130a ] Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee Tested-by: [email protected] Fixes: ef6980b6becb ("introduce IFE action") Signed-off-by: Ranganath V N <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Cong Wang <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Nov 9 16:12:15 2025 +0000 net_sched: limit try_bulk_dequeue_skb() batches [ Upstream commit 0345552a653ce5542affeb69ac5aa52177a5199b ] After commit 100dfa74cad9 ("inet: dev_queue_xmit() llist adoption") I started seeing many qdisc requeues on IDPF under high TX workload. $ tc -s qd sh dev eth1 handle 1: ; sleep 1; tc -s qd sh dev eth1 handle 1: qdisc mq 1: root Sent 43534617319319 bytes 268186451819 pkt (dropped 0, overlimits 0 requeues 3532840114) backlog 1056Kb 6675p requeues 3532840114 qdisc mq 1: root Sent 43554665866695 bytes 268309964788 pkt (dropped 0, overlimits 0 requeues 3537737653) backlog 781164b 4822p requeues 3537737653 This is caused by try_bulk_dequeue_skb() being only limited by BQL budget. perf record -C120-239 -e qdisc:qdisc_dequeue sleep 1 ; perf script ... netperf 75332 [146] 2711.138269: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1292 skbaddr=0xff378005a1e9f200 netperf 75332 [146] 2711.138953: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1213 skbaddr=0xff378004d607a500 netperf 75330 [144] 2711.139631: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1233 skbaddr=0xff3780046be20100 netperf 75333 [147] 2711.140356: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1093 skbaddr=0xff37800514845b00 netperf 75337 [151] 2711.141037: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1353 skbaddr=0xff37800460753300 netperf 75337 [151] 2711.141877: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1367 skbaddr=0xff378004e72c7b00 netperf 75330 [144] 2711.142643: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1202 skbaddr=0xff3780045bd60000 ... This is bad because : 1) Large batches hold one victim cpu for a very long time. 2) Driver often hit their own TX ring limit (all slots are used). 3) We call dev_requeue_skb() 4) Requeues are using a FIFO (q->gso_skb), breaking qdisc ability to implement FQ or priority scheduling. 5) dequeue_skb() gets packets from q->gso_skb one skb at a time with no xmit_more support. This is causing many spinlock games between the qdisc and the device driver. Requeues were supposed to be very rare, lets keep them this way. Limit batch sizes to /proc/sys/net/core/dev_weight (default 64) as __qdisc_run() was designed to use. Fixes: 5772e9a3463b ("qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrii Melnychenko <[email protected]> Date: Fri Oct 24 18:22:16 2025 +0200 netfilter: nft_ct: add seqadj extension for natted connections [ Upstream commit 90918e3b6404c2a37837b8f11692471b4c512de2 ] Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq. The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" } } table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } } } Note that the ftp helper gets assigned *after* the dnat setup. The inverse (nat after helper assign) is handled by an existing check in nf_nat_setup_info() and will not show the problem. Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection. Kernel logs: Missing nfct_seqadj_ext_add() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41 [..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 .. Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding. Fixes: 1a64edf54f55 ("netfilter: nft_ct: add helper set support") Signed-off-by: Andrii Melnychenko <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joshua Watt <[email protected]> Date: Tue Oct 7 15:22:58 2025 -0600 NFS4: Apply delay_retrans to async operations [ Upstream commit 7a84394f02ab1985ebbe0a8d6f6d69bd040de4b3 ] The setting of delay_retrans is applied to synchronous RPC operations because the retransmit count is stored in same struct nfs4_exception that is passed each time an error is checked. However, for asynchronous operations (READ, WRITE, LOCKU, CLOSE, DELEGRETURN), a new struct nfs4_exception is made on the stack each time the task callback is invoked. This means that the retransmit count is always zero and thus delay_retrans never takes effect. Apply delay_retrans to these operations by tracking and updating their retransmit count. Change-Id: Ieb33e046c2b277cb979caa3faca7f52faf0568c9 Signed-off-by: Joshua Watt <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joshua Watt <[email protected]> Date: Thu Oct 9 15:48:04 2025 -0600 NFS4: Fix state renewals missing after boot [ Upstream commit 9bb3baa9d1604cd20f49ae7dac9306b4037a0e7a ] Since the last renewal time was initialized to 0 and jiffies start counting at -5 minutes, any clients connected in the first 5 minutes after a reboot would have their renewal timer set to a very long interval. If the connection was idle, this would result in the client state timing out on the server and the next call to the server would return NFS4ERR_BADSESSION. Fix this by initializing the last renewal time to the current jiffies instead of 0. Signed-off-by: Joshua Watt <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Scott Mayhew <[email protected]> Date: Thu Oct 9 16:42:12 2025 -0400 NFS: check if suid/sgid was cleared after a write as needed [ Upstream commit 9ff022f3820a31507cb93be6661bf5f3ca0609a4 ] I noticed xfstests generic/193 and generic/355 started failing against knfsd after commit e7a8ebc305f2 ("NFSD: Offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE"). I ran those same tests against ONTAP (which has had write delegation support for a lot longer than knfsd) and they fail there too... so while it's a new failure against knfsd, it isn't an entirely new failure. Add the NFS_INO_REVAL_FORCED flag so that the presence of a delegation doesn't keep the inode from being revalidated to fetch the updated mode. Signed-off-by: Scott Mayhew <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:36 2025 -0400 NFS: Check the TLS certificate fields in nfs_match_client() [ Upstream commit fb2cba0854a7f315c8100a807a6959b99d72479e ] If the TLS security policy is of type RPC_XPRTSEC_TLS_X509, then the cert_serial and privkey_serial fields need to match as well since they define the client's identity, as presented to the server. Fixes: 90c9550a8d65 ("NFS: support the kernel keyring for TLS") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dai Ngo <[email protected]> Date: Sun Nov 9 09:05:08 2025 -0800 NFS: Fix LTP test failures when timestamps are delegated [ Upstream commit b623390045a81fc559decb9bfeb79319721d3dfb ] The utimes01 and utime06 tests fail when delegated timestamps are enabled, specifically in subtests that modify the atime and mtime fields using the 'nobody' user ID. The problem can be reproduced as follow: # echo "/media *(rw,no_root_squash,sync)" >> /etc/exports # export -ra # mount -o rw,nfsvers=4.2 127.0.0.1:/media /tmpdir # cd /opt/ltp # ./runltp -d /tmpdir -s utimes01 # ./runltp -d /tmpdir -s utime06 This issue occurs because nfs_setattr does not verify the inode's UID against the caller's fsuid when delegated timestamps are permitted for the inode. This patch adds the UID check and if it does not match then the request is sent to the server for permission checking. Fixes: e12912d94137 ("NFSv4: Add support for delegated atime and mtime attributes") Signed-off-by: Dai Ngo <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Xiuwei <[email protected]> Date: Thu Oct 30 11:03:25 2025 +0800 NFS: sysfs: fix leak when nfs_client kobject add fails [ Upstream commit 7a7a3456520b309a0bffa1d9d62bd6c9dcab89b3 ] If adding the second kobject fails, drop both references to avoid sysfs residue and memory leak. Fixes: e96f9268eea6 ("NFS: Make all of /sys/fs/nfs network-namespace unique") Signed-off-by: Yang Xiuwei <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Thu Oct 9 16:37:59 2025 -0400 nfsd: add missing FATTR4_WORD2_CLONE_BLKSIZE from supported attributes commit 4d3dbc2386fe051e44efad663e0ec828b98ab53f upstream. RFC 7862 Section 4.1.2 says that if the server supports CLONE it MUST support clone_blksize attribute. Fixes: d6ca7d2643ee ("NFSD: Implement FATTR4_CLONE_BLKSIZE attribute") Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: NeilBrown <[email protected]> Date: Wed Oct 8 09:52:25 2025 -0400 nfsd: fix refcount leak in nfsd_set_fh_dentry() commit 8a7348a9ed70bda1c1f51d3f1815bcbdf9f3b38c upstream. nfsd exports a "pseudo root filesystem" which is used by NFSv4 to find the various exported filesystems using LOOKUP requests from a known root filehandle. NFSv3 uses the MOUNT protocol to find those exported filesystems and so is not given access to the pseudo root filesystem. If a v3 (or v2) client uses a filehandle from that filesystem, nfsd_set_fh_dentry() will report an error, but still stores the export in "struct svc_fh" even though it also drops the reference (exp_put()). This means that when fh_put() is called an extra reference will be dropped which can lead to use-after-free and possible denial of service. Normal NFS usage will not provide a pseudo-root filehandle to a v3 client. This bug can only be triggered by the client synthesising an incorrect filehandle. To fix this we move the assignments to the svc_fh later, after all possible error cases have been detected. Reported-and-tested-by: tianshuo han <[email protected]> Fixes: ef7f6c4904d0 ("nfsd: move V4ROOT version check to nfsd_set_fh_dentry()") Signed-off-by: NeilBrown <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Cc: [email protected] Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Tue Oct 14 13:59:59 2025 -0400 NFSD: free copynotify stateid in nfs4_free_ol_stateid() commit 4aa17144d5abc3c756883e3a010246f0dba8b468 upstream. Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs Reported-by: [email protected] Closes: https://lore.kernel.org/linux-nfs/[email protected]/T/#t Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation") Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chuck Lever <[email protected]> Date: Thu Oct 16 09:49:55 2025 -0400 NFSD: Skip close replay processing if XDR encoding fails [ Upstream commit ff8141e49cf70d2d093a5228f5299ce188de6142 ] The replay logic added by commit 9411b1d4c7df ("nfsd4: cleanup handling of nfsv4.0 closed stateid's") cannot be done if encoding failed due to a short send buffer; there's no guarantee that the operation encoder has actually encoded the data that is being copied to the replay cache. Reported-by: [email protected] Closes: https://lore.kernel.org/linux-nfs/[email protected]/T/#t Fixes: 9411b1d4c7df ("nfsd4: cleanup handling of nfsv4.0 closed stateid's") Reviewed-by: Jeff Layton <[email protected]> Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Tue Oct 28 17:27:43 2025 -0400 NFSv2/v3: Fix error handling in nfs_atomic_open_v23() [ Upstream commit 85d2c2392ac6348e1171d627497034a341a250c1 ] When nfs_do_create() returns an EEXIST error, it means that a regular file could not be created. That could mean that a symlink needs to be resolved. If that's the case, a lookup needs to be kicked off. Reported-by: Stephen Abbene <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220710 Fixes: 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.") Signed-off-by: Trond Myklebust <[email protected]> Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Fri Oct 31 10:51:42 2025 -0400 NFSv4: Fix an incorrect parameter when calling nfs4_call_sync() [ Upstream commit 1f214e9c3aef2d0936be971072e991d78a174d71 ] The Smatch static checker noted that in _nfs4_proc_lookupp(), the flag RPC_TASK_TIMEOUT is being passed as an argument to nfs4_init_sequence(), which is clearly incorrect. Since LOOKUPP is an idempotent operation, nfs4_init_sequence() should not ask the server to cache the result. The RPC_TASK_TIMEOUT flag needs to be passed down to the RPC layer. Reported-by: Dan Carpenter <[email protected]> Reported-by: Harshit Mogalapalli <[email protected]> Fixes: 76998ebb9158 ("NFSv4: Observe the NFS_MOUNT_SOFTREVAL flag in _nfs4_proc_lookupp") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edward Adam Davis <[email protected]> Date: Thu Oct 30 07:51:52 2025 +0900 nilfs2: avoid having an active sc_timer before freeing sci commit 9a6b60cb147d53968753a34805211d2e5e08c027 upstream. Because kthread_stop did not stop sc_task properly and returned -EINTR, the sc_timer was not properly closed, ultimately causing the problem [1] reported by syzbot when freeing sci due to the sc_timer not being closed. Because the thread sc_task main function nilfs_segctor_thread() returns 0 when it succeeds, when the return value of kthread_stop() is not 0 in nilfs_segctor_destroy(), we believe that it has not properly closed sc_timer. We use timer_shutdown_sync() to sync wait for sc_timer to shutdown, and set the value of sc_task to NULL under the protection of lock sc_state_lock, so as to avoid the issue caused by sc_timer not being properly shutdowned. [1] ODEBUG: free active (active state 0) object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout Call trace: nilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline] nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c:2877 nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509 Link: https://lkml.kernel.org/r/[email protected] Fixes: 3f66cc261ccb ("nilfs2: use kthread_create and kthread_stop for the log writer thread") Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=24d8b70f039151f65590 Tested-by: [email protected] Signed-off-by: Edward Adam Davis <[email protected]> Cc: <[email protected]> [6.12+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Wed Nov 12 21:57:08 2025 -0300 perf build: Don't fail fast path feature detection when binutils-devel is not available [ Upstream commit a09e5967ad6819379fd31894634d7aed29c18409 ] This is one more remnant of the BUILD_NONDISTRO series to make building with binutils-devel opt-in due to license incompatibility. In this case just the references at link time were still in place, which make building the test-all.bin file fail, which wasn't detected before probably because the last test was done with binutils-devel available, doh. Now: $ rpm -q binutils-devel package binutils-devel is not installed $ file /tmp/build/perf-tools/feature/test-all.bin /tmp/build/perf-tools/feature/test-all.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4b5388a346b51f1b993f0b0dbd49f4570769b03c, for GNU/Linux 3.2.0, not stripped $ Fixes: 970ae86307718c34 ("perf build: The bfd features are opt-in, stop testing for them by default") Reviewed-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Falcon <[email protected]> Date: Fri Nov 7 11:31:50 2025 -0600 perf header: Write bpf_prog (infos|btfs)_cnt to data file [ Upstream commit 85c894a80ac46aa177df04e0a33bcad409b7d64f ] With commit f0d0f978f3f5830a ("perf header: Don't write empty BPF/BTF info"), the write_bpf_( prog_info() | btf() ) functions exit without writing anything if env->bpf_prog.(infos| btfs)_cnt is zero. process_bpf_( prog_info() | btf() ), however, still expect a "count" value to exist in the data file. If btf information is empty, for example, process_bpf_btf will read garbage or some other data as the number of btf nodes in the data file. As a result, the data file will not be processed correctly. Instead, write the count to the data file and exit if it is zero. Fixes: f0d0f978f3f5830a ("perf header: Don't write empty BPF/BTF info") Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Thomas Falcon <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ravi Bangoria <[email protected]> Date: Thu Nov 13 16:01:23 2025 +0000 perf lock: Fix segfault due to missing kernel map [ Upstream commit d0206db94b36c998c11458cfdae2f45ba20bc4fb ] Kernel maps are encoded in PERF_RECORD_MMAP2 samples but "perf lock report" and "perf lock contention" do not process MMAP2 samples. Because of that, machine->vmlinux_map stays NULL and any later access triggers a segmentation fault. Fix it by adding ->mmap2() callbacks. Fixes: 53b00ff358dc75b1 ("perf record: Make --buildid-mmap the default") Reported-by: Tycho Andersen (AMD) <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Ravi Bangoria <[email protected]> Tested-by: Tycho Andersen (AMD) <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ananth Narayan <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sandipan Das <[email protected]> Cc: Santosh Shukla <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Aug 21 09:38:18 2025 -0700 perf test shell lock_contention: Extra debug diagnostics [ Upstream commit 8b93f8933d37591d17c59fd71b18fc61966d9515 ] In test_record_concurrent, as stderr is sent to /dev/null, error messages are hidden. Change this to gather the error messages and dump them on failure. Some minor sh->bash changes to add some more diagnostics in trap_cleanup. Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Blake Jones <[email protected]> Cc: Chun-Tse Shao <[email protected]> Cc: Collin Funk <[email protected]> Cc: Howard Chu <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jan Polensky <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Li Huafei <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Nam Cao <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steinar H. Gunderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Stable-dep-of: 3c723f449723 ("perf test: Fix lock contention test") Signed-off-by: Sasha Levin <[email protected]>
Author: Ravi Bangoria <[email protected]> Date: Thu Nov 13 16:01:24 2025 +0000 perf test: Fix lock contention test [ Upstream commit 3c723f449723db2dc2b75b7efe03c2a76e4c09f0 ] Couple of independent fixes: 1. Wire in SIGSEGV handler that terminates the test with a failure code. 2. Use "--lock-cgroup" instead of "-g"; "-g" was proposed but never merged. See commit 4d1792d0a2564caf ("perf lock contention: Add --lock-cgroup option") 3. Call cleanup() on every normal exit so trap_cleanup() doesn't mistake it for an unexpected signal and emit a false-negative "Unexpected signal in main" message. Before patch: # ./perf test -vv "lock contention" 85: kernel lock contention analysis test: --- start --- test child forked, pid 610711 Testing perf lock record and perf lock contention Testing perf lock contention --use-bpf Testing perf lock record and perf lock contention at the same time Testing perf lock contention --threads Testing perf lock contention --lock-addr Testing perf lock contention --lock-cgroup Unexpected signal in test_aggr_cgroup ---- end(0) ---- 85: kernel lock contention analysis test : Ok After patch: # ./perf test -vv "lock contention" 85: kernel lock contention analysis test: --- start --- test child forked, pid 602637 Testing perf lock record and perf lock contention Testing perf lock contention --use-bpf Testing perf lock record and perf lock contention at the same time Testing perf lock contention --threads Testing perf lock contention --lock-addr Testing perf lock contention --lock-cgroup Testing perf lock contention --type-filter (w/ spinlock) Testing perf lock contention --lock-filter (w/ tasklist_lock) Testing perf lock contention --callstack-filter (w/ unix_stream) [Skip] Could not find 'unix_stream' Testing perf lock contention --callstack-filter with task aggregation [Skip] Could not find 'unix_stream' Testing perf lock contention --cgroup-filter Testing perf lock contention CSV output ---- end(0) ---- 85: kernel lock contention analysis test : Ok Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Ravi Bangoria <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ananth Narayan <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sandipan Das <[email protected]> Cc: Santosh Shukla <[email protected]> Cc: Tycho Andersen <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Wed Nov 5 22:51:05 2025 -0600 PM: hibernate: Emit an error when image writing fails commit 62b9ca1706e1bbb60d945a58de7c7b5826f6b2a2 upstream. If image writing fails, a return code is passed up to the caller, but none of the callers log anything to the log and so the only record of it is the return code that userspace gets. Adjust the logging so that the image size and speed of writing is only emitted on success and if there is an error, it's saved to the logs. Fixes: a06c6f5d3cc9 ("PM: hibernate: Move to crypto APIs for LZO compression") Reported-by: Askar Safin <[email protected]> Closes: https://lore.kernel.org/linux-pm/[email protected]/ Signed-off-by: Mario Limonciello (AMD) <[email protected]> Tested-by: Askar Safin <[email protected]> Cc: 6.9+ <[email protected]> # 6.9+ [ rjw: Added missing braces after "else", changelog edits ] Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mario Limonciello (AMD) <[email protected]> Date: Wed Nov 5 22:51:06 2025 -0600 PM: hibernate: Use atomic64_t for compressed_size variable commit 66ededc694f1d06a71ca35a3c8e3689e9b85b3ce upstream. `compressed_size` can overflow, showing nonsensical values. Change from `atomic_t` to `atomic64_t` to prevent overflow. Fixes: a06c6f5d3cc9 ("PM: hibernate: Move to crypto APIs for LZO compression") Reported-by: Askar Safin <[email protected]> Closes: https://lore.kernel.org/linux-pm/[email protected]/ Signed-off-by: Mario Limonciello (AMD) <[email protected]> Tested-by: Askar Safin <[email protected]> Cc: 6.9+ <[email protected]> # 6.9+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sudeep Holla <[email protected]> Date: Fri Oct 17 12:03:20 2025 +0100 pmdomain: arm: scmi: Fix genpd leak on provider registration failure commit 7458f72cc28f9eb0de811effcb5376d0ec19094a upstream. If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20 Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd") Signed-off-by: Sudeep Holla <[email protected]> Reviewed-by: Peng Fan <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Tue Oct 28 11:16:20 2025 +0800 pmdomain: imx: Fix reference count leak in imx_gpc_remove commit bbde14682eba21d86f5f3d6fe2d371b1f97f1e61 upstream. of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add the missing of_node_put() to avoid refcount leak. Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: [email protected] Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: André Draszik <[email protected]> Date: Thu Oct 16 16:58:37 2025 +0100 pmdomain: samsung: plug potential memleak during probe commit 90c82941adf1986364e0f82c35cf59f2bf5f6a1d upstream. of_genpd_add_provider_simple() could fail, in which case this code leaks the domain name, pd->pd.name. Use devm_kstrdup_const() to plug this leak. As a side-effect, we can simplify existing error handling. Fixes: c09a3e6c97f0 ("soc: samsung: pm_domains: Convert to regular platform driver") Cc: [email protected] Reviewed-by: Peter Griffin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: André Draszik <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Szyprowski <[email protected]> Date: Mon Oct 27 13:55:15 2025 +0100 pmdomain: samsung: Rework legacy splash-screen handover workaround commit fccac54b0d3d0602f177bb79f203ae6fbea0e32a upstream. Limit the workaround for the lack of the proper splash-screen handover handling to the legacy ARM 32bit systems and replace forcing a sync_state by explicite power domain shutdown. This approach lets compiler to optimize it out on newer ARM 64bit systems. Suggested-by: Ulf Hansson <[email protected]> Fixes: 0745658aebbe ("pmdomain: samsung: Fix splash-screen handover by enforcing a sync_state") Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:33 2025 -0400 pnfs: Fix TLS logic in _nfs4_pnfs_v3_ds_connect() [ Upstream commit 7aca00d950e782e66c34fbd045c9605eca343a36 ] Don't try to add an RDMA transport to a client that is already marked as being a TCP/TLS transport. Fixes: 04a15263662a ("pnfs/flexfiles: connect to NFSv3 DS using TLS if MDS connection uses TLS") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:34 2025 -0400 pnfs: Fix TLS logic in _nfs4_pnfs_v4_ds_connect() [ Upstream commit 28e19737e1570c7c71890547c2e43c3e0da79df9 ] Don't try to add an RDMA transport to a client that is already marked as being a TCP/TLS transport. Fixes: a35518cae4b3 ("NFSv4.1/pnfs: fix NFS with TLS in pnfs") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Oct 18 20:10:35 2025 -0400 pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS [ Upstream commit 8ab523ce78d4ca13add6b4ecbacff0f84c274603 ] The default setting for the transport security policy must be RPC_XPRTSEC_NONE, when using a TCP or RDMA connection without TLS. Conversely, when using TLS, the security policy needs to be set. Fixes: 6c0a8c5fcf71 ("NFS: Have struct nfs_client carry a TLS policy field") Signed-off-by: Trond Myklebust <[email protected]> Reviewed-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eslam Khafagy <[email protected]> Date: Fri Nov 14 14:27:39 2025 +0200 posix-timers: Plug potential memory leak in do_timer_create() [ Upstream commit e0fd4d42e27f761e9cc82801b3f183e658dc749d ] When posix timer creation is set to allocate a given timer ID and the access to the user space value faults, the function terminates without freeing the already allocated posix timer structure. Move the allocation after the user space access to cure that. [ tglx: Massaged change log ] Fixes: ec2d0c04624b3 ("posix-timers: Provide a mechanism to allocate a given timer ID") Reported-by: [email protected] Suggested-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Eslam Khafagy <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Frederic Weisbecker <[email protected]> Link: https://patch.msgid.link/[email protected] Closes: https://lore.kernel.org/all/[email protected]/T/ Signed-off-by: Sasha Levin <[email protected]>
Author: Luke Wang <[email protected]> Date: Fri Nov 14 14:53:08 2025 +0800 pwm: adp5585: Correct mismatched pwm chip info [ Upstream commit f84fd5bec502447df145f31734793714690ce27f ] The register addresses of ADP5585 and ADP5589 are swapped. Fixes: 75024f97e82e ("pwm: adp5585: add support for adp5589") Signed-off-by: Luke Wang <[email protected]> Acked-by: Nuno Sá <[email protected]> Tested-by: Liu Ying <[email protected]> # ADP5585 PWM Link: https://patch.msgid.link/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haotian Zhang <[email protected]> Date: Wed Oct 29 01:28:28 2025 +0800 regulator: fixed: fix GPIO descriptor leak on register failure [ Upstream commit 636f4618b1cd96f6b5a2b8c7c4f665c8533ecf13 ] In the commit referenced by the Fixes tag, devm_gpiod_get_optional() was replaced by manual GPIO management, relying on the regulator core to release the GPIO descriptor. However, this approach does not account for the error path: when regulator registration fails, the core never takes over the GPIO, resulting in a resource leak. Add gpiod_put() before returning on regulator registration failure. Fixes: 5e6f3ae5c13b ("regulator: fixed: Let core handle GPIO descriptor") Signed-off-by: Haotian Zhang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Danil Skrebenkov <[email protected]> Date: Fri Sep 19 16:28:46 2025 +0300 RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors [ Upstream commit ae9e9f3d67dcef7582a4524047b01e33c5185ddb ] openSBI v1.7 adds harts checks for ipi operations. Especially it adds comparison between hmask passed as an argument from linux and mask of online harts (from openSBI side). If they don't fit each other the error occurs. When cpu is offline, cpu_online_mask is explicitly cleared in __cpu_disable. However, there is no explicit clearing of mm_cpumask. mm_cpumask is used for rfence operations that call openSBI RFENCE extension which uses ipi to remote harts. If hart is offline there may be error if mask of linux is not as mask of online harts in openSBI. this patch adds explicit clearing of mm_cpumask for offline hart. Signed-off-by: Danil Skrebenkov <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: rewrote subject line for clarity] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Han Gao <[email protected]> Date: Wed Sep 10 19:24:01 2025 +0800 riscv: acpi: avoid errors caused by probing DT devices when ACPI is used [ Upstream commit 69a8b62a7aa1e54ff7623064f6507fa29c1d0d4e ] Similar to the ARM64 commit 3505f30fb6a9s ("ARM64 / ACPI: If we chose to boot from acpi then disable FDT"), let's not do DT hardware probing if ACPI is enabled in early boot. This avoids errors caused by repeated driver probing. Signed-off-by: Han Gao <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: cleaned up patch description and subject] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Feng Jiang <[email protected]> Date: Wed Oct 29 17:44:28 2025 +0800 riscv: Build loader.bin exclusively for Canaan K210 [ Upstream commit 3ad1b71fdc5707d14332d9ae710a237de936be9b ] According to the explanation in commit ef10bdf9c3e6 ("riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210"), loader.bin is a special feature of the Canaan K210 and is not applicable to other SoCs. Fixes: e79dfcbfb902 ("riscv: make image compression configurable") Signed-off-by: Feng Jiang <[email protected]> Reviewed-by: Emil Renner Berthing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paul Walmsley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xi Ruoyao <[email protected]> Date: Sun Nov 9 16:01:50 2025 +0800 rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags [ Upstream commit fe4b3a34e9a9654d98d274218dac0270779db0ae ] It's used to work around an objtool issue since commit abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference"), but it's then passed to bindgen and cause an error because Clang does not have this option. Fixes: abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference") Acked-by: Miguel Ojeda <[email protected]> Tested-by: Mingcong Bai <[email protected]> Signed-off-by: Xi Ruoyao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zqiang <[email protected]> Date: Wed Nov 12 15:33:28 2025 +0800 sched_ext: Fix unsafe locking in the scx_dump_state() [ Upstream commit 5f02151c411dda46efcc5dc57b0845efcdcfc26d ] For built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be converted sleepable spinlock and not disable-irq, so the following scenarios occur: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes: (&rq->__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40 {IN-HARDIRQ-W} state was registered at: lock_acquire+0x1e1/0x510 _raw_spin_lock_nested+0x42/0x80 raw_spin_rq_lock_nested+0x2b/0x40 sched_tick+0xae/0x7b0 update_process_times+0x14c/0x1b0 tick_periodic+0x62/0x1f0 tick_handle_periodic+0x48/0xf0 timer_interrupt+0x55/0x80 __handle_irq_event_percpu+0x20a/0x5c0 handle_irq_event_percpu+0x18/0xc0 handle_irq_event+0xb5/0x150 handle_level_irq+0x220/0x460 __common_interrupt+0xa2/0x1e0 common_interrupt+0xb0/0xd0 asm_common_interrupt+0x2b/0x40 _raw_spin_unlock_irqrestore+0x45/0x80 __setup_irq+0xc34/0x1a30 request_threaded_irq+0x214/0x2f0 hpet_time_init+0x3e/0x60 x86_late_time_init+0x5b/0xb0 start_kernel+0x308/0x410 x86_64_start_reservations+0x1c/0x30 x86_64_start_kernel+0x96/0xa0 common_startup_64+0x13e/0x148 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rq->__lock); <Interrupt> lock(&rq->__lock); *** DEADLOCK *** stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 print_usage_bug+0x42e/0x690 mark_lock.part.44+0x867/0xa70 ? __pfx_mark_lock.part.44+0x10/0x10 ? string_nocheck+0x19c/0x310 ? number+0x739/0x9f0 ? __pfx_string_nocheck+0x10/0x10 ? __pfx_check_pointer+0x10/0x10 ? kvm_sched_clock_read+0x15/0x30 ? sched_clock_noinstr+0xd/0x20 ? local_clock_noinstr+0x1c/0xe0 __lock_acquire+0xc4b/0x62b0 ? __pfx_format_decode+0x10/0x10 ? __pfx_string+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 lock_acquire+0x1e1/0x510 ? raw_spin_rq_lock_nested+0x2b/0x40 ? __pfx_lock_acquire+0x10/0x10 ? dump_line+0x12e/0x270 ? raw_spin_rq_lock_nested+0x20/0x40 _raw_spin_lock_nested+0x42/0x80 ? raw_spin_rq_lock_nested+0x2b/0x40 raw_spin_rq_lock_nested+0x2b/0x40 scx_dump_state+0x3b3/0x1270 ? finish_task_switch+0x27e/0x840 scx_ops_error_irq_workfn+0x67/0x80 irq_work_single+0x113/0x260 irq_work_run_list.part.3+0x44/0x70 run_irq_workd+0x6b/0x90 ? __pfx_run_irq_workd+0x10/0x10 smpboot_thread_fn+0x529/0x870 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x305/0x3f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x40/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This commit therefore use rq_lock_irqsave/irqrestore() to replace rq_lock/unlock() in the scx_dump_state(). Fixes: 07814a9439a3 ("sched_ext: Print debug dump after an error exit") Signed-off-by: Zqiang <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Llamas <[email protected]> Date: Thu Oct 30 01:03:33 2025 +0000 scripts/decode_stacktrace.sh: fix build ID and PC source parsing commit 7d9f7d390f6af3a29614e81e802e2b9c238eb7b2 upstream. Support for parsing PC source info in stacktraces (e.g. '(P)') was added in commit 2bff77c665ed ("scripts/decode_stacktrace.sh: fix decoding of lines with an additional info"). However, this logic was placed after the build ID processing. This incorrect order fails to parse lines containing both elements, e.g.: drm_gem_mmap_obj+0x114/0x200 [drm 03d0564e0529947d67bb2008c3548be77279fd27] (P) This patch fixes the problem by extracting the PC source info first and then processing the module build ID. With this change, the line above is now properly parsed as such: drm_gem_mmap_obj (./include/linux/mmap_lock.h:212 ./include/linux/mm.h:811 drivers/gpu/drm/drm_gem.c:1177) drm (P) While here, also add a brief explanation the build ID section. Link: https://lkml.kernel.org/r/[email protected] Fixes: 2bff77c665ed ("scripts/decode_stacktrace.sh: fix decoding of lines with an additional info") Signed-off-by: Carlos Llamas <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Cc: Breno Leitao <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Marc Rutland <[email protected]> Cc: Mark Brown <[email protected]> Cc: Matthieu Baerts <[email protected]> Cc: Miroslav Benes <[email protected]> Cc: Puranjay Mohan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Sep 8 17:41:57 2025 +0200 scripts/decode_stacktrace.sh: symbol: avoid trailing whitespaces commit d322f6a24ee5964a58294f61bf96a1b6404c676d upstream. A few patches slightly improving the output generated by decode_stacktrace.sh. This patch (of 3): Lines having a symbol to decode might not always have info after this symbol. It means ${info_str} might not be set, but it will always be printed after a space, causing trailing whitespaces. That's a detail, but when the output is opened with an editor marking these trailing whitespaces, that's a bit disturbing. It is easy to remove them by printing this variable with a space only if it is set. While at it, do the same with ${module} and print everything in one line. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Carlos Llamas <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Elliot Berman <[email protected]> Cc: Stephen Boyd <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Sep 8 17:41:58 2025 +0200 scripts/decode_stacktrace.sh: symbol: preserve alignment commit 4a2fc4897b5e0ca1e7a3cb4e32f44c7db3367dee upstream. With lines having a symbol to decode, the script was only trying to preserve the alignment for the timestamps, but not the rest, nor when the caller was set (CONFIG_PRINTK_CALLER=y). With this sample ... [ 52.080924] Call Trace: [ 52.080926] <TASK> [ 52.080931] dump_stack_lvl+0x6f/0xb0 ... the script was producing the following output: [ 52.080924] Call Trace: [ 52.080926] <TASK> [ 52.080931] dump_stack_lvl (arch/x86/include/asm/irqflags.h:19) (dump_stack_lvl is no longer aligned with <TASK>: one missing space) With this other sample ... [ 52.080924][ T48] Call Trace: [ 52.080926][ T48] <TASK> [ 52.080931][ T48] dump_stack_lvl+0x6f/0xb0 ... the script was producing the following output: [ 52.080924][ T48] Call Trace: [ 52.080926][ T48] <TASK> [ 52.080931][ T48] dump_stack_lvl (arch/x86/include/asm/irqflags.h:19) (the misalignment is clearer here) That's because the script had a workaround for CONFIG_PRINTK_TIME=y only, see the previous comment called "Format timestamps with tabs". To always preserve spaces, they need to be recorded along the words. That is what is now done with the new 'spaces' array. Some notes: - 'extglob' is needed only for this operation, and that's why it is set in a dedicated subshell. - 'read' is used with '-r' not to treat a <backslash> character in any special way, e.g. when followed by a space. - When a word is removed from the 'words' array, the corresponding space needs to be removed from the 'spaces' array as well. With the last sample, we now have: [ 52.080924][ T48] Call Trace: [ 52.080926][ T48] <TASK> [ 52.080931][ T48] dump_stack_lvl (arch/x86/include/asm/irqflags.h:19) (the alignment is preserved) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Tested-by: Carlos Llamas <[email protected]> Cc: Breno Leitao <[email protected]> Cc: Elliot Berman <[email protected]> Cc: Luca Ceresoli <[email protected]> Cc: Stephen Boyd <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu Nov 6 11:10:54 2025 +0000 sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto [ Upstream commit 1534ff77757e44bcc4b98d0196bc5c0052fce5fa ] syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline] Fixes: b58537a1f562 ("net: sctp: fix permissions for rto_alpha and rto_beta knobs") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Cc: Daniel Borkmann <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Tue Oct 28 12:27:24 2025 -0400 selftests/tracing: Run sample events to clear page cache events commit dd4adb986a86727ed8f56c48b6d0695f1e211e65 upstream. The tracing selftest "event-filter-function.tc" was failing because it first runs the "sample_events" function that triggers the kmem_cache_free event and it looks at what function was used during a call to "ls". But the first time it calls this, it could trigger events that are used to pull pages into the page cache. The rest of the test uses the function it finds during that call to see if it will be called in subsequent "sample_events" calls. But if there's no need to pull pages into the page cache, it will not trigger that function and the test will fail. Call the "sample_events" twice to trigger all the page cache work before it calls it to find a function to use in subsequent checks. Cc: [email protected] Fixes: eb50d0f250e96 ("selftests/ftrace: Choose target function for filter test from samples") Signed-off-by: Steven Rostedt (Google) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ankit Khushwaha <[email protected]> Date: Thu Nov 6 15:25:32 2025 +0530 selftests/user_events: fix type cast for write_index packed member in perf_test commit 216158f063fe24fb003bd7da0cd92cd6e2c4d48b upstream. Accessing 'reg.write_index' directly triggers a -Waddress-of-packed-member warning due to potential unaligned pointer access: perf_test.c:239:38: warning: taking address of packed member 'write_index' of class or structure 'user_reg' may result in an unaligned pointer value [-Waddress-of-packed-member] 239 | ASSERT_NE(-1, write(self->data_fd, ®.write_index, | ^~~~~~~~~~~~~~~ Since write(2) works with any alignment. Casting '®.write_index' explicitly to 'void *' to suppress this warning. Link: https://lkml.kernel.org/r/[email protected] Fixes: 42187bdc3ca4 ("selftests/user_events: Add perf self-test for empty arguments events") Signed-off-by: Ankit Khushwaha <[email protected]> Cc: Beau Belgrave <[email protected]> Cc: "Masami Hiramatsu (Google)" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: sunliming <[email protected]> Cc: Wei Yang <[email protected]> Cc: Shuah Khan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:40 2025 +0100 selftests: mptcp: connect: fix fallback note due to OoO commit 63c643aa7b7287fdbb0167063785f89ece3f000f upstream. The "fallback due to TCP OoO" was never printed because the stat_ooo_now variable was checked twice: once in the parent if-statement, and one in the child one. The second condition was then always true then, and the 'else' branch was never taken. The idea is that when there are more ACK + MP_CAPABLE than expected, the test either fails if there was no out of order packets, or a notice is printed. Fixes: 69ca3d29a755 ("mptcp: update selftest for fallback due to OoO") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-1-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:44 2025 +0100 selftests: mptcp: connect: trunc: read all recv data commit ee79980f7a428ec299f6261bea4c1084dcbc9631 upstream. MPTCP Join "fastclose server" selftest is sometimes failing because the client output file doesn't have the expected size, e.g. 296B instead of 1024B. When looking at a packet trace when this happens, the server sent the expected 1024B in two parts -- 100B, then 924B -- then the MP_FASTCLOSE. It is then strange to see the client only receiving 296B, which would mean it only got a part of the second packet. The problem is then not on the networking side, but rather on the data reception side. When mptcp_connect is launched with '-f -1', it means the connection might stop before having sent everything, because a reset has been received. When this happens, the program was directly stopped. But it is also possible there are still some data to read, simply because the previous 'read' step was done with a buffer smaller than the pending data, see do_rnd_read(). In this case, it is important to read what's left in the kernel buffers before stopping without error like before. SIGPIPE is now ignored, not to quit the app before having read everything. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-5-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:42 2025 +0100 selftests: mptcp: join: endpoints: longer transfer commit 6457595db9870298ee30b6d75287b8548e33fe19 upstream. In rare cases, when the test environment is very slow, some userspace tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to make the connection longer. This connection will be killed at the end, after the verifications, so making it longer doesn't change anything, apart from avoid it to end before the end of the verifications To play it safe, all endpoints tests not waiting for the end of the transfer are now sharing a longer file (128KB) at slow speed. Fixes: 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case") Cc: [email protected] Fixes: e274f7154008 ("selftests: mptcp: add subflow limits test-cases") Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Fixes: e06959e9eebd ("selftests: mptcp: join: test for flush/re-add endpoints") Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-3-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:45 2025 +0100 selftests: mptcp: join: properly kill background tasks commit 852b644acbce1529307a4bb283752c4e77b5cda7 upstream. The 'run_tests' function is executed in the background, but killing its associated PID would not kill the children tasks running in the background. To properly kill all background tasks, 'kill -- -PID' could be used, but this requires kill from procps-ng. Instead, all children tasks are listed using 'ps', and 'kill' is called with all PIDs of this group. Fixes: 31ee4ad86afd ("selftests: mptcp: join: stop transfer when check is done (part 1)") Cc: [email protected] Fixes: 04b57c9e096a ("selftests: mptcp: join: stop transfer when check is done (part 2)") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-6-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:41 2025 +0100 selftests: mptcp: join: rm: set backup flag commit aea73bae662a0e184393d6d7d0feb18d2577b9b9 upstream. Some of these 'remove' tests rarely fail because a subflow has been reset instead of cleanly removed. This can happen when one extra subflow which has never carried data is being closed (FIN) on one side, while the other is sending data for the first time. To avoid such subflows to be used right at the end, the backup flag has been added. With that, data will be only carried on the initial subflow. Fixes: d2c4333a801c ("selftests: mptcp: add testcases for removing addrs") Cc: [email protected] Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-2-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Mon Nov 10 19:23:43 2025 +0100 selftests: mptcp: join: userspace: longer transfer commit 290493078b96ce2ce3e60f55c23654acb678042a upstream. In rare cases, when the test environment is very slow, some userspace tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to make the connection longer. This connection will be killed at the end, after the verifications, so making it longer doesn't change anything, apart from avoid it to end before the end of the verifications To play it safe, all userspace tests not waiting for the end of the transfer are now sharing a longer file (128KB) at slow speed. Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") Cc: [email protected] Fixes: b2e2248f365a ("selftests: mptcp: userspace pm create id 0 subflow") Fixes: e3b47e460b4b ("selftests: mptcp: userspace pm remove initial subflow") Fixes: b9fb176081fb ("selftests: mptcp: userspace pm send RM_ADDR for ID 0") Reviewed-by: Geliang Tang <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-4-a4332c714e10@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Sverdlin <[email protected]> Date: Thu Nov 6 17:12:09 2025 +0100 selftests: net: local_termination: Wait for interfaces to come up [ Upstream commit 57531b3416448d1ced36a2a974a4085ec43d57b0 ] It seems that most of the tests prepare the interfaces once before the test run (setup_prepare()), rely on setup_wait() to wait for link and only then run the test(s). local_termination brings the physical interfaces down and up during test run but never wait for them to come up. If the auto-negotiation takes some seconds, first test packets are being lost, which leads to false-negative test results. Use setup_wait() in run_test() to make sure auto-negotiation has been completed after all simple_if_init() calls on physical interfaces and test packets will not be lost because of the race against link establishment. Fixes: 90b9566aa5cd3f ("selftests: forwarding: add a test for local_termination.sh") Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: Alexander Sverdlin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Fri Sep 12 11:52:41 2025 -0400 simplify nfs_atomic_open_v23() [ Upstream commit aae9db5739164353fa1894db000fabad940a835b ] 1) finish_no_open() takes ERR_PTR() as dentry now. 2) caller of ->atomic_open() will call d_lookup_done() itself, no need to do it here. Reviewed-by: NeilBrown <[email protected]> Signed-off-by: Al Viro <[email protected]> Stable-dep-of: 85d2c2392ac6 ("NFSv2/v3: Fix error handling in nfs_atomic_open_v23()") Signed-off-by: Sasha Levin <[email protected]>
Author: ZhangGuoDong <[email protected]> Date: Sun Oct 12 00:47:59 2025 +0800 smb/server: fix possible memory leak in smb2_read() [ Upstream commit 6fced056d2cc8d01b326e6fcfabaacb9850b71a4 ] Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree(). Co-developed-by: ChenXiaoSong <[email protected]> Signed-off-by: ChenXiaoSong <[email protected]> Signed-off-by: ZhangGuoDong <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: ZhangGuoDong <[email protected]> Date: Sun Oct 12 00:51:36 2025 +0800 smb/server: fix possible refcount leak in smb2_sess_setup() [ Upstream commit 379510a815cb2e64eb0a379cb62295d6ade65df0 ] Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put(). Co-developed-by: ChenXiaoSong <[email protected]> Signed-off-by: ChenXiaoSong <[email protected]> Signed-off-by: ZhangGuoDong <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Henrique Carvalho <[email protected]> Date: Fri Nov 7 18:59:53 2025 -0300 smb: client: fix cifs_pick_channel when channel needs reconnect commit 79280191c2fd7f24899bbd640003b5389d3c109c upstream. cifs_pick_channel iterates candidate channels using cur. The reconnect-state test mistakenly used a different variable. This checked the wrong slot and would cause us to skip a healthy channel and to dispatch on one that needs reconnect, occasionally failing operations when a channel was down. Fix by replacing for the correct variable. Fixes: fc43a8ac396d ("cifs: cifs_pick_channel should try selecting active channels") Cc: [email protected] Reviewed-by: Shyam Prasad N <[email protected]> Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuhao Fu <[email protected]> Date: Tue Nov 4 23:13:15 2025 +0800 smb: client: fix refcount leak in smb2_set_path_attr [ Upstream commit b540de9e3b4fab3b9e10f30714a6f5c1b2a50ec3 ] Fix refcount leak in `smb2_set_path_attr` when path conversion fails. Function `cifs_get_writable_path` returns `cfile` with its reference counter `cfile->count` increased on success. Function `smb2_compound_op` would decrease the reference counter for `cfile`, as stated in its comment. By calling `smb2_rename_path`, the reference counter of `cfile` would leak if `cifs_convert_path_to_utf16` fails in `smb2_set_path_attr`. Fixes: 8de9e86c67ba ("cifs: create a helper to find a writeable handle by path name") Acked-by: Henrique Carvalho <[email protected]> Signed-off-by: Shuhao Fu <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Nov 2 20:09:21 2025 +0100 spi: Try to get ACPI GPIO IRQ earlier commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream. Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device. If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables. Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet. Link: https://bbs.archlinux.org/viewtopic.php?id=302348 Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nate Karstens <[email protected]> Date: Thu Nov 6 16:28:33 2025 -0600 strparser: Fix signed/unsigned mismatch bug commit 4da4e4bde1c453ac5cc2dce5def81d504ae257ee upstream. The `len` member of the sk_buff is an unsigned int. This is cast to `ssize_t` (a signed type) for the first sk_buff in the comparison, but not the second sk_buff. On 32-bit systems, this can result in an integer underflow for certain values because unsigned arithmetic is being used. This appears to be an oversight: if the intention was to use unsigned arithmetic, then the first cast would have been omitted. The change ensures both len values are cast to `ssize_t`. The underflow causes an issue with ktls when multiple TLS PDUs are included in a single TCP segment. The mainline kernel does not use strparser for ktls anymore, but this is still useful for other features that still use strparser, and for backporting. Signed-off-by: Nate Karstens <[email protected]> Cc: [email protected] Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Sabrina Dubroca <[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: Kuniyuki Iwashima <[email protected]> Date: Fri Nov 7 06:40:25 2025 +0000 tipc: Fix use-after-free in tipc_mon_reinit_self(). [ Upstream commit 0725e6afb55128be21a2ca36e9674f573ccec173 ] syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6088: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kfree+0x195/0x550 mm/slub.c:4894 tipc_l2_device_event+0x380/0x650 net/tipc/bearer.c:-1 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] unregister_netdevice_many_notify+0x14d7/0x1fe0 net/core/dev.c:12166 unregister_netdevice_many net/core/dev.c:12229 [inline] unregister_netdevice_queue+0x33c/0x380 net/core/dev.c:12073 unregister_netdevice include/linux/netdevice.h:3385 [inline] __tun_detach+0xe4d/0x1620 drivers/net/tun.c:621 tun_detach drivers/net/tun.c:637 [inline] tun_chr_close+0x10d/0x1c0 drivers/net/tun.c:3433 __fput+0x458/0xa80 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alok Tiwari <[email protected]> Date: Mon Oct 27 03:46:47 2025 -0700 virtio-fs: fix incorrect check for fsvq->kobj [ Upstream commit c014021253d77cd89b2d8788ce522283d83fbd40 ] In virtio_fs_add_queues_sysfs(), the code incorrectly checks fs->mqs_kobj after calling kobject_create_and_add(). Change the check to fsvq->kobj (fs->mqs_kobj -> fsvq->kobj) to ensure the per-queue kobject is successfully created. Fixes: 87cbdc396a31 ("virtio_fs: add sysfs entries for queue information") Signed-off-by: Alok Tiwari <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xuan Zhuo <[email protected]> Date: Tue Nov 11 17:08:28 2025 +0800 virtio-net: fix incorrect flags recording in big mode [ Upstream commit 0eff2eaa5322b5b141ff5d5ded26fac4a52b5f7b ] The purpose of commit 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") is to record the flags in advance, as their value may be overwritten in the XDP case. However, the flags recorded under big mode are incorrect, because in big mode, the passed buf does not point to the rx buffer, but rather to the page of the submitted buffer. This commit fixes this issue. For the small mode, the commit c11a49d58ad2 ("virtio_net: Fix mismatched buf address when unmapping for small packets") fixed it. Tested-by: Alyssa Ross <[email protected]> Fixes: 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") Signed-off-by: Xuan Zhuo <[email protected]> Acked-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Escande <[email protected]> Date: Tue Nov 4 09:39:57 2025 +0100 wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp() [ Upstream commit 9065b968752334f972e0d48e50c4463a172fc2a7 ] When reporting tx completion using ieee80211_tx_status_xxx() family of functions, the status part of the struct ieee80211_tx_info nested in the skb is used to report things like transmit rates & retry count to mac80211 On the TX data path, this is correctly memset to 0 before calling ieee80211_tx_status_ext(), but on the tx mgmt path this was not done. This leads to mac80211 treating garbage values as valid transmit counters (like tx retries for example) and accounting them as real statistics that makes their way to userland via station dump. The same issue was resolved in ath12k by commit 9903c0986f78 ("wifi: ath12k: Add memset and update default rate value in wmi tx completion") Tested-on: QCN9074 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande <[email protected]> Reviewed-by: Vasanthakumar Thiagarajan <[email protected]> Reviewed-by: Baochen Qiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Mon Nov 10 14:57:00 2025 +0200 wifi: iwlwifi: mld: always take beacon ies in link grading [ Upstream commit 1a222625b468effd13d1ebb662c36a41c28a835a ] One of the factors of a link's grade is the channel load, which is calculated from the AP's bss load element. The current code takes this element from the beacon for an active link, and from bss->ies for an inactive link. bss->ies is set to either the beacon's ies or to the probe response ones, with preference to the probe response (meaning that if there was even one probe response, the ies of it will be stored in bss->ies and won't be overiden by the beacon ies). The probe response can be very old, i.e. from the connection time, where a beacon is updated before each link selection (which is triggered only after a passive scan). In such case, the bss load element in the probe response will not include the channel load caused by the STA, where the beacon will. This will cause the inactive link to always have a lower channel load, and therefore an higher grade than the active link's one. This causes repeated link switches, causing the throughput to drop. Fix this by always taking the ies from the beacon, as those are for sure new. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110145652.b493dbb1853a.I058ba7309c84159f640cc9682d1bda56dd56a536@changeid Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Oct 8 11:20:44 2025 +0200 wifi: iwlwifi: mvm: fix beacon template/fixed rate [ Upstream commit 3592c0083fb29cca13cd9978b8844d58b4eff548 ] During the development of the rate changes, I evidently made some changes that shouldn't have been there; beacon templates with rate_n_flags are only in old versions, so no changes to them should have been necessary, and evidently broke on some devices. This also would have broken fixed (injection) rates, it would seem. Restore the old handling of this. Fixes: dabc88cb3b78 ("wifi: iwlwifi: handle v3 rates") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220558 Reviewed-by: Benjamin Berg <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Link: https://patch.msgid.link/20251008112044.3bb8ea849d8d.I90f4d2b2c1f62eaedaf304a61d2ab9e50c491c2d@changeid Signed-off-by: Miri Korenblit <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Nov 5 15:41:19 2025 +0100 wifi: mac80211: reject address change while connecting commit a9da90e618cd0669a22bcc06a96209db5dd96e9b upstream. While connecting, the MAC address can already no longer be changed. The change is already rejected if netif_carrier_ok(), but of course that's not true yet while connecting. Check for auth_data or assoc_data, so the MAC address cannot be changed. Also more comprehensively check that there are no stations on the interface being changed - if any peer station is added it will know about our address already, so we cannot change it. Cc: [email protected] Fixes: 3c06e91b40db ("wifi: mac80211: Support POWERED_ADDR_CHANGE feature") Link: https://patch.msgid.link/20251105154119.f9f6c1df81bb.I9bb3760ede650fb96588be0d09a5a7bdec21b217@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Benjamin Berg <[email protected]> Date: Mon Nov 10 14:26:18 2025 +0200 wifi: mac80211: skip rate verification for not captured PSDUs [ Upstream commit 7fe0d21f5633af8c3fab9f0ef0706c6156623484 ] If for example the sniffer did not follow any AIDs in an MU frame, then some of the information may not be filled in or is even expected to be invalid. As an example, in that case it is expected that Nss is zero. Fixes: 2ff5e52e7836 ("radiotap: add 0-length PSDU "not captured" type") Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20251110142554.83a2858ee15b.I9f78ce7984872f474722f9278691ae16378f0a3e@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu Nov 13 16:35:50 2025 -0600 x86/CPU/AMD: Add additional fixed RDSEED microcode revisions commit e1a97a627cd01d73fac5dd054d8f3de601ef2781 upstream. Microcode that resolves the RDSEED failure (SB-7055 [1]) has been released for additional Zen5 models to linux-firmware [2]. Update the zen5_rdseed_microcode array to cover these new models. Fixes: 607b9fb2ce24 ("x86/CPU/AMD: Add RDSEED fix for Zen5") Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html [1] Link: https://gitlab.com/kernel-firmware/linux-firmware/-/commit/6167e5566900cf236f7a69704e8f4c441bc7212a [2] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Borislav Petkov (AMD) <[email protected]> Date: Fri Nov 14 14:01:14 2025 +0100 x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev commit dd14022a7ce96963aa923e35cf4bcc8c32f95840 upstream. Add the minimum Entrysign revision for that model+stepping to the list of minimum revisions. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Reported-by: Andrew Cooper <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>