commit 228da13e907e2b46b7222cfc35290fbfad920bef Author: Greg Kroah-Hartman Date: Mon Jun 1 17:39:43 2026 +0200 Linux 6.1.175 Link: https://lore.kernel.org/r/20260528194629.379955525@linuxfoundation.org Tested-by: Dominique Martinet Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Francesco Dolcini Tested-by: Brett A C Sheffield Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4c5d407ba3ff7f30561ff73ba1b07ed70c864edc Author: Linus Torvalds Date: Thu May 28 11:45:41 2026 -0700 security/keys: fix missed RCU read section on lookup commit 43a1e3744548e6fd85873e6fb43e293eb4010694 upstream. Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for. Reported-by: Nicholas Carlini Cc: David Howells Cc: Jarkko Sakkinen Cc: Paul Moore Cc: James Morris James Morris Cc: Serge E. Hallyn Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff1d5af207bcea857d45fe81505f1bc4b29eaef0 Author: Aditya Garg Date: Tue May 19 22:15:53 2026 -0700 net: mana: validate rx_req_idx to prevent out-of-bounds array access [ Upstream commit b809d0409991b75a6cff846a5ac27c3062953f84 ] In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[]. Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260520051553.857120-1-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37634adc85e72132efcf1e2f342644c32fce1850 Author: Bartosz Golaszewski Date: Thu May 21 10:42:16 2026 +0200 gpio: cdev: check if uAPI v2 config attributes are correctly zeroed [ Upstream commit 3e6ccd790ed69bedd3d9626d01dd35cf9821c121 ] We check the padding of other uAPI v2 structures but not that of line config attributes. For used attributes: check if their padding is zeroed, for unused: check if the entire structure is zeroed. Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Reviewed-by: Kent Gibson Link: https://patch.msgid.link/20260521-gpio-cdev-attr-padding-check-v3-1-ec3bcbe2e358@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 9ffabebea35dacdcabf429c676ee73c858fa01a1 Author: Andy Shevchenko Date: Sun Nov 10 22:16:15 2024 +0200 gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n) [ Upstream commit e106b1dd38e723ec2bb2bf57ea9b2aff464b9423 ] Use the mem_is_zero() helper where possible. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241110201706.16614-1-andy.shevchenko@gmail.com Signed-off-by: Bartosz Golaszewski Stable-dep-of: 3e6ccd790ed6 ("gpio: cdev: check if uAPI v2 config attributes are correctly zeroed") Signed-off-by: Sasha Levin commit e990211bd07d2c85a096cc04e012979abb966421 Author: Jani Nikula Date: Wed Aug 14 13:00:34 2024 +0300 string: add mem_is_zero() helper to check if memory area is all zeros [ Upstream commit 3942bb49728ad9e1f94d953a88af169a8f5d8099 ] Almost two thirds of the memchr_inv() usages check if the memory area is all zeros, with no interest in where in the buffer the first non-zero byte is located. Checking for !memchr_inv(s, 0, n) is also not very intuitive or discoverable. Add an explicit mem_is_zero() helper for this use case. Reviewed-by: Kees Cook Reviewed-by: Andy Shevchenko Link: https://patchwork.freedesktop.org/patch/msgid/20240814100035.3100852-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: 3e6ccd790ed6 ("gpio: cdev: check if uAPI v2 config attributes are correctly zeroed") Signed-off-by: Sasha Levin commit b0f5a956a83e4b1815071cff079f1f9796912d29 Author: Rosen Penev Date: Sat May 16 14:26:16 2026 -0700 net: ag71xx: check error for platform_get_irq [ Upstream commit e7c70bf97e90d974cd575e4c90f8f9b07d056da3 ] Complete error handling for a failed platform_get_irq() call Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver") Signed-off-by: Rosen Penev Reviewed-by: Oleksij Rempel Link: https://patch.msgid.link/20260516212616.11758-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0402a1d3ddec565132867337ed44514a09d84728 Author: David Carlier Date: Fri May 8 20:57:47 2026 +0100 tracing: Avoid NULL return from hist_field_name() on truncation [ Upstream commit 576ec047d20b368b43c4d5db98c4f2e0f3c101ec ] hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow. Link: https://patch.msgid.link/20260508195747.25492-1-devnexen@gmail.com Fixes: 5ec1d1e97de1 ("tracing: Rebuild full_name on each hist_field_name() call") Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit ed3b69e60385a03df11c6d12e5d7bdf0f4a11b70 Author: Ido Schimmel Date: Sun May 17 15:11:21 2026 +0300 bridge: mcast: Fix a possible use-after-free when removing a bridge port [ Upstream commit 4df78ff02629c7729168f0696a7a2123c389818d ] When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled. When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled. The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port: # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1 This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs. After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1]. Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled. [1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) Fixes: 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions") Reported-by: syzbot+ae231e0552fa77b26ea1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/87qznowlfs.ffs@tglx/ Reported-by: Thomas Gleixner Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260517121122.188333-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 735bcaa9fc53f899a51210dcc9212a55bba9d442 Author: Petr Machata Date: Thu Oct 23 16:45:37 2025 +0200 net: bridge: Flush multicast groups when snooping is disabled [ Upstream commit 68800bbf583f26f71491141e4b3c8582f9cfcbde ] When forwarding multicast packets, the bridge takes MDB into account when IGMP / MLD snooping is enabled. Currently, when snooping is disabled, the MDB is retained, even though it is not used anymore. At the same time, during the time that snooping is disabled, the IGMP / MLD control packets are obviously ignored, and after the snooping is reenabled, the administrator has to assume it is out of sync. In particular, missed join and leave messages would lead to traffic being forwarded to wrong interfaces. Keeping the MDB entries around thus serves no purpose, and just takes memory. Note also that disabling per-VLAN snooping does actually flush the relevant MDB entries. This patch flushes non-permanent MDB entries as global snooping is disabled. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/5e992df1bb93b88e19c0ea5819e23b669e3dde5d.1761228273.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4df78ff02629 ("bridge: mcast: Fix a possible use-after-free when removing a bridge port") Signed-off-by: Sasha Levin commit 548f3956e53a7f7bde912d8129010b8986d5e602 Author: Guangshuo Li Date: Thu May 14 19:38:34 2026 +0800 RDMA/rtrs: Fix use-after-free in path file creation cleanup [ Upstream commit 5b74373390113fba798a76b483837029ab010fef ] In the error path of rtrs_srv_create_path_files(), the sysfs root folders may already have been created and srv_path->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobject_put(&srv_path->kobj) before rtrs_srv_destroy_once_sysfs_root_folders(srv_path). kobject_put() may drop the last reference to srv_path->kobj and invoke the release callback, rtrs_srv_release(), which frees srv_path. The following call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then dereferences srv_path internally to access srv_path->srv, resulting in a use-after-free. This failure path is reached before rtrs_srv_create_path_files() returns success, so the successful-path lifetime handling is not involved. Fix this by destroying the sysfs root folders before calling kobject_put(&srv_path->kobj), so srv_path is still valid while the helper accesses it. This issue was found by a static analysis tool I am developing. Fixes: ae4c81644e91 ("RDMA/rtrs-srv: Rename rtrs_srv_sess to rtrs_srv_path") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260514113834.865530-1-lgs201920130244@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0be2a245b8d2b382edeeb17d44c70982104448f1 Author: Rafael J. Wysocki Date: Tue May 12 17:16:22 2026 +0200 platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL [ Upstream commit a9f305c5a355efeb240d406d378491d9eec02d07 ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-vbtn driver. Fixes: 26173179fae1 ("platform/x86: intel-vbtn: Eval VBDL after registering our notifier") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/3426431.aeNJFYEL58@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 19b6ed4b6378f71e457a92e4220eb542971b23a5 Author: Rafael J. Wysocki Date: Tue May 12 17:13:28 2026 +0200 platform/x86: intel-hid: Check ACPI_HANDLE() against NULL [ Upstream commit 5c69e090ae5dd93d910f70db0796357080707d26 ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-hid driver. Fixes: ecc83e52b28c ("intel-hid: new hid event driver for hotkeys") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/1971512.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7cf32e64644b1f97a40c77395282a26c3976a649 Author: Rafael J. Wysocki Date: Tue May 12 17:12:40 2026 +0200 platform/x86: hp_accel: Check ACPI_COMPANION() against NULL [ Upstream commit abfbe5ee8ae89f1f5449790423d5dd3e423545bd ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the platform/x86 hp_accel driver. Fixes: 8ebcb6c94c71 ("platform/x86: hp_accel: Convert to be a platform driver") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/2425918.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d9fe36536a423777e9b19a7f3a49a7032f29af69 Author: Rafael J. Wysocki Date: Tue May 12 17:11:49 2026 +0200 platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL [ Upstream commit e7a9a6ea40e352cd7977f6a8c80bdeadf65ad838 ] Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 adv_swbutton driver. Fixes: 3d904005f686 ("platform/x86: add support for Advantech software defined button") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/5115425.31r3eYUQgx@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 70ad2dff8d052a85dfef15715b531f38a29108cf Author: Erni Sri Satya Vennela Date: Thu May 14 12:41:51 2026 -0700 net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer [ Upstream commit 35f0f0a2536a4d604b4dbad92c85c4a8fdebb870 ] In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic. DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation. Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp(). Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260514194156.466823-1-ernis@linux.microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5505b5a14d7b3045e63a7943a5ee5e3126ca5cb4 Author: Daniel Golle Date: Thu May 14 15:04:35 2026 +0100 net: dsa: mt7530: preserve VLAN tags on trapped link-local frames [ Upstream commit 3ac85bcfd404b588298c95c6fba8aad4ad334f57 ] The BPC, RGAC1 and RGAC2 registers control the handling of link-local frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are correctly trapped to the CPU port, but the egress VLAN tag attribute was set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any VLAN tags from trapped frames before they reach the CPU. This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer Delay Requests) to arrive at the CPU without their VLAN tag, so they are delivered to the base network interface instead of the VLAN sub-interface. The DSA local_termination selftest confirms this: all link-local protocol tests on VLAN upper interfaces fail. Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default) so that the switch does not modify VLAN tags in trapped frames. This way VLAN-tagged frames retain their original tag and are delivered to the correct VLAN sub-interface, matching the behavior of non-trapped frames which pass through without VLAN tag modification. Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames") Signed-off-by: Daniel Golle Acked-by: Chester A. Unal Link: https://patch.msgid.link/891e0cd34db2a5fe20ceb73283a81fb5f71427ca.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 11cbfdc5f6dbc23cad8a355c3e42b37a6b093023 Author: Arınç ÜNAL Date: Mon Apr 22 10:15:11 2024 +0300 net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw [ Upstream commit 7603a0c7d2210a253265394b50567c64fbb977e4 ] The mt753x_bpdu_port_fw enum is globally used for manipulating the process of deciding the forwardable ports, specifically concerning the CPU port(s). Therefore, rename it and the values in it to mt753x_to_cpu_fw. Change FOLLOW_MFC to SYSTEM_DEFAULT to be on par with the switch documents. Signed-off-by: Arınç ÜNAL Signed-off-by: David S. Miller Stable-dep-of: 3ac85bcfd404 ("net: dsa: mt7530: preserve VLAN tags on trapped link-local frames") Signed-off-by: Sasha Levin commit a2b00f7cb0b83b45da9b1d6fe284333021432de1 Author: Daniel Golle Date: Thu May 14 15:04:21 2026 +0100 net: dsa: mt7530: fix FDB entries not aging out with short timeout [ Upstream commit e824e40d0e841fab66ab7897d6c7b14dc81c66a7 ] The DSA forwarding selftests bridge_vlan_aware.sh and bridge_vlan_unaware.sh configure the bridge with ageing_time set to LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run learning_test() in lib.sh, which expects a learned FDB entry to be removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry persisted past the deadline and the "Found FDB record when should not" assertion failed. With msecs=10000, the algorithm in mt7530_set_ageing_time() finds AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the search from tmp_age_count=0). The per-entry aging counter is initialized to AGE_CNT when a MAC address is learned, so with AGE_CNT=0 new entries start with a counter value of 0, which the hardware treats as "already aged" and never removes, effectively disabling aging. Fix this by starting the search from tmp_age_count=1 to ensure entries always have a non-zero initial aging counter. For a 10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead: the timer ticks every 5 seconds and entries are removed after 2 ticks. Starting the search at AGE_CNT=1 raises the minimum representable ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time of 1 second would now make the loop fall through without setting age_count and age_unit, leaving them uninitialized when written to the MT7530_AAC hardware register. Set ds->ageing_time_min and ds->ageing_time_max so the DSA core validates the range before the callback is invoked, and drop the now-redundant range check from mt7530_set_ageing_time(). Fixes: ea6d5c924e39 ("net: dsa: mt7530: support setting ageing time") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/7788ded12dc07b1bce329ec35fa70f4b45f3f9b7.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9429d625751d5e4fe3927e863297e2a9abfab62b Author: Daniel Golle Date: Tue Apr 22 04:10:20 2025 +0100 net: dsa: mt7530: sync driver-specific behavior of MT7531 variants [ Upstream commit 497041d763016c2e8314d2f6a329a9b77c3797ca ] MT7531 standalone and MMIO variants found in MT7988 and EN7581 share most basic properties. Despite that, assisted_learning_on_cpu_port and mtu_enforcement_ingress were only applied for MT7531 but not for MT7988 or EN7581, causing the expected issues on MMIO devices. Apply both settings equally also for MT7988 and EN7581 by moving both assignments form mt7531_setup() to mt7531_setup_common(). This fixes unwanted flooding of packets due to unknown unicast during DA lookup, as well as issues with heterogenous MTU settings. Fixes: 7f54cc9772ce ("net: dsa: mt7530: split-off common parts from mt7531_setup") Signed-off-by: Daniel Golle Reviewed-by: Chester A. Unal Link: https://patch.msgid.link/89ed7ec6d4fa0395ac53ad2809742bb1ce61ed12.1745290867.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Stable-dep-of: e824e40d0e84 ("net: dsa: mt7530: fix FDB entries not aging out with short timeout") Signed-off-by: Sasha Levin commit fcb479e55b37042b8dbff02ad86c803ea080a6a2 Author: Matthew Leach Date: Fri Apr 24 10:50:35 2026 +0100 wifi: ath11k: fix peer resolution on rx path when peer_id=0 [ Upstream commit 2a2451a34afdf563b3102d36a4b6cf335cf813e2 ] It has been observed that on certain chipsets a peer can be assigned peer_id=0. For reception of non-aggregated MPDUs this is fine as ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer based upon the source MAC address. On an aggregated link, the mpdu_start header is only populated by hardware on the first sub-MSDU. This causes the peer resolution to be skipped for the subsequent MSDUs and the encryption type of these frames to be set to an incorrect value, resulting in these MSDUs being dropped by ieee80211. ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0 ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1 Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID of 0 to be resolved. Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9 Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload") Reviewed-by: Baochen Qiang Signed-off-by: Matthew Leach Reviewed-by: P Praneesh Link: https://patch.msgid.link/20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c7ec1a257a306307135c4fa72a349395f7fcbce1 Author: P Praneesh Date: Fri Mar 24 16:57:00 2023 +0200 wifi: ath11k: fix rssi station dump not updated in QCN9074 [ Upstream commit 031ffa6c2cd305a57ccc6d610f2decd956b2e7f6 ] In QCN9074, station dump signal values display default value which is -95 dbm, since there is firmware header change for HAL_RX_MPDU_START between QCN9074 and IPQ8074 which cause wrong peer_id fetch from msdu. Fix this by updating hal_rx_mpdu_info with corresponding QCN9074 tlv format. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1 Signed-off-by: P Praneesh Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230320110312.20639-1-quic_ppranees@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit 291d8103a9dcf4a0362678591426c7ef4d470d35 Author: Sriram R Date: Fri Dec 2 23:37:15 2022 +0200 wifi: ath11k: add new hw ops for IPQ5018 to get rx dest ring hashmap [ Upstream commit 69968f88f1770d61cae0febef805fd00d66cf6a1 ] The Destination ring control register is different for IPQ5018 when compared to IPQ8074/IPQ6018/QCN9074. Hence create a new hw ops to fetch the hash ring map for different device variants. ipq5018 hw ops is similar to qcn9074 except for this change, so reuse all the qcn9074 ops for ipq5018. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-8-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit d0ca5aa0fe7e3a43797ed1bf8b144c59863fd65c Author: Sriram R Date: Fri Dec 2 23:37:14 2022 +0200 wifi: ath11k: initialize hw_ops for IPQ5018 [ Upstream commit ba60f2793d3a37a00da14bb56a26558a902d2831 ] The ipq5018_ops is initialized for IPQ5018. This is different from other platforms. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-7-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit f9a78708302c26655de4978f786bc8493898cf29 Author: Sriram R Date: Fri Dec 2 23:37:14 2022 +0200 wifi: ath11k: update hal srng regs for IPQ5018 [ Upstream commit 711b80acbdfb9667a9cf8374e13320a6e624ce73 ] IPQ5018 hal srng register address & offsets are not similar to IPQ8074/IPQ6018/QCN9074, hence define a new set of srng register group data for IPQ5018. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-6-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit a019ee286e26d8fd5cca21dc5e768423d5687ba4 Author: Sriram R Date: Fri Dec 2 23:37:14 2022 +0200 wifi: ath11k: remap ce register space for IPQ5018 [ Upstream commit b42b3678c91f3ca6e0888bf5a15c1e8678fd5f2d ] In IPQ5018 ce register space is moved out of wcss unlike ipq8074 or ipq6018 and the space is not contiguous, hence remap the CE registers to a new space to access them. Register read/write is modified to check if the register to be written falls in the CE register space and corresponding register is written. Also adjust the interrupt register address to ce irq enable/disable. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-5-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit 967ce322434eb68743ae7b46649a3f2a285d75b7 Author: Sriram R Date: Fri Dec 2 23:37:14 2022 +0200 wifi: ath11k: update ce configurations for IPQ5018 [ Upstream commit 26af7aabd2d8225c6b2056234626ba5099610871 ] IPQ5018 is a single pdev device. Update host and target CE configurations accordingly. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-4-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit 4b41f8114f0336e69ac61dcf1efadef319e3826a Author: Sriram R Date: Fri Dec 2 23:37:13 2022 +0200 wifi: ath11k: update hw params for IPQ5018 [ Upstream commit 8dfe875aa24aec68baf6702018633c84c2c1feca ] Add new compatible string for IPQ5018 and add required hw params for IPQ5018. The hw descriptors size and datapath ops are similar to QCN9074, hence reuse the same. Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Co-developed-by: Karthikeyan Kathirvel Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221122132152.17771-3-quic_kathirve@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit aedac18cbd4ceb54f483fc0679ec1e8047e997b2 Author: Youghandhar Chintala Date: Fri Nov 4 14:24:03 2022 +0530 wifi: ath11k: Trigger sta disconnect on hardware restart [ Upstream commit a018750a2cceaf4427c4ee3d9ce3e83a171d5bd6 ] Currently after the hardware restart triggered from the driver, the station interface connection remains intact, since a disconnect trigger is not sent to userspace. This can lead to a problem in targets where the wifi mac sequence is added by the firmware. After the target restart, its wifi mac sequence number gets reset to zero. Hence AP to which our device is connected will receive frames with a wifi mac sequence number jump to the past, thereby resulting in the AP dropping all these frames, until the frame arrives with a wifi mac sequence number which AP was expecting. To avoid such frame drops, its better to trigger a station disconnect upon target hardware restart which can be done with API ieee80211_reconfig_disconnect exposed to mac80211. The other targets are not affected by this change, since the hardware params flag is not set. Reported-by: kernel test robot Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Youghandhar Chintala Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221104085403.11025-1-quic_youghand@quicinc.com Stable-dep-of: 2a2451a34afd ("wifi: ath11k: fix peer resolution on rx path when peer_id=0") Signed-off-by: Sasha Levin commit cecd34e046121d788a70b5c8b4f8a88916637953 Author: Dmitry Baryshkov Date: Sat May 16 14:53:45 2026 +0300 drm/msm/snapshot: fix dumping of the unaligned regions [ Upstream commit 76824d2467feb1828b745d6add2541918d7be3da ] The snapshotting code internally aligns data segment to 16 bytes. This works fine for DPU code (where most of the regions are aligned), but fails for snapshotting of the DSI data (because DSI data region is shifted by 4 bytes). Fix the code by removing length alignment and by accurately printing last registers in the region. While reworking the code also fix the 16x memory overallocation in msm_disp_state_dump_regs(). Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reported-by: Salendarsingh Gaud Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/725449/ Message-ID: <20260516-msm-fix-dsi-dump-2-v2-1-9e49fb2d240e@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 24f46cc7882f2db29a32cb8182cfac3355b83734 Author: Felix Gu Date: Sun May 10 01:55:37 2026 +0800 spi: mtk-snfi: Fix resource leak in mtk_snand_read_page_cache() [ Upstream commit 496ba79b9496b8b3747cbc764ebd33ee7325e806 ] When DMA read times out in mtk_snand_read_page_cache(), the original code erroneously jumped to cleanup label which skips DMA unmapping and ECC disable, causing a resource leak. Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260510-snfi-v1-1-bc375cf1af8e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 410351158dfef2d67fea6603680b3a6013c6ed9d Author: Jakub Kicinski Date: Mon May 11 10:49:18 2026 -0700 net: tls: prevent chain-after-chain in plain text SG [ Upstream commit ff26a0e8377dec07e4a7230db7675bed1b9a6d03 ] Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link: This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links. meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap: end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] Skip the wrapping in this case. TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain. Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective. Reported-by: Sashiko Fixes: 9aaaa56845a0 ("bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260511174920.433155-3-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 84158c2997159df4a0d70cd9c46774512d32a522 Author: Jakub Kicinski Date: Mon May 11 10:49:17 2026 -0700 net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring [ Upstream commit 285943c6e7ca309bbea84b253745154241d9788a ] When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. */ struct scatterlist data[MAX_MSG_FRAGS + 2]; The current code uses MAX_SKB_FRAGS + 1 as the ring size: sg_chain(&msg_pl->sg.data[msg_pl->sg.start], MAX_SKB_FRAGS - msg_pl->sg.start + 1, msg_pl->sg.data); This places the chain pointer at sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS] instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down") Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina). Reported-by: 钱一铭 Fixes: 9aaaa56845a0 ("bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining") Signed-off-by: Jakub Kicinski Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260511174920.433155-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6927cacf2b10d4fa80c1a2d407512ef9397c59c6 Author: Xiang Mei Date: Sun May 10 23:21:38 2026 -0700 net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot [ Upstream commit 277740023def559a4a2ddc3e8e784ee37a0f16a9 ] On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ism_selected becomes 0, and the subsequent ism_dev[0]->lgr_lock dereference in smc_conn_create() faults at offsetof(struct smcd_dev, lgr_lock) == 0x68: BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0 Write of size 4 at addr 0000000000000068 by task exploit/144 Call Trace: _raw_spin_lock_bh smc_conn_create (net/smc/smc_core.c:1997) __smc_connect (net/smc/af_smc.c:1447) smc_connect (net/smc/af_smc.c:1720) __sys_connect __x64_sys_connect do_syscall_64 Require ism_dev[i] to be non-NULL before accepting a CHID match. Fixes: a7c9c5f4af7f ("net/smc: CLC accept / confirm V2") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260511062138.2839584-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 51860e423592893cd7bfa7287d99a3aff4dc3a9d Author: Sayali Patil Date: Wed May 13 13:44:13 2026 +0530 powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise() [ Upstream commit 31467b23823ffec1f6fff407f8e3ca9af8b7491a ] A kernel panic is observed when handling machine check exceptions from real mode. BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70 LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0 The crash occurs because arch_irq_work_raise() calls preempt_disable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preempt_count can fault, leading to the panic. The preempt_disable()/preempt_enable() pair in arch_irq_work_raise() was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix oops due to perf_event_do_pending call") to avoid races while raising irq work from exception context. Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per cpu atomics instead of regular atomics") added equivalent protection in irq_work_queue_on() before reaching arch_irq_work_raise(): irq_work_queue() / irq_work_queue_on() -> preempt_disable() -> __irq_work_queue_local() -> irq_work_raise() -> arch_irq_work_raise() As a result, callers other than mce_irq_work_raise() already execute with preemption disabled, making the additional preempt_disable()/preempt_enable() pair in arch_irq_work_raise() redundant. The arch_irq_work_raise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preempt_disable()/preempt_enable() calls from here. Remove it to avoid accessing preempt_count from real mode context. Fixes: cc15ff327569 ("powerpc/mce: Avoid using irq_work_queue() in realmode") Suggested-by: Mahesh Salgaonkar Acked-by: Shrikanth Hegde Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sayali Patil [Maddy: Fixed the commit title] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260513081413.222490-1-sayalip@linux.ibm.com Signed-off-by: Sasha Levin commit 3e3c3c95ef4fe17231a9149e27bcfc9dae2dd89f Author: Mikko Perttunen Date: Tue Apr 21 13:02:38 2026 +0900 drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN [ Upstream commit 55e0f0d1c1a4ee1e46da7da4d443eb3044fb3851 ] Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. Store the return value in the appropriate type and in case of error, return it rather than WARNing. Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()") Signed-off-by: Mikko Perttunen Patchwork: https://patchwork.freedesktop.org/patch/719685/ Message-ID: <20260421-iommu_map_sgtable-return-v1-3-fb484c07d2a1@nvidia.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5e2c196c3430fb94225c4102b1028d0146544761 Author: Dmitry Baryshkov Date: Tue Apr 28 20:21:38 2026 +0300 drm/msm/dsi: don't dump registers past the mapped region [ Upstream commit 5b49a46baa853b26dbefa65c6c75dd9ff69f63d4 ] On DSI 6G platforms the IO address space is internally adjusted by io_offset. Later this adjusted address might be used for memory dumping. However the size that is used for memory dumping isn't adjusted to account for the io_offset, leading to the potential access to the unmapped region. Lower ctrl_size by the io_offset value to prevent access past the mapped area. msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P) msm_dsi_host_snapshot+0x4c/0x78 [msm] msm_dsi_snapshot+0x28/0x50 [msm] msm_disp_snapshot_capture_state+0x74/0x140 [msm] msm_disp_snapshot_state_sync+0x60/0x90 [msm] _msm_disp_snapshot_work+0x30/0x90 [msm] kthread_worker_fn+0xdc/0x460 kthread+0x120/0x140 Fixes: bac2c6a62ed9 ("drm/msm: get rid of msm_iomap_size") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/721747/ Link: https://lore.kernel.org/r/20260428-msm-fix-dsi-dump-v1-1-5d4cb5ccfac7@oss.qualcomm.com Signed-off-by: Sasha Levin commit 97bee44eb172a48127bbea6febb45cc1f29a803c Author: Chenguang Zhao Date: Mon May 11 09:43:43 2026 +0800 ethtool: fix ethnl_bitmap32_not_zero() bit interval semantics [ Upstream commit 3d042592ebd4c7e44974d556de0b727cb7db4dab ] ethnl_bitmap32_not_zero() should return true if some bit in [start, end) is set: - Fix inverted memchr_inv() sense: return true when the scan finds a non-zero byte, not when the middle words are all zero. - Return false for an empty interval (end <= start). - When end is 32-bit aligned, indices in [start, end) do not include any bits from map[end_word]; return false after earlier checks found no non-zero data. Fixes: 10b518d4e6dd ("ethtool: netlink bitset handling") Signed-off-by: Chenguang Zhao Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68200112534bb2acd1d7117dc2d5c124868d866d Author: Xiang Mei Date: Sun May 10 15:26:40 2026 -0700 net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint [ Upstream commit 7bf563badd37cb796df5477d2b78bb64148a1268 ] The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname) conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on these paths already handles this (e.g. !conn->lnk in SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first sendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64 The faulting address 0x3e0 is offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref. Enabling the tracepoint requires root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has no capability check, and SMC-D negotiation needs no admin step on s390 or on x86 with the loopback ISM device loaded. Log an empty device name for SMC-D instead of dereferencing NULL. Fixes: aff3083f10bf ("net/smc: Introduce tracepoints for tx and rx msg") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Dust Li Reviewed-by: Sidraya Jayagond Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f5be510bc54bd9dd19c25258021f98b8c1f95ea2 Author: Lukas Bulwahn Date: Thu Feb 5 09:11:31 2026 +0100 HID: quirks: really enable the intended work around for appledisplay [ Upstream commit 5f90dcfa8dc32a488581b78e575cdd7808ba5c78 ] Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") intends to add a quirk for kernels built with Apple Cinema Display support, but it refers to the non-existing config option CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display support is named CONFIG_USB_APPLEDISPLAY. Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef directive. Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") Signed-off-by: Lukas Bulwahn Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cd43d587dd333517c806cd24696e6e1a26b9951e Author: Nicolas Escande Date: Wed May 6 15:42:38 2026 +0200 wifi: ath11k: fix error path leaks in some WMI WOW calls [ Upstream commit 55dda532bbc261aef495e403c8900c5e2ab5fa34 ] Fix two instances where we used to directly return the result of ath11k_wmi_cmd_send(...). Because we did not check the return value, we also did not free the skb in the error path. Fixes: 79802b13a492 ("ath11k: implement WoW enable and wakeup commands") Signed-off-by: Nicolas Escande Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260506134240.2284016-2-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5919c05838e7d2017051fc9576b8f2b615dc9a92 Author: Ethan Nelson-Moore Date: Fri May 8 19:37:28 2026 -0700 net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS reference [ Upstream commit 36a8d04a8293afcb9304cf0cd3741f67698f2a1a ] The legacy ARM board file for MACH_MX31ADS was removed in commit c93197b0041d ("ARM: imx: Remove i.MX31 board files"), but a reference to it remained in the cs89x0 driver. Drop this unused code. Signed-off-by: Ethan Nelson-Moore Fixes: c93197b0041d ("ARM: imx: Remove i.MX31 board files") Link: https://patch.msgid.link/20260509023732.42256-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 75105fcf73f1ce7d9f769aaefec6e6d6645d5ac0 Author: Linus Walleij Date: Sat May 9 00:13:38 2026 +0200 net: ethernet: cortina: Carry over frag counter [ Upstream commit ebd8ec2b309e3a447851b456ccaf8fb39f3661e7 ] The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-3-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2b67f0e78ec6db31077e9b4cd6dfe57530538871 Author: Andreas Haarmann-Thiemann Date: Tue May 5 23:52:17 2026 +0200 net: ethernet: cortina: Drop half-assembled SKB [ Upstream commit b266bacba796ff5c4dcd2ae2fc08aacf7ab39153 ] In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when gmac_get_queue_page() returns NULL for the second page of a multi-page fragment, the driver logs an error and continues — but does not free the partially assembled skb that was being assembled via napi_build_skb() / napi_get_frags(). Free the in-progress partially assembled skb via napi_free_frags() and increase the number of dropped frames appropriately and assign the skb pointer NULL to make sure it is not lingering around, matching the pattern already used elsewhere in the driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Andreas Haarmann-Thiemann Signed-off-by: Linus Walleij Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260505-gemini-ethernet-fix-v2-1-997c31d06079@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6bba24e9ebe6f1c0b356cd471e36bdc7fa434897 Author: Linus Walleij Date: Sat May 9 00:13:37 2026 +0200 net: ethernet: cortina: Make RX SKB per-port [ Upstream commit 06937db21ee311ed07eba47954447245041a982d ] The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-2-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2dc79362302922cb18f35e262712b5e58de65442 Author: Jiayuan Chen Date: Mon Mar 30 15:32:29 2026 +0800 irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT [ Upstream commit 91840be8f710370607f949a627e070896faeddb8 ] On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0. After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up(). An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free. Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees. Fixes: 810979682ccc ("irq_work: Allow irq_work_sync() to sleep if irq_work() no IRQ support.") Suggested-by: Sebastian Andrzej Siewior Suggested-by: Steven Rostedt Signed-off-by: Jiayuan Chen Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260330073234.303732-1-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit 29278b5f2376dffdca47f914d192e68cd29ae0d2 Author: Rosen Penev Date: Wed May 6 01:55:22 2026 -0700 irqchip/ath79-cpu: Remove unused function [ Upstream commit 0fa10fb77069fb67aa51384868ef3702b7791465 ] ath79_cpu_irq_init() was part of the legacy pre-OF code that got removed a while back. Remove it to get rid of a missing prototype warning, reported by the kernel test robot. [ tglx: Fix the subject prefix. Sigh ... ] Fixes: 51fa4f8912c0 ("MIPS: ath79: drop legacy IRQ code") Reported-by: kernel test robot Signed-off-by: Rosen Penev Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260506085522.1210143-1-rosenp@gmail.com Closes: https://lore.kernel.org/oe-kbuild-all/202412011509.kGQkDr1y-lkp@intel.com/ Signed-off-by: Sasha Levin commit fdb77ba6b14e9b0aa1c2a8ca9de5ed6be04d98d6 Author: Gabor Juhos Date: Sat Mar 21 15:42:32 2026 +0100 phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access [ Upstream commit 91ddf6f722084383fb05be731c0107814b055c0c ] The mvebu_a3700_utmi_phy_power_off() function tries to modify the USB2_PHY_CTRL register by using the IO address of the PHY IP block along with the readl/writel IO accessors. However, the register exist in the USB miscellaneous register space, and as such it must be accessed via regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function. Change the code to use regmap_update_bits() for modífying the register to fix this. Fixes: cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver") Signed-off-by: Gabor Juhos Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260321-a3700-utmi-fix-usb2_phy_ctrl-access-v1-1-6005ff4b5058@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3d3bd7990b976af98489b5ba071dabdfa0c1f0e6 Author: Myeonghun Pak Date: Wed May 6 21:43:11 2026 +0900 net: lan966x: avoid unregistering netdev on register failure [ Upstream commit c4f3d6eb1fcf6cd9ce4644f604d5aad1ce594dfc ] lan966x_probe_port() stores the newly allocated net_device in the port before calling register_netdev(). If register_netdev() fails, the probe error path calls lan966x_cleanup_ports(), which sees port->dev and calls unregister_netdev() for a device that was never registered. Destroy the phylink instance created for this port and clear port->dev before returning the registration error. The common cleanup path now skips ports without port->dev before reaching the registered netdev cleanup, so it only handles ports that reached the registered-netdev lifetime. This also avoids treating an uninitialized FDMA netdev and the failed port as a NULL == NULL match in the common cleanup path. Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260506124331.31945-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5250fe739b01111162521cd0ebd6e783f4717cb Author: Bart Van Assche Date: Wed May 6 14:48:15 2026 -0700 ice: fix locking in ice_dcb_rebuild() [ Upstream commit 0ded1f36ba4021cba50513e80be6b6e173710168 ] Move the mutex_lock() call up to prevent that DCB settings change after the first ice_query_port_ets() call. The second ice_query_port_ets() call in ice_dcb_rebuild() is already protected by pf->tc_mutex. This also fixes a bug in an error path, as before taking the first "goto dcb_error" in the function jumped over mutex_lock() to mutex_unlock(). This bug has been detected by the clang thread-safety analyzer. Cc: intel-wired-lan@lists.osuosl.org Fixes: 242b5e068b25 ("ice: Fix DCB rebuild after reset") Signed-off-by: Bart Van Assche Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Tested-by: Arpana Arland Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-6-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 808bf76f4ef63511621333195ebad43125f05021 Author: Kuniyuki Iwashima Date: Wed May 6 03:59:19 2026 +0000 tcp: Fix imbalanced icsk_accept_queue count. [ Upstream commit 7eca3292cac7c26dad4c236f51ba225c39a0523f ] When TCP socket migration happens in reqsk_timer_handler(), @sk_listener will be updated with the new listener. When we call __inet_csk_reqsk_queue_drop(), the listener must be the one stored in req->rsk_listener. The cited commit accidentally replaced oreq->rsk_listener with sk_listener, leading to imbalanced icsk_accept_queue count. Let's pass the correct listener to __inet_csk_reqsk_queue_drop(). Fixes: e8c526f2bdf1 ("tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().") Reported-by: Damiano Melotti Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260506035954.1563147-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3cb93f3e4b9d0f55a20d03d7bf71147147da4115 Author: Florian Westphal Date: Wed May 6 12:07:16 2026 +0200 netfilter: x_tables: unregister the templates first [ Upstream commit d338693d778579b676a61346849bebd892427158 ] When the module is going away we need to zap the template first. Else there is a small race window where userspace could instantiate a new table after the pernet exit function has removed the current table. Fixes: fdacd57c79b7 ("netfilter: x_tables: never register tables by default") Reported-by: Tristan Madani Reviewed-by: Tristan Madani Closes: https://lore.kernel.org/netfilter-devel/20260429175613.1459342-1-tristmd@gmail.com/ Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6624854554c4c2bdfed3559e5c11bb03b16e7bd1 Author: Guenter Roeck Date: Tue May 5 21:15:37 2026 +0200 ARM: integrator: Fix early initialization [ Upstream commit 90d77b30a666049ad24df463f52e5d529c44e8cd ] Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible which in turn calls of_syscon_register. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows. Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at __kmalloc_cache_noprof+0xec/0x39c LR is at __kmalloc_cache_noprof+0x34/0x39c ... Call trace: __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310 of_syscon_register from device_node_get_regmap+0xa4/0xb0 device_node_get_regmap from intcp_init_early+0xc/0x40 intcp_init_early from start_kernel+0x60/0x688 start_kernel from 0x0 The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to syscon_regmap_lookup_by_compatible returns -ENOMEM, and sched_clock_register is never called. Fix the problem by moving the early initialization code into the standard machine initialization code. Fixes: bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap") Cc: Linus Walleij Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/20250518164118.3859567-1-linux@roeck-us.net Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20260505-integrator-fixes-v1-1-56ab9aac59db@kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit c5fba9d5333de244990cf5740a8a626db1918db1 Author: Maulik Shah Date: Tue Apr 28 17:44:58 2026 +0530 pinctrl: qcom: Fix wakeirq map by removing disconnected irqs for sm8150 [ Upstream commit 52ac35b8a151446481496404af3a8e5e889b3c5a ] PDC interrupts 122-125 were meant for ibi_i3c wakeup but sm8150 do not support i3c. GPIOs 39,51,88 and 144 are also connected to different PDC pin and already reflected in the wake irq map. Remove the unsupported wakeup interrupts from the map. Fixes: 90337380c809 ("pinctrl: qcom: sm8150: Specify PDC map") Reviewed-by: Konrad Dybcio Signed-off-by: Maulik Shah Signed-off-by: Navya Malempati Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 811fdfdb4710a0c3ad977a72c4e247e5cf379960 Author: David Gow Date: Sat Apr 25 11:41:54 2026 +0800 kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS [ Upstream commit 8f80b5b227ef9ea422080487715c841856339aed ] CONFIG_KUNIT_DEBUGFS is totally useless without debugfs, so it should depend on CONFIG_DEBUG_FS. Link: https://lore.kernel.org/r/20260425034155.53913-2-david@davidgow.net Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit//results display") Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 783de70a779f8744ff5c2b2b80286e1a5aa0f5f2 Author: David Gow Date: Sat Apr 25 11:41:53 2026 +0800 kunit: config: Enable KUNIT_DEBUGFS by default [ Upstream commit 17e4c68ff35090d8cb743e3c82c09f92fda1ebda ] The KUNIT_DEBUGFS option is currently enabled based on the value of KUNIT_ALL_TESTS, but it really doesn't have anything to do with the set of enabled tests, so just enable it by default anyway. In particular, this shouldn't be only visible if KUNIT_ALL_TESTS is set, which is quite confusing. Link: https://lore.kernel.org/r/20260425034155.53913-1-david@davidgow.net Fixes: beaed42c427d ("kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS") Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e1f2bc593fff24e0a53b9dfcd3cc594c57bd4793 Author: Sudeep Holla Date: Tue Apr 28 19:33:26 2026 +0100 firmware: arm_ffa: Skip free_pages on RX buffer alloc failure [ Upstream commit 09527e2c534911619d7e098729711100290bc3e1 ] If the RX buffer allocation fails in ffa_init(), the error path jumps to free_pages even though no buffer has been allocated yet. Route that case directly to free_drv_info so the cleanup path is only used after at least one RX/TX buffer allocation has succeeded. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-2-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit bc499d1acddbb75b5b4bce05f5296dd8ef9611fd Author: Sudeep Holla Date: Tue Apr 28 19:33:25 2026 +0100 firmware: arm_ffa: Check for NULL FF-A ID table while driver registration [ Upstream commit 0a5e695095c557d2380131b613dea4e8d90371be ] The bus match callback assumes that every FF-A driver provides an id_table and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match. Fixes: 92743071464f ("firmware: arm_ffa: Ensure drivers provide a probe function") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-1-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 167adad72c6b0bf26bb7b62838430f9a26a8635a Author: Takashi Iwai Date: Tue Apr 28 10:33:16 2026 +0200 HID: uclogic: Fix regression of input name assignment [ Upstream commit 487359284509a6745e14b8c0518768bc277809b0 ] The previous fix for adding the devm_kasprintf() return check in the commit bd07f751208b ("HID: uclogic: Add NULL check in uclogic_input_configured()") changed the condition of hi->input->name assignment, and it resulted in missing the proper input device name when no custom suffix is defined. Restore the conditional to the original content to address the regression. Fixes: bd07f751208b ("HID: uclogic: Add NULL check in uclogic_input_configured()") Signed-off-by: Takashi Iwai Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c603b6c6840ac0c6285f5eefea0de6242710af21 Author: Abdurrahman Hussain Date: Mon May 18 17:52:27 2026 -0700 hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors commit a7232f68c43ca62f545049b7f5fbfc75137b843b upstream. adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the pin-status word as pins_status = read_buf[0] + (read_buf[1] << 8); right after i2c_smbus_read_block_data(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIO_STATUS/PDIO_STATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both read_buf slots are uninitialized stack memory; if it returns 1 byte, read_buf[1] is. The composed value then flows through set_bit() into the caller's *bits in adm1266_gpio_get_multiple(), or into the return value of adm1266_gpio_get(), and ends up in userspace via gpiolib (sysfs and the char-dev ioctls). That leaks a few bits of kernel stack per request on any device whose firmware glitch, bus error, or hostile slave produces a short block-read response. Add the missing length check to both call sites and surface a short response as -EIO. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-3-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit be9af508c9bbf8315314168c722b93d9da8dc915 Author: Abdurrahman Hussain Date: Mon May 18 17:52:29 2026 -0700 hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe() commit 6af713af91d5c34ec049eb3cc2c5b3f5eba953b8 upstream. adm1266_probe() calls adm1266_config_nvmem() -- which goes on to devm_nvmem_register() and exposes adm1266_nvmem_read() to userspace -- before pmbus_do_probe() has initialised the per-client PMBus state. Same latent hazard as the gpio_chip one fixed in the previous patch: once the nvmem device is registered, gpiolib's nvmem char-dev / sysfs interface is reachable, and any concurrent read triggers adm1266_nvmem_read() -> adm1266_nvmem_read_blackbox(), which issues PMBus traffic that races pmbus_do_probe()'s own device accesses with no serialisation. Move adm1266_config_nvmem() down past pmbus_do_probe() so the nvmem device isn't reachable from userspace until the PMBus state the nvmem accessors depend on is fully initialised. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-5-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 676dc0af840288fe29bd33b049d490e6e782bfec Author: Abdurrahman Hussain Date: Mon May 18 17:52:28 2026 -0700 hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe() commit 491403b9b76cf66abd81301c5901aa4a4549f1e8 upstream. adm1266_probe() calls adm1266_config_gpio() -- which goes on to devm_gpiochip_add_data() and exposes the gpio_chip callbacks to gpiolib -- before pmbus_do_probe() has initialised the per-client PMBus state (notably the pmbus_lock mutex the core hands out via pmbus_get_data()). That ordering is already a latent hazard: any GPIO access that lands between adm1266_config_gpio() and the end of pmbus_do_probe() (for example a sysfs read from a user space agent that opens the gpiochip the instant gpiolib advertises it) races pmbus_do_probe()'s own device accesses with no serialisation. Move adm1266_config_gpio() down past pmbus_do_probe() so the chip isn't reachable from userspace until the PMBus state it depends on is fully initialised. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-4-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4f5133c085c368000076a0bcc531f7ff99ffafc7 Author: Abdurrahman Hussain Date: Mon May 18 17:52:26 2026 -0700 hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in get_multiple commit 3327a12aee9e10ffa903e28b8445dfd1af5307c0 upstream. adm1266_gpio_get_multiple() zeroes *bits before the GPIO_STATUS loop and then a second time before the PDIO_STATUS loop: *bits = 0; for_each_set_bit(gpio_nr, mask, ADM1266_GPIO_NR) { ... set_bit(gpio_nr, bits); } ret = i2c_smbus_read_block_data(data->client, ADM1266_PDIO_STATUS, ...); ... *bits = 0; for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_NR) { ... set_bit(gpio_nr, bits); } The second *bits = 0 throws away every GPIO bit the first loop just populated, so callers asking for any combination of GPIO and PDIO pins always see the GPIO portion of the returned bits as zero. Drop the redundant second assignment so both halves of the result survive. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-2-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 299efd14c2eda7e5fd40025e54addd4151a01081 Author: Abdurrahman Hussain Date: Mon May 18 17:52:25 2026 -0700 hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR commit d7834d92251baade796812876e95555e2066fa9f upstream. adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a handful of unsigned-long words: four on 64-bit, seven on 32-bit) of whatever lives past the end of the mask in the caller's stack. Any incidental set bit in that range then drives a set_bit(gpio_nr, bits) call that writes past the end of the caller-supplied bits array too -- both out-of-bounds. Substitute ADM1266_PDIO_NR for the constant so the scan stops at the last real PDIO bit. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-1-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6098634cfa711f11a8d65368dc51ec8f7c8241ba Author: Abdurrahman Hussain Date: Fri May 15 15:11:51 2026 -0700 hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer commit 43cae21424ff8e33894a0f86c6b80b840c049fd7 upstream. adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length: memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]); The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns more than 64 bytes on the trailing record (read_buff offset 1984 in the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes before the post-call if (ret != ADM1266_BLACKBOX_SIZE) return -EIO; can reject the response. Contain the fix in the caller without changing the helper signature: read each record into a 255-byte local bounce buffer that matches the helper's maximum output, validate the returned length, and only then copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot. Fixes: 407dc802a9c0 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-5-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 528a9f88e88502d0c2f2052a279415074cd83715 Author: Abdurrahman Hussain Date: Fri May 15 15:11:50 2026 -0700 hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer commit 487566cb1ccdf3756fdd7bf8d875e612ff3169bb upstream. adm1266_pmbus_block_xfer() sets up the read transaction with .buf = data->read_buf, .len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc != msgs[1].buf[msgs[1].buf[0] + 1]) read a byte beyond the array. Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2c_msg length already accounts for. Fixes: 407dc802a9c0 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-4-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5469e1e7c411acc15fdd8262c99c3ebd9defd594 Author: Abdurrahman Hussain Date: Fri May 15 15:11:49 2026 -0700 hwmon: (pmbus/adm1266) reject implausible blackbox record_count commit 4afca954622d672ea65ed961bed01cf91caa034e upstream. adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOX_INFO response cannot drive the loop out of bounds. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-3-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e0797957c7205c57d04003add4f1c9cf279c36e9 Author: Abdurrahman Hussain Date: Fri May 15 15:11:47 2026 -0700 hwmon: (pmbus/adm1266) seed timestamp from the real-time clock commit b86095e3d7dcf2bf80c747349a35912a87a85098 upstream. adm1266_set_rtc() seeds the chip's SET_RTC register from ktime_get_seconds(), which returns CLOCK_MONOTONIC -- i.e. seconds since the host last booted, not seconds since the Unix epoch. The chip stamps that value into every blackbox record it captures. Userspace reading those timestamps back expects wall-clock seconds: that's what the SET_RTC frame layout documents (datasheet Rev. D, Table 84) and what every other consumer of "seconds since epoch" assumes. Seeding from CLOCK_MONOTONIC gives blackbox records a timestamp that is only meaningful within a single boot of the host and silently resets to small values on every reboot. Switch to ktime_get_real_seconds() so the seed matches what the register is documented to hold. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-1-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3c96dff00998314983b68a3e7caac07a66ebe496 Author: Sven Eckelmann Date: Sat May 2 19:53:21 2026 +0200 batman-adv: tt: fix negative tt_buff_len commit b64963a2ceeb7529310b6cf253a1e540784422f4 upstream. batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_other_tt_response(). Cc: stable@kernel.org Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c424e8519ac78eac5d9f4eecf06208a0d619ec14 Author: Sven Eckelmann Date: Sat May 2 19:53:21 2026 +0200 batman-adv: tt: fix negative last_changeset_len commit fc92cdfcb295cefa4344d71a527d61b638b7bfc4 upstream. batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_my_tt_response(). Cc: stable@kernel.org Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 9884c9c02d3c90e9215db3c5128f59045d20ae91 Author: Sven Eckelmann Date: Wed May 13 09:01:35 2026 +0200 batman-adv: tp_meter: avoid use of uninit sender vars commit 6c65cf23d4c6170fcf5714c32aa64689718cb142 upstream. batadv_tp_recv_ack() and batadv_tp_stop() are only valid for tp_vars in the BATADV_TP_SENDER role. When called with a BATADV_TP_RECEIVER role, it proceeds to read sender-only members that were never initialized, leading to undefined behavior. This can be triggered when a node that is currently acting as a receiver in an ongoing tp_meter session receives a malicious ACK packet. Guard against this by checking tp_vars->role immediately after the lookup and bailing out if it is not BATADV_TP_SENDER, before any of those members are accessed. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit f1303adb1e59582f76c22798a2e2e150e054a9e7 Author: Sven Eckelmann Date: Sun May 10 11:43:20 2026 +0200 batman-adv: bla: fix report_work leak on backbone_gw purge commit 0459430add32ea41f3e2ef9351610e6d33627a6b upstream. batadv_bla_purge_backbone_gw() removes stale backbone gateway entries, but fails to properly handle their associated report_work: - If report_work is running, the purge must wait for it to finish before freeing the backbone_gw, otherwise the worker may access freed memory (e.g. bat_priv). - If report_work is pending, the purge must cancel it and release the reference held for that pending work item. The previous implementation called hlist_for_each_entry_safe() inside a spin_lock_bh() section, but cancel_work_sync() may sleep and therefore cannot be called from within a spinlock-protected region. Restructure the loop to handle one entry per spinlock critical section: acquire the lock, find the next entry to purge, remove it from the hash list, then release the lock before calling cancel_work_sync() and dropping the hash_entry reference. Repeat until no more entries require purging. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Reviewed-by: Simon Wunderlich Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit aea54d0bbe156d5ab7d00d68f66149ff41f4612a Author: Sven Eckelmann Date: Wed May 13 09:01:36 2026 +0200 batman-adv: frag: disallow unicast fragment in fragment commit bc62216dc8e221e3781afa14430f45208bfa9af9 upstream. batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a BATADV_UNICAST_FRAG packet is received. Once all fragments are collected and the packet is reassembled, batadv_recv_frag_packet() calls batadv_batman_skb_recv() again to process the defragmented payload. A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting). Each nesting level recurses through batadv_batman_skb_recv() without bound, growing the kernel stack until it is exhausted. Since refragmentation or fragments in fragments are not actually allowed, discard all packets which are still BATADV_UNICAST_FRAG packets after the defragmentation process. Cc: stable@kernel.org Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c66d20a3ff095e3f000551d208ec2606616db15c Author: Luxiao Xu Date: Mon May 11 18:52:09 2026 +0200 batman-adv: fix tp_meter counter underflow during shutdown commit 94f3b133168d1c49895e7cc6afbcf1cc0b354602 upstream. batadv_tp_sender_shutdown() unconditionally decrements the "sending" atomic counter. If multiple paths (e.g. timeout, user cancel, and normal finish) call this function, the counter can underflow to -1. Since the sender logic treats any non-zero value as "still sending", a negative value causes the sender kthread to loop indefinitely. This leads to a use-after-free when the interface is removed while the zombie thread is still active. Fix this by using atomic_xchg() to ensure the counter only transitions from 1 to 0 once. Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei [sven: added missing change in batadv_tp_send] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 975563c5de1123dde1ec7946bf5556d20c89d74e Author: Ruide Cao Date: Wed May 13 11:58:15 2026 +0800 batman-adv: fix fragment reassembly length accounting commit 9cd3f16c320bfdadd4509358122368deb56a5741 upstream. batman-adv keeps a running payload length for queued fragments and uses it to validate a fragment chain before reassembly. That accounting currently allows the accumulated fragment length to be truncated during updates. As a result, malformed fragment chains can bypass the intended validation and drive reassembly with inconsistent length state, leading to a local denial of service. Fix the accounting by storing the accumulated length in a length-typed field and rejecting update overflows before the existing validation logic runs. The fix was verified against the original reproducer and against valid fragment reassembly paths. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruide Cao Tested-by: Ren Wei Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ce0c381199402a2c58f4599f4f6ed100d872d0da Author: Sven Eckelmann Date: Wed May 13 09:01:34 2026 +0200 batman-adv: dat: handle forward allocation error commit 2d8826a2d3657cea66fb0370f9e521575a673871 upstream. batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb for each DHT candidate, but does not check the return value before passing it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences the skb unconditionally, so a failed allocation triggers a NULL pointer dereference. Skip forwarding to the current DHT candidate on allocation failure. Cc: stable@kernel.org Fixes: 785ea1144182 ("batman-adv: Distributed ARP Table - create DHT helper functions") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 9a1a8ed4facfe843bde6fdfcf7af0e9923eb2e17 Author: Ruijie Li Date: Thu May 14 16:13:25 2026 +0800 batman-adv: clear current gateway during teardown commit a340a51ed801eab7bb454150c226323b865263cc upstream. batadv_gw_node_free() removes the gateway list entries during mesh teardown, but it does not clear the currently selected gateway. This leaves stale gateway state behind across cleanup and can break a later mesh recreation. Clear bat_priv->gw.curr_gw before walking the gateway list so the selected gateway reference is dropped as part of teardown. Fixes: 2265c1410864 ("batman-adv: gateway election code refactoring") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Zhanpeng Li Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ced48f55bac73f0822eae90509e51b42b4f646c8 Author: Sven Eckelmann Date: Thu May 14 19:22:02 2026 +0200 batman-adv: mcast: fix use-after-free in orig_node RCU release commit 20c2d6a20ca936f5aaa6dd40f73f262ac45c87cc upstream. batadv_mcast_purge_orig() removes entries from RCU-protected hlists but does not wait for an RCU grace period before returning. Concurrent RCU readers may still accesses references to those entries at the point of removal. RCU-protected readers trying to operate on entries like orig->mcast_want_all_ipv6_node will then access already freed memory. Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(), just before the call_rcu() invocation. This ensures RCU readers that were active at purge time have drained before the orig_node memory is reclaimed. Cc: stable@kernel.org Fixes: ab49886e3da7 ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support") Acked-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 16a5fa57565afb6bf37e18129921c270c93d8e2b Author: Harry Wentland Date: Thu May 7 16:26:31 2026 -0400 drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async commit 6c92f6d9600efa3ef0d9e560a2b52776d9803c29 upstream. [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. Assisted-by: GitHub Copilot:Claude claude-4-opus Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9900f6954be779011e7c2cd42addd87baf028bc5 Author: Harry Wentland Date: Mon May 4 16:14:11 2026 -0400 drm/amd/display: Validate GPIO pin LUT table size before iterating commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ca8510a132db4e547b96c0cf28e77f55be1041f3 Author: Harry Wentland Date: Mon May 4 11:14:45 2026 -0400 drm/amd/display: Fix integer overflow in bios_get_image() commit cd86529ec61474a38c3837fb7823790a7c3f8cce upstream. [Why&How] The bounds check in bios_get_image() computes 'offset + size' using unsigned 32-bit arithmetic before comparing against bios_size. If a VBIOS image contains a near-UINT32_MAX offset the addition wraps to a small value, the comparison passes, and the function returns a wild pointer past the VBIOS mapping. Additionally, the comparison uses '<' (strict), which incorrectly rejects the valid exact-fit case where offset + size == bios_size. Fix both issues by restructuring the check to avoid the addition entirely: first reject if offset alone exceeds bios_size, then check size against the remaining space (bios_size - offset). This eliminates the overflow and correctly permits exact-fit accesses. Assisted-by: GitHub Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d40fb392af659c4a02b560319f226842f6ec1a95) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2292914b5752b2abab65c54a7f54228fa99c56e2 Author: Osama Abdelkader Date: Thu Apr 30 21:56:59 2026 +0200 drm/bridge: megachips: remove bridge when irq request fails commit d45d5c819f2cd0b6b5d76a194a537a5f4aeefecb upstream. If devm_request_threaded_irq() fails after drm_bridge_add(), remove the bridge before returning. Keep drm_bridge_add() rather than devm_drm_bridge_add(): registration is tied to the STDP4028 device while ge_b850v3_register() may complete from either I2C probe; devm would not unwind the bridge if the other client's probe fails. Signed-off-by: Osama Abdelkader Fixes: fcfa0ddc18ed ("drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Tested-by: Ian Ray Link: https://patch.msgid.link/20260430195700.80317-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit fc81faa01307a9fc8e146d7ab9accd2690edb686 Author: Julien Chauveau Date: Tue Mar 24 20:30:11 2026 +0100 drm/bridge: it66121: acquire reset GPIO in probe commit e02b5262fd288cc235f14e12233ea54e78c04611 upstream. The it66121_ctx structure has a gpio_reset field, and it66121_hw_reset() calls gpiod_set_value() on it. However, the GPIO descriptor is never acquired via devm_gpiod_get(), leaving gpio_reset as NULL throughout the driver lifetime. gpiod_set_value() silently returns when passed a NULL descriptor, so the hardware reset sequence in it66121_hw_reset() is a no-op. This leaves the chip in an undefined state at probe time, which can prevent it from responding on the I2C bus. The DT binding marks reset-gpios as a required property, so all compliant device trees provide this GPIO. Add the missing devm_gpiod_get() call after enabling power supplies and before the hardware reset, so the chip is properly reset with power applied. Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Cc: stable@vger.kernel.org Signed-off-by: Julien Chauveau Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260324193011.16583-1-chauveau.julien@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit c86077d512ee980cc91322211d35dbcd3175f64c Author: Deepanshu Kartikey Date: Tue May 19 13:52:47 2026 +0530 drm/virtio: use uninterruptible resv lock for plane updates commit 9af1b6e175c82daf4b423da339a722d8e67a735a upstream. virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260519082247.34470-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3f1024deeab3b5443c29b3de4fe475e87309b8fa Author: Bartosz Golaszewski Date: Wed May 6 13:57:00 2026 +0200 device property: set fwnode->secondary to NULL in fwnode_init() commit 215c90ee656114f5e8c32408228d97082f8e0eef upstream. If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. Cc: stable Fixes: 01bb86b380a3 ("driver core: Add fwnode_init()") Signed-off-by: Bartosz Golaszewski Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Andy Shevchenko Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260506115701.23035-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e12b69efdad2097e4adb680d3cb20edfffb10d39 Author: Huacai Chen Date: Thu May 21 20:58:40 2026 +0800 LoongArch: Remove unused code to avoid build warning commit 0ccc9d47cf020994097ff51827cebd04aa2b0bf4 upstream. After commit feee6b2989165631b1 ("mm/memory_hotplug: shrink zones when offlining memory"), __remove_pages() doesn't need the "zone" parameter so the "page" variable is also unused. Remove the unused code to avoid such build warning: arch/loongarch/mm/init.c: In function 'arch_remove_memory': arch/loongarch/mm/init.c:134:22: warning: variable 'page' set but not used [-Wunused-but-set-variable=] 134 | struct page *page = pfn_to_page(start_pfn); Cc: Reviewed-by: Guo Ren Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 33a8b5e971e294ec2a7b74211c545e09efd8e9ac Author: Michael Bommarito Date: Wed May 13 13:53:24 2026 -0400 RDMA/siw: Reject MPA FPDU length underflow before signed receive math commit 0ce1bc9e46ecabe84772bb561e373c0d9876d6f2 upstream. A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace: skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields do not agree on the start of an FPDU"), the correct framing-error class for this inconsistency. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260513175325.2042630-2-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Acked-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit d6f422b122922d1abee907d673bcc990e5f3672d Author: Johan Hovold Date: Tue May 12 09:48:09 2026 +0200 spi: ti-qspi: fix use-after-free after DMA setup failure commit ea6ec3343e05f7937a53eb6d7617b3abdb4abc19 upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: c687c46e9e45 ("spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?part=17 Cc: stable@vger.kernel.org # 4.12 Cc: Vignesh R Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260512074809.915084-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0cdea166c1a07c200caf9d0b722224fca43b23ae Author: Johan Hovold Date: Tue May 12 09:47:33 2026 +0200 spi: sprd: fix error pointer deref after DMA setup failure commit 3d67fffb74267772d461c02c67f1eff893ad547d upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 386119bc7be9 ("spi: sprd: spi: sprd: Add DMA mode support") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?part=10 Cc: stable@vger.kernel.org # 5.1 Cc: Lanqing Liu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260512074733.915029-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ab2266601a875982f2d2033f41e070a6d5e615e2 Author: Michael Bommarito Date: Sun Apr 19 17:04:20 2026 -0400 scsi: isci: Fix use-after-free in device removal path commit b52a8d52c3125ec9a93106ed816582368de34426 upstream. The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() returns the IRQ handlers can still requeue the tasklet. The tasklet callback also re-enables interrupts after draining completions, so killing the tasklet before the source is quiesced leaves the same race open. Once wait_for_stop() returns, no further IRQ-driven scheduling can occur. Kill completion_tasklet there so teardown cannot race a queued tasklet running on a dead ihost. On remove or unload, the stale callback can otherwise dereference ihost and touch ihost->smu_registers after the host lifetime ends. A UML + KASAN analogue reproduced the failure class both with no tasklet_kill() and with tasklet_kill() placed before source quiesce, and stayed clean once the kill happened after quiescing the scheduling source. This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), but ISCI needs the kill after wait_for_stop(). Fixes: 6f231dda6808 ("isci: Intel(R) C600 Series Chipset Storage Control Unit Driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419210420.2134639-1-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b34ec33570d97839517606d097dbea5b9830409c Author: Osama Abdelkader Date: Thu Apr 30 21:49:42 2026 +0200 drm/bridge: chipone-icn6211: use devm_drm_bridge_add in i2c probe commit 73d01051e8040c0b1de7fd26b3b8d0c2ffa6895c upstream. Use devm_drm_bridge_add() so the bridge is released if probe fails after registration, and drop drm_bridge_remove() in chipone_i2c_probe. Signed-off-by: Osama Abdelkader Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260430194944.78119-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 1716b7fea2ead941a0dfac06c4504a3437cdf00d Author: Michael Bommarito Date: Tue May 19 09:25:19 2026 -0400 KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits commit 9ce754ed8e7ab4e3999767ce1505f85c449ccb07 upstream. Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range. Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://lore.kernel.org/r/20260519132519.2142458-1-michael.bommarito@gmail.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b427e9f6d81c9341cba23ef92f860f99f830d91d Author: Masami Hiramatsu (Google) Date: Thu May 21 13:49:14 2026 +0900 tracing: Do not call map->ops->elt_free() if elt_alloc() fails commit 8f0f5c4fb9df0e19a341e0c6ed8dc4fda9124f03 upstream. In paths where tracing_map_elt_alloc() failed to allocate objects, the map->ops->elt_alloc() call was never successful. In this case, map->ops->elt_free() should not be called. Link: https://sashiko.dev/#/patchset/20260520223101.34710-1-rosenp%40gmail.com Cc: stable@vger.kernel.org Cc: Tom Zanussi Cc: Mathieu Desnoyers Cc: Rosen Penev Reported-by: Sashiko Fixes: 2734b629525a ("tracing: Add per-element variable support to tracing_map") Link: https://patch.msgid.link/177933895460.108746.5396070821443932634.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c7364cea52531534676b9f7dbc0a477c11f4c050 Author: Zhihao Cheng Date: Tue May 19 17:18:05 2026 +0800 cifs: Fix busy dentry used after unmounting commit c68337442f03953237a94577beb468ab2662a851 upstream. Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry ref_cnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in generic_shutdown_super: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs] The detailed processs is: process A process B kworker fd = open(PATH) vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_fileinfo cfile->dentry = dget(dentry) // dentry->d_lockref.count = 2 close(fd) __fput cifs_close queue_delayed_work(deferredclose_wq, cfile->deferred) dput(dentry) // dentry->d_lockref.count = 1 smb2_deferred_work_close _cifsFileInfo_put list_del(&cifs_file->flist) umount cleanup_mnt deactivate_super cifs_kill_sb cifs_close_all_deferred_files_sb cifs_close_all_deferred_files // cannot find cfile, skip _cifsFileInfo_put kill_anon_super generic_shutdown_super shrink_dcache_for_umount umount_check WARN ! // dentry->d_lockref.count = 1 cifsFileInfo_put_final dput(cifs_file->dentry) // dentry->d_lockref.count = 0 Fix it by flushing 'deferredclose_wq' before calling kill_anon_super. Fetch a reproducer in https://bugzilla.kernel.org/show_bug.cgi?id=221548. Fixes: 340cea84f691c ("cifs: open files should not hold ref on superblock") Cc: stable@vger.kernel.org Reviewed-by: Shyam Prasad N Signed-off-by: Zhihao Cheng Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c0bc4c8bd556cbe036a5b9ed333c0aab9aadfcb8 Author: John Walker Date: Thu May 7 17:07:20 2026 -0600 wifi: cfg80211: advance loop vars in cfg80211_merge_profile() commit 7666dbb1bacc4ba522b96740cba7283d243d16e1 upstream. cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem) but never advances mbssid_elem or sub_elem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same next_mbssid; and the same next_sub bytes are memcpy()'d into merged_ie at a growing offset until the buffer fills. Advance both mbssid_elem and sub_elem to the just-consumed continuation so the next call to cfg80211_get_profile_continuation() searches for a further continuation beyond it (or returns NULL when none exists). A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211_merge_profile (up to as much as 2ms per beacon received), which could theoretically be abused in some way. Cc: stable@vger.kernel.org Fixes: fe806e4992c9 ("cfg80211: support profile split between elements") Signed-off-by: John Walker Link: https://patch.msgid.link/20260507230720.64783-1-johnwalker0@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b0c16d591918fb97bdfe2e3bcd321b16700f692b Author: Marcin Szycik Date: Fri May 15 11:24:10 2026 -0700 ice: fix setting promisc mode while adding VID filter commit ebc8de716c9ec2be384abdc2dd866da26c6580d1 upstream. There are at least two paths through which VSI promiscuous mode can be independently configured via ice_fltr_set_vsi_promisc(): - ice_vlan_rx_add_vid() (netdev op) - ice_service_task() -> ... -> ice_set_promisc() Both paths may try to program promiscuous mode concurrently. One such scenario is: 1. Add ice netdev to bond 2. Add the bond netdev to bridge 3. ice netdev enters allmulticast mode (IFF_ALLMULTI) 4. Service task programs promisc mode filter 5. Bridge -> bond calls ice_vlan_rx_add_vid() Crucially, ice_vlan_rx_add_vid() fails if ice_fltr_set_vsi_promisc() returns any error, including -EEXIST. This causes VLAN filtering setup to fail on the bond interface. ice_set_promisc() already handles -EEXIST correctly. Fix by adding the same -EEXIST check to ice_vlan_rx_add_vid(): if the promisc filter is already programmed, continue without returning error. Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") Cc: stable@vger.kernel.org Signed-off-by: Marcin Szycik Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 55b3e91d62b2f7a24109b2d7c9f4c66d2e3b1ec1 Author: Michael Bommarito Date: Fri May 15 11:24:14 2026 -0700 ixgbevf: fix use-after-free in VEPA multicast source pruning commit 5d49b568c188dc77199d8d2b959c91da8cc27cf1 upstream. ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context. The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here. I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags): BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90) QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible. Fixes: bad17234ba70 ("ixgbevf: Change receive model to use double buffered page based receives") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5a564f737ec54d63e8ee221d3ff396d07586d464 Author: Michael Bommarito Date: Tue May 12 16:51:14 2026 -0400 ipv4: raw: reject IP_HDRINCL packets with ihl < 5 commit 915fab69823a14c170dbaa3b41978768e0fe62fc upstream. raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length: iphlen = iph->ihl * 4; err = -EINVAL; if (iphlen > length) goto error_free; if (iphlen >= sizeof(*iph)) { /* fix up saddr, tot_len, id, csum, transport_header */ } It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic. An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path. Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to. Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it. Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl. Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev. Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Herbert Xu Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/77ec2b5e8111961c2c39883c92e8aa2709039c17.1778614451.git.michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8319af39fef127db1721f9503ee31053a2436c0b Author: Kyle Farnung Date: Wed May 13 21:52:12 2026 -0700 wifi: ath11k: clear shared SRNG pointer state on restart commit f51e4b3b5574ad8cb5b16b11f8a1452147ece87a upstream. LMAC rings reuse the shared rdp/wrp pointer buffers without going through the normal SRNG hw-init path that zeros non-LMAC ring pointers. After restart, ath11k_hal_srng_clear() can therefore hand stale hp/tp state from the previous firmware instance back to the new one. Clear the shared pointer buffers while keeping the allocations in place so restart still avoids reallocating SRNG DMA memory, but starts with fresh ring-pointer state. Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/ Signed-off-by: Kyle Farnung Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit b8abc2ca8c0f20ef418d0d20c04e27f93c16a7a2 Author: Stefano Garzarella Date: Mon May 18 11:06:55 2026 +0200 vsock/virtio: reset connection on receiving queue overflow commit a4f0b001782b21663d10df983b4b208195bec66c upstream. When there is no more space to queue an incoming packet, the packet is silently dropped. This causes data loss without any notification to either peer, since there is no retransmission. Under normal circumstances, this should never happen. However, it could happen if the other peer doesn't respect the credit, or if the skb overhead, which we recently began to take into account with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), is too high. Fix this by resetting the connection and setting the local socket error to ENOBUFS when virtio_transport_recv_enqueue() can no longer queue a packet, so both peers are explicitly notified of the failure rather than silently losing data. Fixes: ae6fcfbf5f03 ("vsock/virtio: discard packets if credit is not respected") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260518090656.134588-2-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ecda37f8faab3220da199335e42564cb7a9ad145 Author: Minh Nguyen Date: Tue May 19 17:23:10 2026 +0700 vsock/vmci: fix UAF when peer resets connection during handshake commit 99e22ddf4edb63dc8382bc028af928056d3450cf upstream. vmci_transport_recv_connecting_server() returned err = 0 for a peer RST in its default switch arm: err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state = TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work(). One second later vsock_pending_work() observed is_pending=true and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object: BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it. The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch. Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Cc: stable@vger.kernel.org Signed-off-by: Minh Nguyen Acked-by: Bryan Tan Link: https://patch.msgid.link/20260519102310.237181-1-minhnguyen.080505@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2b1964af58f124f08a914f1fa433289d68e1020d Author: Steven Rostedt Date: Wed May 20 22:08:01 2026 -0400 ring-buffer: Fix reporting of missed events in iterator commit a254b6d13b0edd6272926674d2afc46d46e496b7 upstream. When tracing is active while reading the trace file, if the iterator reading the buffer detects that the writer has passed the iterator head, it will reset and set a "missed events" flag. This flag is passed to the output processing to show the user that events were missed: CPU:4 [LOST EVENTS] The problem is that the flag is reset after it is checked in ring_buffer_iter_dropped(). But the "trace" file iterates over all the CPU ring buffers and it will check if they are dropped when figuring out which buffer to print next. This prematurely clears the missed_events flag if the CPU buffer with the missed events is not the one that is printed next. On the iteration where the CPU buffer with the missed events is printed, the check if it had missed events would return false and the output does not show that events were missed. Do not reset the missed_events flag when checking if there were missed events, but instead clear it when moving the iterator head to the next event. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260520220801.4fd09d13@fedora Fixes: c9b7a4a72ff64 ("ring-buffer/tracing: Have iterator acknowledge dropped events") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8cf5e4d2ca6b101d163c7423a426fb0aec34f7bb Author: Dawei Feng Date: Wed May 20 15:03:23 2026 +0800 qed: fix double free in qed_cxt_tables_alloc() commit 2bccfb8476ca5f3548afbd623dc7a6980d4e77de upstream. If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again. Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3. Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup. Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260520070323.2762379-1-dawei.feng@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0d7b33ace701fe397e6e4de145f32e098178d901 Author: Nan Li Date: Tue May 12 16:50:01 2026 +0800 netfilter: ipset: stop hash:* range iteration at end commit 0d3a282ab5f165fc207ff49ea5b6ad8f54616bd6 upstream. The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary. Fixes: 48596a8ddc46 ("netfilter: ipset: Fix adding an IPv4 range containing more than 2^31 addresses") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Nan Li Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 19924bdd8a45ebc72a7b84c57fd63057d1dc75ac Author: Haoze Xie Date: Fri May 15 11:19:02 2026 +0800 netfilter: nf_queue: hold bridge skb->dev while queued commit e196115ec330a18de415bdb9f5071aa9f08e53ce upstream. br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCAL_IN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection. When the verdict is reinjected later, br_netif_receive_skb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free. Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEV_DOWN handling. Fixes: ac2863445686 ("netfilter: bridge: add nf_afinfo to enable queuing to userspace") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Haoze Xie Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 784aadea7a108c9f90985683caa87fb0198c6a39 Author: Zhengchuan Liang Date: Wed May 13 15:57:17 2026 +0800 netfilter: ip6t_hbh: reject oversized option lists commit 4322dcde6b4173c2d8e8e6118ed290794263bcc8 upstream. struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors, but hbh_mt6_check() does not reject larger optsnr values supplied from userspace. Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged. `struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array, where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible: [ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]' Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 6afdb8113cb007f9332f59a9b7fd45731b8a9de5 Author: Michael Bommarito Date: Wed May 13 21:37:39 2026 -0400 net: ifb: report ethtool stats over num_tx_queues commit 5db89c99566fc4728cc92e941d8e1975711e24b5 upstream. ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues. The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example: ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10 ifb_get_ethtool_stats() indexes past the tx_private allocation and copies adjacent slab data through ETHTOOL_GSTATS. Use dev->num_tx_queues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifb_q_private entry, which is the queue set IFB can actually populate. Reproduced under UML+KASAN at v7.1-rc2: BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifb_fill_stats_data+0x3c/0xae ifb_get_ethtool_stats+0xc0/0x129 __dev_ethtool+0x1ca5/0x363c dev_ethtool+0x123/0x1b3 dev_ioctl+0x56c/0x744 sock_do_ioctl+0x15f/0x1b2 sock_ioctl+0x4d5/0x50a sys_ioctl+0xd8b/0xde9 With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated tx_private entry. Fixes: a21ee5b2fcb8 ("net: ifb: support ethtools stats") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260514013739.3549624-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b579f3a73da7a7e74213558f4cc3d865c30aaa78 Author: Nicolai Buchwitz Date: Wed May 20 20:43:20 2026 +0200 net: bcmgenet: keep RBUF EEE/PM disabled commit 9a1730245e416d11ad5c0f2c100061d61cc43f60 upstream. Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to DMA, so rx_packets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skb_release_data via bcmgenet_rx_poll on an LPI exit. Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUF_PM_EN is not publicly documented. This shows up more often now that phy_support_eee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes. Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working. Link: https://github.com/raspberrypi/linux/issues/7304 Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support") Cc: stable@vger.kernel.org Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260520184320.652053-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 02c04df84de709060f63e1d52ec67488c4f6f212 Author: Zijing Yin Date: Tue May 19 10:26:33 2026 -0700 phonet/pep: disable BH around forwarded sk_receive_skb() commit dbc81608e3a653dea6cf403f20cae35468b8ab9c upstream. The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case release_sock() -> __release_sock() drops the slock with spin_unlock_bh() and then calls sk->sk_backlog_rcv() with bottom halves enabled. Typical sk_backlog_rcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pep_do_rcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different *child* socket via sk_receive_skb(). That helper takes the child slock with bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path): process context softirq context --------------- --------------- release_sock(listener) __netif_receive_skb() __release_sock() phonet_rcv() spin_unlock_bh() __sk_receive_skb(listener) [BH now ENABLED] [BH already disabled] sk_backlog_rcv: sk_backlog_rcv: pep_do_rcv() pep_do_rcv() sk_receive_skb(child) sk_receive_skb(child) bh_lock_sock_nested(child) bh_lock_sock_nested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path: WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900 __sk_receive_skb net/core/sock.c:563 sk_receive_skb include/net/sock.h:2022 [inline] pep_do_rcv net/phonet/pep.c:675 sk_backlog_rcv include/net/sock.h:1190 __release_sock net/core/sock.c:3216 release_sock net/core/sock.c:3815 pep_sock_accept net/phonet/pep.c:879 Wrap the forwarded sk_receive_skb() in local_bh_disable() / local_bh_enable() so the child slock is always acquired with BH off. local_bh_disable() nests safely on the softirq path. Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer: https://pastebin.com/A3t8xzCR Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Link: https://syzkaller.appspot.com/bug?extid=44f0626dd6284f02663c Cc: stable@vger.kernel.org Signed-off-by: Zijing Yin Acked-by: Rémi Denis-Courmont Reported-by: syzbot+9f4a135646b66c509935@syzkaller.appspotmail.com Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260519172635.86304-1-yzjaurora@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 14b01b9cba04e6ce82825f68fc4c4322fa4ffa43 Author: Michael Bommarito Date: Fri May 15 10:38:19 2026 -0400 Bluetooth: MGMT: validate Add Extended Advertising Data length commit d3f7d17960ed50df3a6709c5158caff989c8c905 upstream. MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload. A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read. Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data. Fixes: 12410572833a ("Bluetooth: Break add adv into two mgmt commands") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c85cff648a2bc92322912db5f1727ad05afae7b6 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon May 18 10:49:49 2026 +0800 Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths commit c1bb9336ae6b54a5f6a353c4bd4ed9a4307e429b upstream. Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities. Fixes: 3b799254cf6f ("Bluetooth: hci_uart: Cancel init work before unregistering") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 915a92182e2cda9cd7d2479020a44c6eda986f7c Author: Jann Horn Date: Tue May 12 22:15:39 2026 +0200 Bluetooth: bnep: Fix UAF read of dev->name commit 59e932ded949fa6f0340bf7c6d7818f962fa4fd2 upstream. bnep_add_connection() needs to keep holding the bnep_session_sem while reading dev->name (just like bnep_get_connlist() does); otherwise the bnep_session() thread can concurrently free the net_device, which can for example be triggered by a concurrent bnep_del_connection(). (This UAF is fairly uninteresting from a security perspective; calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.) Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jann Horn Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1c3d1e1696b72579b970e17999c503a14535205b Author: David Carlier Date: Fri May 15 07:25:25 2026 +0100 Bluetooth: ISO: drop ISO_END frames received without prior ISO_START commit 84c24fb151fc1179355296d7ff29129ac7c42129 upstream. ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing ISO_START by checking conn->rx_len before touching conn->rx_skb, but ISO_END does not. If a peer sends an ISO_END as the first packet on a fresh ISO connection, conn->rx_skb is still NULL and conn->rx_len is zero, so skb_put(conn->rx_skb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this. Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment is logged and dropped instead of crashing the host. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 7eebd4c2c86f573af87ff165d08a83432eb0b919 Author: Safa Karakuş Date: Sat May 16 21:15:04 2026 +0300 Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() commit ab1513597c6cf17cd1ad2a21e3b045421b48e022 upstream. bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Cc: stable@vger.kernel.org Reported-by: Siwei Zhang Reviewed-by: Siwei Zhang Signed-off-by: Safa Karakuş Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ba6d8643019c33428f7c0658863e80e0b04a70f4 Author: Abdun Nihaal Date: Tue May 19 11:57:39 2026 +0530 net: wwan: iosm: fix potential memory leaks in ipc_imem_init() commit c5d93b2c40355e999715262a824965aac025a427 upstream. The memory allocated in ipc_protocol_init() is not freed on the error paths that follow in ipc_imem_init(). Fix that by calling the corresponding release function ipc_protocol_deinit() in the error path. Fixes: 3670970dd8c6 ("net: iosm: shared memory IPC interface") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260519062815.55545-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ffa29cea7bf9a4ef2ea8084967f142e0301ac670 Author: Takashi Iwai Date: Fri May 15 10:55:58 2026 +0200 ALSA: asihpi: Fix potential OOB array access at reading cache commit 7b7d6572145c1dab2dd9bfb550b188e5f0ff3c3f upstream. find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it. Link: https://sashiko.dev/#/patchset/20260511230121.28606-1-rosenp%40gmail.com Cc: Link: https://patch.msgid.link/20260515085606.242284-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 786ff77a920c7c319fa88f6c951820a12eb50aaa Author: Cássio Gabriel Date: Tue May 19 00:32:15 2026 -0300 ALSA: ua101: Reject too-short USB descriptors commit b59d5c51bb328a60749b4dd5fe7e649bfb4089b4 upstream. find_format_descriptor() walks the class-specific interface extras by advancing with bLength. It rejects descriptors that extend past the remaining buffer, but it does not reject descriptor lengths smaller than a USB descriptor header. Reject too-short descriptors before using bLength to advance the local scan. This keeps the UA-101 parser robust against malformed descriptor data and matches the usual USB descriptor walking rules. Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-alsa-ua101-desc-len-v1-1-4307d1a5e054@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6ed16a40b162e9d87d9ac8bed4d7f0e3e807700e Author: Abdurrahman Hussain Date: Fri May 15 15:11:48 2026 -0700 hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX commit eee213daa1e1b402eb631bcd1b8c5aa340a6b081 upstream. adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2C_SMBUS_BLOCK_MAX = 32): memcpy(values, &data.block[1], data.block[0]); If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call if (ret != 4) return -EIO; check has a chance to reject the response. Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-2-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 14f2c14ae86c4af17a0a9f8ab46dacf2d5fd1d8a Author: Greg Kroah-Hartman Date: Wed May 20 15:05:04 2026 +0200 sysfs: don't remove existing directory on update failure commit 237557b8a81ab948e8332f7c0058e758f081c0a3 upstream. When sysfs_update_group() is called for a named group and create_files() fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on the group directory. In the update path, kn was obtained via kernfs_find_and_get() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create. Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by remove_files() inside create_files(), but can be repopulated by a retry. Cc: Rajat Jain Fixes: c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates") Cc: stable Assisted-by: gkh_clanker_t1000 Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/2026052003-uniquely-hastily-c093@gregkh Signed-off-by: Greg Kroah-Hartman commit cf20038657d6d4974349556a34e08fe0490bebbc Author: Asim Viladi Oglu Manizada Date: Sat May 16 21:15:39 2026 +0000 smb: client: reject userspace cifs.spnego descriptions commit 3da1fdf4efbc490041eb4f836bf596201203f8f2 upstream. cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key. Fixes: f1d662a7d5e5 ("[CIFS] Add upcall files for cifs to use spnego/kerberos") Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix Reviewed-by: David Howells Signed-off-by: Asim Viladi Oglu Manizada Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5752c2c7795713d9a578b6447e591e7f7ac1447c Author: Sasha Levin Date: Tue May 26 09:03:28 2026 -0400 Revert "s390/cio: Fix device lifecycle handling in css_alloc_subchannel()" This reverts commit fd295a75d828c11acfcc6869c2a12cdaaf9b7722. Signed-off-by: Sasha Levin commit cfdc4e3acc7d0b55bd2b5386c2ec98069bc13b13 Author: Sasha Levin Date: Mon May 25 20:46:05 2026 -0400 Revert "x86/vdso: Fix output operand size of RDPID" This reverts commit 757a9e78a1c5b824d0a2b7de14c3cd8d841dfbee. Signed-off-by: Sasha Levin commit 44839ea7e96b3659a1606f3d5267063135479b7c Author: Deepanshu Kartikey Date: Mon May 25 13:48:54 2026 +0800 wifi: mac80211: check tdls flag in ieee80211_tdls_oper [ Upstream commit 7d73872d949c488a1d7c308031d6a9d89b5e0a8b ] When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers. Reported-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=56b6a844a4ea74487b7b Tested-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com Suggested-by: Johannes Berg Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260313092417.520807-1-kartikey406@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Sasha Levin commit a445a4717bcd4810b25ea92b15ff67cba0255b8a Author: Pengpeng Hou Date: Thu May 21 10:28:39 2026 +0800 s390/debug: Reject zero-length input before trimming a newline [ Upstream commit c366a7b5ed7564e41345c380285bd3f6cb98971b ] debug_get_user_string() copies the userspace buffer into a newly allocated NUL-terminated buffer and then unconditionally looks at buffer[user_len - 1] to strip a trailing newline. A zero-length write reaches this helper unchanged, so the newline trim reads before the start of the allocated buffer. Reject empty writes before accessing the last input byte. Fixes: 66a464dbc8e0 ("[PATCH] s390: debug feature changes") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Benjamin Block Reviewed-by: Vasily Gorbik Tested-by: Vasily Gorbik Link: https://lore.kernel.org/r/20260417073530.96002-1-pengpeng@iscas.ac.cn Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit d261ead565a080e3411b0dd04e6d58a52471cac8 Author: Pavel Begunkov Date: Thu May 21 13:49:19 2026 +0800 io_uring: prevent opcode speculation [ Upstream commit 1e988c3fe1264708f4f92109203ac5b1d65de50b ] sqe->opcode is used for different tables, make sure we santitise it against speculations. Cc: stable@vger.kernel.org Fixes: d3656344fea03 ("io_uring: add lookup table for various opcode needs") Signed-off-by: Pavel Begunkov Reviewed-by: Li Zetao Link: https://lore.kernel.org/r/7eddbf31c8ca0a3947f8ed98271acc2b4349c016.1739568408.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Robert Garcia Signed-off-by: Sasha Levin commit d84ce1786ce40fdd3dd98db47aec5527817e1ef6 Author: Allison Henderson Date: Tue May 5 16:43:36 2026 -0700 net/rds: reset op_nents when zerocopy page pin fails commit e174929793195e0cd6a4adb0cad731b39f9019b4 upstream. When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260505234336.2132721-1-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 508f0f7af2d447a3bda89d082dfec80bb5f2e65c Author: Nicholas Carlini Date: Mon May 11 18:02:16 2026 +0000 io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot. Cc: stable@vger.kernel.org # 5.7+ Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work") Signed-off-by: Nicholas Carlini Signed-off-by: Greg Kroah-Hartman commit 4b833e5f9f84fb3869bcc48d0a4bb67d24526512 Author: Johan Hovold Date: Fri May 8 16:44:46 2026 +0200 drm/gma500/oaktrail_lvds: fix i2c adapter leaks on init commit 84d1c9b416d54afe760ca4c378bd95c89261254c upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. Make sure to drop the references taken by i2c_get_adapter() when falling back to allocating an adapter as well as on late errors to allow the looked up adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5fe9f505d8578852c30668567bc3ce52e776e8c7 Author: Johan Hovold Date: Fri May 8 16:44:45 2026 +0200 drm/gma500/oaktrail_lvds: fix hang on init failure commit 657a091ab6d01d0091b77660c75cfed573c9a53e upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors. Fixes: a57ebfc0b4da ("drm/gma500: Make oaktrail lvds use ddc adapter from drm_connector") Cc: stable@vger.kernel.org # 6.0 Cc: Patrik Jakobsson Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f2f074bf43b915bd2e90fd8116e1d8f1b345ec6 Author: Johan Hovold Date: Fri May 8 16:44:44 2026 +0200 drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup commit 950953f774b3f69da6f413e045ef075e1f3da2df upstream. Make sure to drop the reference taken to the I2C adapter (and its module) when setting up HDMI to allow the adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit a88fe1315b3becd64d6593e72eb5de91d7b6ce8b Author: Gyeyoung Baek Date: Sun Apr 19 16:17:16 2026 +0900 drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout() commit 459d75523b71c0ec254d153d8850d0b7008af396 upstream. dma_resv_wait_timeout() returns a positive 'remaining jiffies' value on success, 0 on timeout, and -errno on failure. panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed ioctl handler, so positive values reach userspace as bogus errors. Explicitly set ret to 0 on the success path. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: stable@vger.kernel.org Signed-off-by: Gyeyoung Baek Reviewed-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 8e7bfea35675b7ab051d745fe44cdcb672f188e6 Author: Sebastian Brzezinka Date: Thu Apr 16 13:31:18 2026 +0200 drm/i915: skip __i915_request_skip() for already signaled requests commit 4cfe4c0efbdcde742a47813180cc69b132d7598e upstream. After a GPU reset the HWSP is zeroed, so previously completed requests appear incomplete. If such a request is picked up during reset_rewind() and marked guilty, i915_request_set_error_once() returns early (fence already signaled), leaving fence.error without a fatal error code. The subsequent __i915_request_skip() then hits: ``` GEM_BUG_ON(!fatal_error(rq->fence.error)) ``` Fixes a kernel BUG observed on Sandy Bridge (Gen6) during heartbeat-triggered engine resets. ``` kernel BUG at drivers/gpu/drm/i915/i915_request.c:556! RIP: __i915_request_skip+0x15e/0x1d0 [i915] ... __i915_request_reset+0x212/0xa70 [i915] reset_rewind+0xe4/0x280 [i915] intel_gt_reset+0x30d/0x5b0 [i915] heartbeat+0x516/0x530 [i915] ``` Guard __i915_request_skip() with i915_request_signaled(), if the fence is already signaled, the ring content is committed and there is nothing left to skip. Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729 Signed-off-by: Sebastian Brzezinka Cc: stable@vger.kernel.org # v5.7+ Reviewed-by: Krzysztof Karas Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com (cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit cee13f3913d769c4ba51b9c9adfd6d9d333a3e5a Author: Naval Alcalá Date: Sat May 9 10:43:44 2026 +0800 iommu/vt-d: Disable DMAR for Intel Q35 IGFX commit 2cda2e10dc8343ae01eae9e999a876b7e7d37861 upstream. Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR behaviour similar to other G4x/GM45 devices for which DMAR is already disabled via quirks. When DMAR is enabled, the system may hard lock up during boot or early device initialization, requiring a reset. Add the missing PCI ID to the existing quirk list to disable DMAR for this device. Fixes: 1f76249cc3be ("iommu/vt-d: Declare Broadwell igfx dmar support snafu") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=201185 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216064 Signed-off-by: Naval Alcalá Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0b6a3bcb91bc5bfeda39f0df3b71bab62c13e9da Author: Raphael Zimmer Date: Tue May 12 09:29:30 2026 +0200 libceph: handle rbtree insertion error in decode_choose_args() commit d289478cfc0bcf81c7914200d6abdcb78bd04ded upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3f42508191e129ee6b5ea96578d5cab14f2a013a Author: Raphael Zimmer Date: Wed Apr 22 10:47:13 2026 +0200 libceph: Fix potential out-of-bounds access in crush_decode() commit 4c79fc2d598694bda845b46229c9d48b65042970 upstream. A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket(). Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 7169f326a23d0f547fcd90e68b72fd387622e126 Author: Raphael Zimmer Date: Tue May 12 18:16:40 2026 +0200 libceph: Fix potential null-ptr-deref in decode_choose_args() commit 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an array of max_buckets CRUSH buckets is decoded, where some indices may not refer to actual buckets and are therefore set to NULL. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). When decoding a crush_choose_arg_map, a series of choose_args for different buckets is decoded, with the bucket_index being read from the incoming message. It is only checked that the bucket index does not exceed max_buckets, but not that it doesn't point to an index with a NULL bucket. If a (potentially corrupted) message contains a crush_choose_arg_map including such a bucket_index, a null pointer dereference may occur in the subsequent processing when attempting to access the bucket with the given index. This patch fixes the issue by extending the affected check. Now, it is only attempted to access the bucket if it is not NULL. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 8713bbc4b2b9ad78f803978e54b7e49dd21bd9be Author: Raphael Zimmer Date: Tue May 5 11:08:12 2026 +0200 libceph: Fix potential out-of-bounds access in osdmap_decode() commit 35d0ed82d03e5ee77ea4f31f20e29562a7721649 upstream. When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight). Cc: stable@vger.kernel.org Fixes: dcbc919a5dc8 ("libceph: switch osdmap decoding to use ceph_decode_entity_addr") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c16516ec8195fe7da1129c5887fb8a36a793ffe0 Author: Ma Ke Date: Sun Nov 16 10:44:11 2025 +0800 powerpc/warp: Fix error handling in pika_dtm_thread commit 108d7f951271cbd36ca36efc5e5d106966f5180c upstream. pika_dtm_thread() acquires client through of_find_i2c_device_by_node() but fails to release it in error handling path. This could result in a reference count leak, preventing proper cleanup and potentially leading to resource exhaustion. Add put_device() to release the reference in the error handling path. Found by code review. Cc: stable@vger.kernel.org Fixes: 3984114f0562 ("powerpc/warp: Platform fix for i2c change") Signed-off-by: Ma Ke Reviewed-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit ecf94823c5c6a20790bb76ed2816822b0beb0c22 Author: Viacheslav Dubeyko Date: Thu Apr 9 12:26:02 2026 -0700 ceph: fix a buffer leak in __ceph_setxattr() commit 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e upstream. The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak. Cc: stable@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 728ab0c72e49ca27185067984cd565425eb69b2e Author: Cássio Gabriel Date: Thu May 7 00:40:51 2026 -0300 ALSA: usb-audio: Bound MIDI endpoint descriptor scans commit d6854daa67be623860f4e1873fd3d3c275aba4ed upstream. snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan. Fixes: 5c6cd7021a05 ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dc496b71ab6cd9648826d3c8ffc2a7b4adbce19f Author: Chaitanya Kumar Borah Date: Tue May 5 14:39:20 2026 +0530 drm/i915/dp: Fix VSC dynamic range signaling for RGB formats commit 1ae15b6c7965d137eef21f2cc7d367b29cb88369 upstream. For RGB, set dynamic_range to CTA or VESA based on crtc_state->limited_color_range so sinks apply correct quantization. YCbCr remains limited (CTA) range. (DP v1.4, Table 5-1) v2: - Added Reported-by and Tested-by tags v3: - Add back YCbCr comment(Suraj) Cc: stable@vger.kernel.org #v5.8+ Reported-by: DeepChirp Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874 Tested-by: DeepChirp Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP") Assisted-by: GitHub-Copilot:GPT-5.4 Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 1cfa2d59f669db28d6292d10ff87ca6837c781b0 Author: Ye Bin Date: Thu May 14 21:14:18 2026 +0800 smb/client: fix possible infinite loop and oob read in symlink_data() commit 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 upstream. On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8 Reported-by: ChenXiaoSong Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: stable@vger.kernel.org Signed-off-by: Ye Bin Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9dd2fe4b270490979532fa04f70ee7d3f021b6eb Author: Qiang Ma Date: Tue May 12 09:53:13 2026 +0800 KVM: x86: Fix Xen hypercall tracepoint argument assignment commit 2b72f1674e427c56e3772c5ccf785fdda2138820 upstream. TRACE_EVENT(kvm_xen_hypercall) stores a5 in __entry->a4 instead of __entry->a5. That overwrites the recorded a4 argument and leaves a5 unset in the trace entry. Fix the typo so both arguments are captured correctly. Signed-off-by: Qiang Ma Link: https://patch.msgid.link/20260512015313.1685784-1-maqianga@uniontech.com/ Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 31a9d9f9942885aae356a1a57c79e82c5b5b0828 Author: Junrui Luo Date: Wed Apr 15 17:26:55 2026 +0800 KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic commit 16d990a15491cf76cd6eef0846e1b4100e63261a upstream. kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Fixes: 73f91b004321 ("KVM: s390: pci: enable host forwarding of Adapter Event Notifications") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 0eb281eb95b2d4eea4db1da5fe91023aecc97095 Author: Aaron Sacks Date: Tue May 12 02:07:42 2026 -0400 KVM: Reject wrapped offset in kvm_reset_dirty_gfn() commit 577a8d3bae0531f0e5ccfac919cd8192f920a804 upstream. kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range. Fixes: fb04a1eddb1a ("KVM: X86: Implement ring-based dirty memory tracking") Cc: stable@vger.kernel.org Signed-off-by: Aaron Sacks Link: https://patch.msgid.link/20260512060742.1628959-1-contact@xchglabs.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit da57e656f122233f684419608dc0f9de9c02165d Author: Sergio Correia Date: Tue May 12 14:28:59 2026 +0100 audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV commit f9e1c1324b4d98d591a6f7568fdebf5cf456dfc2 upstream. AUDIT_ADD_RULE and AUDIT_DEL_RULE correctly check for AUDIT_LOCKED and return -EPERM, but AUDIT_TRIM and AUDIT_MAKE_EQUIV do not. This allows a process with CAP_AUDIT_CONTROL to modify directory tree watches and equivalence mappings even when the audit configuration has been locked, undermining the purpose of the lock. Add AUDIT_LOCKED checks to both commands. Cc: stable@vger.kernel.org Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 7f74f67422c461a07982095e9b9bbde3a34c95b7 Author: Zoran Ilievski Date: Mon May 11 08:40:02 2026 +0200 net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled commit 2c308cf34284420963607d677d576a2b4124d8bd upstream. The shutdown handler aq_pci_shutdown() unconditionally calls pci_wake_from_d3(pdev, false), clearing the PCI PME_En bit even when wake-on-LAN has been configured. While aq_nic_shutdown() correctly programs the NIC firmware via aq_nic_set_power() to listen for magic packets, the PCI subsystem will not propagate the resulting PME wake event from D3, so the system never wakes after poweroff. WOL from suspend (S3) is unaffected because aq_suspend_common() does not touch pci_wake_from_d3() and relies on the PM core's wake configuration via device_may_wakeup(). This affects all atlantic-supported NICs (AQC107/108/111/112/113); users have reported that WOL works if the atlantic driver is never loaded, but breaks once it has run its shutdown path. Pass the configured WOL state to pci_wake_from_d3() instead of a literal false, so the PCI PME_En bit is preserved when the user has armed WOL via ethtool. Fixes: 90869ddfefeb ("net: aquantia: Implement pci shutdown callback") Cc: stable@vger.kernel.org Signed-off-by: Zoran Ilievski Reviewed-by: Sukhdeep Singh Link: https://patch.msgid.link/20260511064002.1857-1-goodboy@rexbytes.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7b96242ceedfe249f158419f3254bcee04173ffe Author: Li Xiasong Date: Thu May 7 22:04:23 2026 +0800 netfilter: nft_ct: fix missing expect put in obj eval commit 19f94b6fee75b3ef7fbc06f3745b9a771a8a19a4 upstream. nft_ct_expect_obj_eval() allocates an expectation and may call nf_ct_expect_related(), but never drops its local reference. Add nf_ct_expect_put(exp) before return to balance allocation. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 95de7bb4bf535a9288549d401ebde83cdcbf2792 Author: Sergio Correia Date: Tue May 12 14:28:33 2026 +0100 audit: fix incorrect inheritable capability in CAPSET records commit e4a640475e43f406fdfd56d370b1f34b0cbbc18d upstream. __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008. Cc: stable@vger.kernel.org Fixes: e68b75a027bb ("When the capset syscall is used it is not possible for audit to record the actual capbilities being added/removed. This patch adds a new record type which emits the target pid and the eff, inh, and perm cap sets.") Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 2c61272875322d44de2eb019d9ab03b28b8794c3 Author: Li Xiasong Date: Thu May 7 22:04:22 2026 +0800 netfilter: nf_conntrack_sip: get helper before allocating expectation commit eb6317739b1ea3ab28791e1f91b24781905fa815 upstream. process_register_request() allocates an expectation and then checks whether a conntrack helper is available. If helper lookup fails, the function returns early and the allocated expectation is left behind. Reorder the code to fetch and validate helper before calling nf_ct_expect_alloc(). This keeps the logic simpler and removes the leak path while preserving existing behavior. Fixes: e14575fa7529 ("netfilter: nf_conntrack: use rcu accessors where needed") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 73f120029d780ca09fd4f40bf27efe805c140a97 Author: Matt Vollrath Date: Wed May 6 14:48:11 2026 -0700 i40e: Cleanup PTP pins on probe failure commit 678b713ece1e853f11e670a84cb887c35e1381b7 upstream. PTP pin structs are allocated early in probe, but never cleaned up. Fix this by calling i40e_ptp_free_pins in the error path. To support this, i40e_ptp_free_pins is added to the header and pin_config is correctly nullified after being freed. This has been an issue since i40e_ptp_alloc_pins was introduced. Fixes: 1050713026a08 ("i40e: add support for PTP external synchronization clock") Reported-by: Kohei Enju Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Reviewed-by: Kohei Enju Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-2-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a4fe4eb580bbc7439f649a496d4cf38415a4021c Author: Herbert Xu Date: Tue May 5 17:02:45 2026 +0800 crypto: af_alg - Cap AEAD AD length to 0x80000000 commit e4c06479d7059888adf2f22bc1ebcf053bf691a2 upstream. In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. Reported-by: Yiming Qian Fixes: 400c40cf78da ("crypto: algif - add AEAD support") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f98a07e5a05ceae39d82be0b124e018e743999b3 Author: Tonghao Zhang Date: Thu Oct 16 20:51:36 2025 +0800 net: bonding: update the slave array for broadcast mode [ Upstream commit e0caeb24f538c3c9c94f471882ceeb43d9dc2739 ] This patch fixes ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad"). Before this commit, on the broadcast mode, all devices were traversed using the bond_for_each_slave_rcu. This patch supports traversing devices by using all_slaves. Therefore, we need to update the slave array when enslave or release slave. Fixes: ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad") Cc: Simon Horman Cc: Jonathan Corbet Cc: Andrew Lunn Cc: Reported-by: Jiri Slaby Tested-by: Jiri Slaby Link: https://lore.kernel.org/all/a97e6e1e-81bc-4a79-8352-9e4794b0d2ca@kernel.org/ Signed-off-by: Tonghao Zhang Reviewed-by: Hangbin Liu Reviewed-by: Nikolay Aleksandrov Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20251016125136.16568-1-tonghao@bamaicloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17931814a292bff1a9c1c04c7d1199f1bd4c529f Author: Hangbin Liu Date: Wed Nov 5 07:26:20 2025 +0000 bonding: fix NULL pointer dereference in actor_port_prio setting [ Upstream commit 067bf016e99ad72aa4ff869d6dec1fd62a9c6202 ] Liang reported an issue where setting a slave’s actor_port_prio to predefined values such as 0, 255, or 65535 would cause a system crash. The problem occurs because in bond_opt_parse(), when the provided value matches a predefined table entry, the function returns that table entry, which does not contain slave information. Later, in bond_option_actor_port_prio_set(), calling bond_slave_get_rtnl() leads to a NULL pointer dereference. Since actor_port_prio is defined as a u16 and initialized to the default value of 255 in ad_initialize_port(), there is no need for the bond_actor_port_prio_tbl. Using the BOND_OPTFLAG_RAWVAL flag is sufficient. Fixes: 6b6dc81ee7e8 ("bonding: add support for per-port LACP actor priority") Reported-by: Liang Li Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20251105072620.164841-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b1902a1a686606ad64a7c8e7333e953855a6bbf Author: Breno Leitao Date: Mon Apr 20 03:18:36 2026 -0700 netconsole: avoid out-of-bounds access on empty string in trim_newline() [ Upstream commit 7079c8c13f2d33992bc846240517d88f4ab07781 ] trim_newline() unconditionally dereferences s[len - 1] after computing len = strnlen(s, maxlen). When the string is empty, len is 0 and the expression underflows to s[(size_t)-1], reading (and potentially writing) one byte before the buffer. The two callers feed trim_newline() with the result of strscpy() from configfs store callbacks (dev_name_store, userdatum_value_store). configfs guarantees count >= 1 reaches the callback, but the byte itself can be NUL: a userspace write(fd, "\0", 1) leaves the destination empty after strscpy() and triggers the underflow. The OOB write only fires if the adjacent byte happens to be '\n', so this is not a security issue, but the access is undefined behaviour either way. This pattern is commonly flagged by LLM-based code reviewers. While it is not a security fix, the underlying access is undefined behaviour and the change is small and self-contained, so it is a reasonable candidate for the stable trees. Guard the dereference on a non-zero length. Fixes: ae001dc67907 ("net: netconsole: move newline trimming to function") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Reviewed-by: Gustavo Luiz Duarte Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-netcons_trim_newline-v1-1-dc35889aeedf@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ea9b8cffee3f117043857a0107a77387709737da Author: Takahiro Kuwano Date: Thu Apr 6 15:17:46 2023 +0900 mtd: spi-nor: spansion: Enable JFFS2 write buffer for S25FS256T [ Upstream commit a9180c298d3527f43563d02a62cb9e7e145642c6 ] Infineon(Cypress) SEMPER NOR flash family has on-die ECC and its program granularity is 16-byte ECC data unit size. JFFS2 supports write buffer mode for ECC'd NOR flash. Provide a way to clear the MTD_BIT_WRITEABLE flag in order to enable JFFS2 write buffer mode support. Drop the comment as the same info is now specified in cypress_nor_ecc_init(). Fixes: 6afcc84080c4 ("mtd: spi-nor: spansion: Add support for Infineon S25FS256T") Suggested-by: Tudor Ambarus Signed-off-by: Takahiro Kuwano Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/641bfb26c6e059915ae920117b7ec278df1a6f0a.1680760742.git.Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus Signed-off-by: Sasha Levin commit dfe25c554daa12ee26eb3540bbded57733ed5d9c Author: Peter Ujfalusi Date: Wed Feb 5 15:52:31 2025 +0200 ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data() [ Upstream commit d8d99c3b5c485f339864aeaa29f76269cc0ea975 ] The nullity of sps->cstream should be checked similarly as it is done in sof_set_stream_data_offset() function. Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference. Fixes: 090349a9feba ("ASoC: SOF: Add support for compress API for stream data/offset") Cc: stable@vger.kernel.org Reported-by: Curtis Malainey Closes: https://github.com/thesofproject/linux/pull/5214 Signed-off-by: Peter Ujfalusi Reviewed-by: Daniel Baluta Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Curtis Malainey Link: https://patch.msgid.link/20250205135232.19762-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f7213206c764bb3a2f2e211d774bf73295c34860 Author: Peter Ujfalusi Date: Wed Feb 5 15:52:32 2025 +0200 ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close [ Upstream commit 46c7b901e2a03536df5a3cb40b3b26e2be505df6 ] The spcm->stream[substream->stream].substream is set during open and was left untouched. After the first PCM stream it will never be NULL and we have code which checks for substream NULLity as indication if the stream is active or not. For the compressed cstream pointer the same has been done, this change will correct the handling of PCM streams. Fixes: 090349a9feba ("ASoC: SOF: Add support for compress API for stream data/offset") Cc: stable@vger.kernel.org Reported-by: Curtis Malainey Closes: https://github.com/thesofproject/linux/pull/5214 Signed-off-by: Peter Ujfalusi Reviewed-by: Daniel Baluta Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Curtis Malainey Link: https://patch.msgid.link/20250205135232.19762-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit edcfe9828953f7f81e81afc1f478e3c986f52bd4 Author: Cássio Gabriel Date: Wed May 6 00:34:47 2026 -0300 ALSA: core: Serialize deferred fasync state checks [ Upstream commit 5337213381df578058e2e41da93cbd0e4639935f ] snd_fasync_helper() updates fasync->on under snd_fasync_lock, and snd_fasync_work_fn() now also evaluates fasync->on under the same lock. snd_kill_fasync() still tests the flag before taking the lock, leaving an unsynchronized read against FASYNC enable/disable updates. Move the enabled-state check into the locked section. Also clear fasync->on under snd_fasync_lock in snd_fasync_free() before unlinking the pending entry. Together with the locked sender-side check, this publishes teardown before flushing the deferred work and prevents a racing sender from requeueing the entry after free has started. Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers") Fixes: 8146cd333d23 ("ALSA: core: Fix potential data race at fasync handling") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260506-alsa-core-fasync-on-lock-v1-1-ea48c77d6ca4@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ce31568632dd35da743e8d210c09ac088cd9d38e Author: Takashi Iwai Date: Fri Aug 29 17:13:33 2025 +0200 ALSA: misc: Use guard() for spin locks [ Upstream commit b8e1684163ae52db90f428965bd9aaff7205c02e ] Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250829151335.7342-20-tiwai@suse.de Stable-dep-of: 5337213381df ("ALSA: core: Serialize deferred fasync state checks") Signed-off-by: Sasha Levin commit 6279992c9ba2774901c9d4dd4a481162e2534714 Author: Filipe Manana Date: Tue Apr 28 16:58:56 2026 +0100 btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file() [ Upstream commit c73370c677646e86fc4b1780fb07027bdf847375 ] The trace event btrfs_sync_file() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dget_parent(), can sleep, triggering a kernel splat. This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following: [53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 32773, name: xfs_io [53.988] preempt_count: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfs_io Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] [54.076] dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ? __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094] __x64_sys_pwrite64+0x8d/0xc0 [54.096] ? do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ? clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e So stop using dget_parent() and dput() and access the parent dentry directly as dentry->d_parent. This is also what ext4 is doing in its equivalent trace event ext4_sync_file_enter(). Fixes: a85b46db143f ("btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 150d06aae1839a6564ab200ef0e7291c3528bbb0 Author: Justin Chen Date: Mon Apr 6 10:57:55 2026 -0700 net: bcmgenet: fix leaking free_bds [ Upstream commit 3f3168300efb839028328d720ab3962f91d6a0d0 ] While reclaiming the tx queue we fast forward the write pointer to drop any data in flight. These dropped frames are not added back to the pool of free bds. We also need to tell the netdev that we are dropping said data. Fixes: f1bacae8b655 ("net: bcmgenet: support reclaiming unsent Tx packets") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd83c9bef0eb8c34630a8c2b2bd5cdc03a07252c Author: Ryo Takakura Date: Wed Jul 2 18:24:17 2025 +0900 net: bcmgenet: Initialize u64 stats seq counter [ Upstream commit ffc2c8c4a714df53a715827d6334ab9474424f6a ] Initialize u64 stats as it uses seq counter on 32bit machines as suggested by lockdep below. [ 1.830953][ T1] INFO: trying to register non-static key. [ 1.830993][ T1] The code is fine but needs lockdep annotation, or maybe [ 1.831027][ T1] you didn't initialize this object before use? [ 1.831057][ T1] turning off the locking correctness validator. [ 1.831090][ T1] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc2-v7l+ #1 PREEMPT [ 1.831097][ T1] Tainted: [W]=WARN [ 1.831099][ T1] Hardware name: BCM2711 [ 1.831101][ T1] Call trace: [ 1.831104][ T1] unwind_backtrace from show_stack+0x18/0x1c [ 1.831120][ T1] show_stack from dump_stack_lvl+0x8c/0xcc [ 1.831129][ T1] dump_stack_lvl from register_lock_class+0x9e8/0x9fc [ 1.831141][ T1] register_lock_class from __lock_acquire+0x420/0x22c0 [ 1.831154][ T1] __lock_acquire from lock_acquire+0x130/0x3f8 [ 1.831166][ T1] lock_acquire from bcmgenet_get_stats64+0x4a4/0x4c8 [ 1.831176][ T1] bcmgenet_get_stats64 from dev_get_stats+0x4c/0x408 [ 1.831184][ T1] dev_get_stats from rtnl_fill_stats+0x38/0x120 [ 1.831193][ T1] rtnl_fill_stats from rtnl_fill_ifinfo+0x7f8/0x1890 [ 1.831203][ T1] rtnl_fill_ifinfo from rtmsg_ifinfo_build_skb+0xd0/0x138 [ 1.831214][ T1] rtmsg_ifinfo_build_skb from rtmsg_ifinfo+0x48/0x8c [ 1.831225][ T1] rtmsg_ifinfo from register_netdevice+0x8c0/0x95c [ 1.831237][ T1] register_netdevice from register_netdev+0x28/0x40 [ 1.831247][ T1] register_netdev from bcmgenet_probe+0x690/0x6bc [ 1.831255][ T1] bcmgenet_probe from platform_probe+0x64/0xbc [ 1.831263][ T1] platform_probe from really_probe+0xd0/0x2d4 [ 1.831269][ T1] really_probe from __driver_probe_device+0x90/0x1a4 [ 1.831273][ T1] __driver_probe_device from driver_probe_device+0x38/0x11c [ 1.831278][ T1] driver_probe_device from __driver_attach+0x9c/0x18c [ 1.831282][ T1] __driver_attach from bus_for_each_dev+0x84/0xd4 [ 1.831291][ T1] bus_for_each_dev from bus_add_driver+0xd4/0x1f4 [ 1.831303][ T1] bus_add_driver from driver_register+0x88/0x120 [ 1.831312][ T1] driver_register from do_one_initcall+0x78/0x360 [ 1.831320][ T1] do_one_initcall from kernel_init_freeable+0x2bc/0x314 [ 1.831331][ T1] kernel_init_freeable from kernel_init+0x1c/0x144 [ 1.831339][ T1] kernel_init from ret_from_fork+0x14/0x20 [ 1.831344][ T1] Exception stack(0xf082dfb0 to 0xf082dff8) [ 1.831349][ T1] dfa0: 00000000 00000000 00000000 00000000 [ 1.831353][ T1] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.831356][ T1] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 Fixes: 59aa6e3072aa ("net: bcmgenet: switch to use 64bit statistics") Reviewed-by: Florian Fainelli Signed-off-by: Ryo Takakura Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250702092417.46486-1-ryotkkr98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1214d912ffc9f9999ab12339a2bc1a964ab80083 Author: Eric Dumazet Date: Thu Apr 30 08:00:56 2026 +0000 net/sched: sch_pie: annotate more data-races in pie_dump_stats() [ Upstream commit 6d4106e8df94c0c52cf3ca6a6a0d01567fb3844e ] My prior patch missed few READ_ONCE()/WRITE_ONCE() annotations. Fixes: 5154561d9b11 ("net/sched: sch_pie: annotate data-races in pie_dump_stats()") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260430080056.35104-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 043834e72337ee7b4e9685859888623ba1504ac7 Author: Greg Kroah-Hartman Date: Mon May 18 19:52:52 2026 +0800 smb: client: fix OOB reads parsing symlink error response [ Upstream commit 3df690bba28edec865cf7190be10708ad0ddd67e ] When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server. symlink_data() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits. smb2_parse_symlink_response() then bounds-checks the substitute name using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from iov_base. That value is computed as sizeof(smb2_err_rsp) + sizeof(smb2_symlink_err_rsp), which is correct only when ErrorContextCount == 0. With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iov_len. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2). Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset. Because sub_offs and sub_len are 16bits, the pointer math will not overflow here with the new greater-than. Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: stable Reviewed-by: Paulo Alcantara (Red Hat) Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steve French Signed-off-by: Alva Lan Signed-off-by: Sasha Levin commit c8fe3ef6101f28277a07242dd5d3a06a7a459faf Author: Liang Jie Date: Mon May 18 19:52:51 2026 +0800 smb: client: correctly handle ErrorContextData as a flexible array [ Upstream commit 215b7f9ecb8d7c14d56febdcdd246f3579c32aba ] The `smb2_symlink_err_rsp` structure was previously defined with `ErrorContextData` as a single `__u8` byte. However, the `ErrorContextData` field is intended to be a variable-length array based on `ErrorDataLength`. This mismatch leads to incorrect pointer arithmetic and potential memory access issues when processing error contexts. Updates the `ErrorContextData` field to be a flexible array (`__u8 ErrorContextData[]`). Additionally, it modifies the corresponding casts in the `symlink_data()` function to properly handle the flexible array, ensuring correct memory calculations and data handling. These changes improve the robustness of SMB2 symlink error processing. Signed-off-by: Liang Jie Suggested-by: Tom Talpey Signed-off-by: Steve French [ Remove the __counted_by_le annotation in v6.1. ] Signed-off-by: Alva Lan Signed-off-by: Sasha Levin commit 0a1478dd4cc9dbf7888759e2e8ea6214c5cfd924 Author: Paolo Abeni Date: Wed Apr 29 09:39:11 2026 +0200 net/sched: cls_flower: revert unintended changes [ Upstream commit 1e01abec856593e02cd69fd95b784c10dd46880c ] While applying the blamed commit 4ca07b9239bd ("net: mctp i2c: check length before marking flow active"), I unintentionally included unrelated and unacceptable changes. Revert them. Fixes: 4ca07b9239bd ("net: mctp i2c: check length before marking flow active") Reported-by: Jeremy Kerr Closes: https://lore.kernel.org/netdev/bd8704fe0bd53e278add5cde4873256656623e2e.camel@codeconstruct.com.au/ Signed-off-by: Paolo Abeni Link: https://patch.msgid.link/043026a53ff84da88b17648c4b0d17f0331749cb.1777447863.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0c9f399b37ce22a5ed94cc51f03ed07ac7f38e32 Author: Jakub Kicinski Date: Tue Apr 28 16:15:59 2026 -0700 net: tls: fix strparser anchor skb leak on offload RX setup failure [ Upstream commit 58689498ca3384851145a754dbb1d8ed1cf9fb54 ] When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock. Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Jakub Kicinski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260428231559.1358502-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit acc76b97902757b63ba5136f787d107647236a19 Author: Petr Oros Date: Mon Apr 27 22:22:17 2026 -0700 ice: fix NULL pointer dereference in ice_reset_all_vfs() [ Upstream commit 54ef02487914c24170c7e1c061e45212dc55365e ] ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi(). When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0]. The single-VF reset path in ice_reset_vf() already handles this correctly by checking the return value of ice_vf_reconfig_vsi() and skipping ice_vf_post_vsi_rebuild() on failure. Apply the same pattern to ice_reset_all_vfs(): check the return value of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and ice_eswitch_attach_vf() on failure. The VF is left safely disabled (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver rebind). Note that this patch does not prevent the VF VSI rebuild from failing during NVM update — the underlying cause is firmware being in a transitional state while the EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer dereference that crashes the kernel when the rebuild does fail. crash> bt PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5" #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595 #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [exception RIP: ice_ena_vf_q_mappings+0x79] RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206 RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000 RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040 R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000 R13: 0000000000000010 R14: R15: ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4 #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663 #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9 The panic occurs attempting to dereference the NULL pointer in RDX at ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi). The faulting VSI is an allocated slab object but not fully initialized after a failed ice_vsi_rebuild(): crash> struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0, rx_rings = 0x0, tx_rings = 0x0, q_vectors = 0x0, txq_map = 0x0, rxq_map = 0x0, alloc_txq = 0x10, num_txq = 0x10, alloc_rxq = 0x10, num_rxq = 0x10, The nvmupdate64e process was performing NVM firmware update: crash> bt 0xff34c9edd1a30000 PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e" #0 [ff72159bcd617618] __schedule at ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice] #9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice] dmesg: ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it may result in a downgrade. continuing anyways ice 0000:13:00.1: ice_init_nvm failed -5 ice 0000:13:00.1: Rebuild failed, unload and reload driver Fixes: 12bb018c538c ("ice: Refactor VF reset") Signed-off-by: Petr Oros Tested-by: Rafal Romanowski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-5-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 654d275fcd453890249b827f5532cdd19415c038 Author: Jacob Keller Date: Wed Jan 18 17:16:47 2023 -0800 ice: Pull common tasks into ice_vf_post_vsi_rebuild [ Upstream commit aeead3d04fa050a94ed314cc5de97125a957dc9f ] The Single Root IOV implementation of .post_vsi_rebuild performs some tasks that will ultimately need to be shared with the Scalable IOV implementation such as rebuilding the host configuration. Refactor by introducing a new wrapper function, ice_vf_post_vsi_rebuild which performs the tasks that will be shared between SR-IOV and Scalable IOV. Move the ice_vf_rebuild_host_cfg and ice_vf_set_initialized calls into this wrapper. Then call the implementation specific post_vsi_rebuild handler afterwards. This ensures that we will properly re-initialize filters and expected settings for both SR-IOV and Scalable IOV. Signed-off-by: Jacob Keller Tested-by: Marek Szlosek Signed-off-by: Tony Nguyen Stable-dep-of: 54ef02487914 ("ice: fix NULL pointer dereference in ice_reset_all_vfs()") Signed-off-by: Sasha Levin commit 6b1b9c938282d5435c7d723c8d696d94c764ee46 Author: Petr Oros Date: Mon Apr 27 22:22:16 2026 -0700 iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler [ Upstream commit 34d33313b52eeac3a97ad2e3176d523ec70d9283 ] The V1 ADD_VLAN opcode had no success handler; filters sent via V1 stayed in ADDING state permanently. Add a fallthrough case so V1 filters also transition ADDING -> ACTIVE on PF confirmation. Critically, add an `if (v_retval) break` guard: the error switch in iavf_virtchnl_completion() does NOT return after handling errors, it falls through to the success switch. Without this guard, a PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE, creating a driver/HW mismatch where the driver believes the filter is installed but the PF never accepted it. For V2, this is harmless: iavf_vlan_add_reject() in the error block already kfree'd all ADDING filters, so the success handler finds nothing to transition. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-4-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c62eba999f7ec2d9eef94d10cb72b12425974749 Author: Petr Oros Date: Mon Apr 27 22:22:15 2026 -0700 iavf: wait for PF confirmation before removing VLAN filters [ Upstream commit bbcbe4ed70dea948849549af7edf44bd42bbd695 ] The VLAN filter DELETE path was asymmetric with the ADD path: ADD waits for PF confirmation (ADD -> ADDING -> ACTIVE), but DELETE immediately frees the filter struct after sending the DEL message without waiting for the PF response. This is problematic because: - If the PF rejects the DEL, the filter remains in HW but the driver has already freed the tracking structure, losing sync. - Race conditions between DEL pending and other operations (add, reset) cannot be properly resolved if the filter struct is already gone. Add IAVF_VLAN_REMOVING state to make the DELETE path symmetric: REMOVE -> REMOVING (send DEL) -> PF confirms -> kfree -> PF rejects -> ACTIVE In iavf_del_vlans(), transition filters from REMOVE to REMOVING instead of immediately freeing them. The new DEL completion handler in iavf_virtchnl_completion() frees filters on success or reverts them to ACTIVE on error. Update iavf_add_vlan() to handle the REMOVING state: if a DEL is pending and the user re-adds the same VLAN, queue it for ADD so it gets re-programmed after the PF processes the DEL. The !VLAN_FILTERING_ALLOWED early-exit path still frees filters directly since no PF message is sent in that case. Also update iavf_del_vlan() to skip filters already in REMOVING state: DEL has been sent to PF and the completion handler will free the filter when PF confirms. Without this guard, the sequence DEL(pending) -> user-del -> second DEL could cause the PF to return an error for the second DEL (filter already gone), causing the completion handler to incorrectly revert a deleted filter back to ACTIVE. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-3-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 275b3745284d68dbfa13f61aa3cbb984e540c29c Author: Petr Oros Date: Mon Apr 27 22:22:14 2026 -0700 iavf: stop removing VLAN filters from PF on interface down [ Upstream commit f2ce65b9b917474a1a6ce68d357e15fac2aca0f2 ] When a VF goes down, the driver currently sends DEL_VLAN to the PF for every VLAN filter (ACTIVE -> DISABLE -> send DEL -> INACTIVE), then re-adds them all on UP (INACTIVE -> ADD -> send ADD -> ADDING -> ACTIVE). This round-trip is unnecessary because: 1. The PF disables the VF's queues via VIRTCHNL_OP_DISABLE_QUEUES, which already prevents all RX/TX traffic regardless of VLAN filter state. 2. The VLAN filters remaining in PF HW while the VF is down is harmless - packets matching those filters have nowhere to go with queues disabled. 3. The DEL+ADD cycle during down/up creates race windows where the VLAN filter list is incomplete. With spoofcheck enabled, the PF enables TX VLAN filtering on the first non-zero VLAN add, blocking traffic for any VLANs not yet re-added. Remove the entire DISABLE/INACTIVE state machinery: - Remove IAVF_VLAN_DISABLE and IAVF_VLAN_INACTIVE enum values - Remove iavf_restore_filters() and its call from iavf_open() - Remove VLAN filter handling from iavf_clear_mac_vlan_filters(), rename it to iavf_clear_mac_filters() - Remove DEL_VLAN_FILTER scheduling from iavf_down() - Remove all DISABLE/INACTIVE handling from iavf_del_vlans() VLAN filters now stay ACTIVE across down/up cycles. Only explicit user removal (ndo_vlan_rx_kill_vid) or PF/VF reset triggers VLAN filter deletion/re-addition. Fixes: ed1f5b58ea01 ("i40evf: remove VLAN filters on close") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-2-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1c17cc44289fd2ba76475f56e5d28a4eae53ac82 Author: Petr Oros Date: Mon Apr 27 22:22:13 2026 -0700 iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING [ Upstream commit 70d62b669f1f9080a25278fc90b64309f4ae8959 ] Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better describe what the state represents: an ADD request has been sent to the PF and is waiting for a response. This is a pure rename with no behavioral change, preparing for a cleanup of the VLAN filter state machine. Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-1-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Stable-dep-of: f2ce65b9b917 ("iavf: stop removing VLAN filters from PF on interface down") Signed-off-by: Sasha Levin commit ba2272be04f0cb1e74e1e355ff32ef95df280731 Author: Eric Dumazet Date: Tue Apr 28 12:32:07 2026 +0000 bonding: 3ad: implement proper RCU rules for port->aggregator [ Upstream commit c4f050ce06c56cfb5993268af4a5cb66ed1cd04e ] syzbot found a data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler [1] which hints at lack of proper RCU implementation. Add __rcu qualifier to port->aggregator, and add proper RCU API. [1] BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0: ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569 process_one_work kernel/workqueue.c:3302 [inline] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385 worker_thread+0x58a/0x780 kernel/workqueue.c:3466 kthread+0x22a/0x280 kernel/kthread.c:436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1: __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853 rtnl_link_info_fill net/core/rtnetlink.c:906 [inline] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453 rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495 __dev_notify_flags+0x76/0x390 net/core/dev.c:9790 netif_change_flags+0xac/0xd0 net/core/dev.c:9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180 rtnl_group_changelink net/core/rtnetlink.c:3813 [inline] __rtnl_newlink net/core/rtnetlink.c:3981 [inline] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x0000000000000000 -> 0xffff88813cf5c400 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full) Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Fixes: 47e91f56008b ("bonding: use RCU protection for 3ad xmit path") Reported-by: syzbot+9bb2ff2a4ab9e17307e1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69f0a82f.050a0220.3aadc4.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Cc: Jay Vosburgh Cc: Andrew Lunn Link: https://patch.msgid.link/20260428123207.3809211-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a68d6829c9c177fa425b49dda9a8830a91d5f58 Author: Hangbin Liu Date: Tue Feb 24 02:02:14 2026 +0000 bonding: print churn state via netlink [ Upstream commit 4916f2e2f3fc9aef289fcd07949301e5c29094c2 ] Currently, the churn state is printed only in sysfs. Add netlink support so users could get the state via netlink. Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260224020215.6012-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit d1e649e9fcc6eeee1d00670ec79f5d2a13fe413c Author: Hangbin Liu Date: Tue Sep 2 06:44:59 2025 +0000 bonding: add support for per-port LACP actor priority [ Upstream commit 6b6dc81ee7e8ca87c71a533e1d69cf96a4f1e986 ] Introduce a new netlink attribute 'actor_port_prio' to allow setting the LACP actor port priority on a per-slave basis. This extends the existing bonding infrastructure to support more granular control over LACP negotiations. The priority value is embedded in LACPDU packets and will be used by subsequent patches to influence aggregator selection policies. Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20250902064501.360822-2-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit b96ce8cdf8bb1b94b16f4fa91030489b32d43c20 Author: Tonghao Zhang Date: Fri Jun 27 21:49:28 2025 +0800 net: bonding: add broadcast_neighbor option for 802.3ad [ Upstream commit ce7a381697cb3958ffe0b45e5028ac69444e9288 ] Stacking technology is a type of technology used to expand ports on Ethernet switches. It is widely used as a common access method in large-scale Internet data center architectures. Years of practice have proved that stacking technology has advantages and disadvantages in high-reliability network architecture scenarios. For instance, in stacking networking arch, conventional switch system upgrades require multiple stacked devices to restart at the same time. Therefore, it is inevitable that the business will be interrupted for a while. It is for this reason that "no-stacking" in data centers has become a trend. Additionally, when the stacking link connecting the switches fails or is abnormal, the stack will split. Although it is not common, it still happens in actual operation. The problem is that after the split, it is equivalent to two switches with the same configuration appearing in the network, causing network configuration conflicts and ultimately interrupting the services carried by the stacking system. To improve network stability, "non-stacking" solutions have been increasingly adopted, particularly by public cloud providers and tech companies like Alibaba, Tencent, and Didi. "non-stacking" is a method of mimicing switch stacking that convinces a LACP peer, bonding in this case, connected to a set of "non-stacked" switches that all of its ports are connected to a single switch (i.e., LACP aggregator), as if those switches were stacked. This enables the LACP peer's ports to aggregate together, and requires (a) special switch configuration, described in the linked article, and (b) modifications to the bonding 802.3ad (LACP) mode to send all ARP/ND packets across all ports of the active aggregator. Note that, with multiple aggregators, the current broadcast mode logic will send only packets to the selected aggregator(s). +-----------+ +-----------+ | switch1 | | switch2 | +-----------+ +-----------+ ^ ^ | | +-----------------+ | bond4 lacp | +-----------------+ | | | NIC1 | NIC2 +-----------------+ | server | +-----------------+ - https://www.ruijie.com/fr-fr/support/tech-gallery/de-stack-data-center-network-architecture/ Cc: Jay Vosburgh Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: Jonathan Corbet Cc: Andrew Lunn Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Nikolay Aleksandrov Signed-off-by: Tonghao Zhang Signed-off-by: Zengbing Tu Link: https://patch.msgid.link/84d0a044514157bb856a10b6d03a1028c4883561.1751031306.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit 0cf7714a6d62429b0230c0ca69fd5c2fd6b87db7 Author: Jones Syue 薛懷宗 Date: Mon Feb 26 02:24:52 2024 +0000 bonding: 802.3ad replace MAC_ADDRESS_EQUAL with __agg_has_partner [ Upstream commit 4440873f3655325f849366d75382aa05d09b5575 ] Replace macro MAC_ADDRESS_EQUAL() for null_mac_addr checking with inline function__agg_has_partner(). When MAC_ADDRESS_EQUAL() is verifiying aggregator's partner mac addr with null_mac_addr, means that seeing if aggregator has a valid partner or not. Using __agg_has_partner() makes it more clear to understand. In ad_port_selection_logic(), since aggregator->partner_system and port->partner_oper.system has been compared first as a prerequisite, it is safe to replace the upcoming MAC_ADDRESS_EQUAL() for null_mac_addr checking with __agg_has_partner(). Delete null_mac_addr, which is not required anymore in bond_3ad.c, since all references to it are gone. Signed-off-by: Jones Syue Reviewed-by: Hangbin Liu Reviewed-by: Jiri Pirko Acked-by: Jay Vosburgh Link: https://lore.kernel.org/r/SI2PR04MB5097BCA8FF2A2F03D9A5A3EEDC5A2@SI2PR04MB5097.apcprd04.prod.outlook.com Signed-off-by: Jakub Kicinski Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit fcc64df4b213a740d8d9b9a9e226e90e34e1be3c Author: Timur Kristóf Date: Tue Apr 28 13:40:44 2026 +0200 drm/amd/display: Read EDID from VBIOS embedded panel info [ Upstream commit 9ea16f64189bf7b6ba50fc7f0325b3c1f836d105 ] Some board manufacturers hardcode the EDID for the embedded panel in the VBIOS. This EDID should be used when the panel doesn't have a DDC. For reference, see the legacy non-DC display code: amdgpu_atombios_encoder_get_lcd_info() This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit eb105e63b474c11ef6a84a1c6b18100d851ff364) Signed-off-by: Sasha Levin commit 0a48fb8cee16b2dc46ffd957f85ad4a713a6bfad Author: Timur Kristóf Date: Tue Apr 28 13:40:41 2026 +0200 drm/amd/display: Allow DCE link encoder without AUX registers [ Upstream commit ac27e3f99035f132f23bc0409d0e57f11f054c70 ] Allow constructing the DCE link encoder without DDC, which means the AUX registers array will be NULL. This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 87f30b101af62590faf6020d106da07efdda199b) Signed-off-by: Sasha Levin commit 4e0ed44e51727d56244a822ab941efe507c47966 Author: Sebastian Andrzej Siewior Date: Tue Apr 28 12:34:25 2026 +0200 futex: Prevent lockup in requeue-PI during signal/ timeout wakeup [ Upstream commit bc7304f3ae20972d11db6e0b1b541c63feda5f05 ] During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup(). Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Reported-by: Moritz Klammler Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260428103425.dywXyPd3@linutronix.de Closes: https://lore.kernel.org/all/VE1PR06MB6894BE61C173D802365BE19DFF4CA@VE1PR06MB6894.eurprd06.prod.outlook.com Signed-off-by: Sasha Levin commit a2a33e87a2ffce3046c574d24eec4390c27c9365 Author: wangdicheng Date: Tue Apr 28 16:04:50 2026 +0800 ALSA: hda/conexant: Fix missing error check for jack detection [ Upstream commit b0e2333a231107adedd38c6fcfe1adc6162716fc ] In cx_probe(), the return value of snd_hda_jack_detect_enable_callback() is ignored. This function returns a pointer, and if it fails (e.g., due to memory allocation failure), it returns an error pointer which must be checked using IS_ERR(). If the registration fails, the driver continues to probe, but the jack detection callback will not be registered. This can lead to a kernel crash later when the driver attempts to handle jack events or accesses the uninitialized structure. Check the return value using IS_ERR() and propagate the error via PTR_ERR() to the probe caller. Fixes: 7aeb25908648 ("ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260428080450.108801-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aebaec2e9ff7a966df14b22c591aad6bb4d71a86 Author: wangdicheng Date: Mon Jun 16 15:43:31 2025 +0800 ALSA: hda/conexant: Renaming the codec with device ID 0x1f86 and 0x1f87 [ Upstream commit 7f4c540e0859e2025675d2c5c5c6ab88eaf817e2 ] Due to changes in the manufacturer's plan, all 0x14f11f86 will be named CX11880, and 0x14f11f87 will be named SN6140 Signed-off-by: wangdicheng Link: https://patch.msgid.link/20250616074331.581309-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Stable-dep-of: b0e2333a2311 ("ALSA: hda/conexant: Fix missing error check for jack detection") Signed-off-by: Sasha Levin commit 5c0ad481bd837f5c6f862fb926da137974c1dcef Author: Oldherl Oh Date: Mon Sep 30 16:41:32 2024 +0800 ALSA: hda/conexant: fix some typos [ Upstream commit 73253f2fd1d0a44708735c842e37163712e3f03b ] Fix some typos in patch_conexant.c Signed-off-by: Oldherl Oh Link: https://patch.msgid.link/20240930084132.3373750-1-me@oldherl.one Signed-off-by: Takashi Iwai Stable-dep-of: b0e2333a2311 ("ALSA: hda/conexant: Fix missing error check for jack detection") Signed-off-by: Sasha Levin commit 662ee3eb799c095c0ae869d1eecfeda6caff1285 Author: Breno Leitao Date: Mon Apr 27 07:30:37 2026 -0700 netconsole: propagate device name truncation in dev_name_store() [ Upstream commit 92ceb7bff62c2606f664c204750eca0b85d44112 ] dev_name_store() calls strscpy(nt->np.dev_name, buf, IFNAMSIZ) without checking the return value. If userspace writes an interface name longer than IFNAMSIZ - 1, strscpy() silently truncates and returns -E2BIG, but the function ignores it and reports a fully successful write back to userspace. If a real interface happens to match the truncated name, netconsole will bind to the wrong device on the next enable, sending kernel logs and panic output to an unintended network segment with no indication to userspace that anything was rewritten. Reject writes whose length cannot fit in nt->np.dev_name up front: if (count >= IFNAMSIZ) return -ENAMETOOLONG; This is not a big deal of a problem, but, it is still the correct approach. Fixes: 0bcc1816188e57 ("[NET] netconsole: Support dynamic reconfiguration using configfs") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-3-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd0f486bc3625834d944ba8c4fcbb66d5a8f917b Author: Matthew Wood Date: Sun Feb 4 15:27:34 2024 -0800 net: netconsole: move newline trimming to function [ Upstream commit ae001dc67907618423fd15bbab2014308c00ad0b ] Move newline trimming logic from `dev_name_store()` to a new function (trim_newline()) for shared use in netconsole.c Signed-off-by: Matthew Wood Signed-off-by: David S. Miller Stable-dep-of: 92ceb7bff62c ("netconsole: propagate device name truncation in dev_name_store()") Signed-off-by: Sasha Levin commit 9d21a6fd3b9df0913be93a89ad5b726af19e9d0b Author: Eric Dumazet Date: Mon Apr 27 08:36:06 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (V) [ Upstream commit a6c95b833dc17e84d16a8ac0f40fd0931616a52d ] cake_dump_stats() runs without qdisc spinlock being held. In this final patch, I add READ_ONCE()/WRITE_ONCE() annotations for cparams.target and cparams.interval. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 51eef9c072aa3405a6823a96ae666d38a3b48750 Author: Weiming Shi Date: Sun Apr 26 09:53:51 2026 -0700 bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() [ Upstream commit aa6c6d9ee064aabfede4402fd1283424e649ca19 ] bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426165350.1663137-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f12886ba14c307ea63aa3bb148f1f49c03d0abd Author: Beniamino Galvani Date: Fri Oct 20 13:55:25 2023 +0200 ipv6: rename and move ip6_dst_lookup_tunnel() [ Upstream commit fc47e86dbfb75a864c0c9dd8e78affb6506296bb ] At the moment ip6_dst_lookup_tunnel() is used only by bareudp. Ideally, other UDP tunnel implementations should use it, but to do so the function needs to accept new parameters that are specific for UDP tunnels, such as the ports. Prepare for these changes by renaming the function to udp_tunnel6_dst_lookup() and move it to file net/ipv6/ip6_udp_tunnel.c. This is similar to what already done for IPv4 in commit bf3fcbf7e7a0 ("ipv4: rename and move ip_route_output_tunnel()"). Suggested-by: Guillaume Nault Signed-off-by: Beniamino Galvani Reviewed-by: David Ahern Signed-off-by: David S. Miller Stable-dep-of: aa6c6d9ee064 ("bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()") Signed-off-by: Sasha Levin commit 7c0aa9d34e636b4d9206f64f1ab12b08a6de7375 Author: Beniamino Galvani Date: Mon Oct 16 09:15:22 2023 +0200 ipv4: add new arguments to udp_tunnel_dst_lookup() [ Upstream commit 72fc68c6356b663a8763f02d9b0ec773d59a4949 ] We want to make the function more generic so that it can be used by other UDP tunnel implementations such as geneve and vxlan. To do that, add the following arguments: - source and destination UDP port; - ifindex of the output interface, needed by vxlan; - the tos, because in some cases it is not taken from struct ip_tunnel_info (for example, when it's inherited from the inner packet); - the dst cache, because not all tunnel types (e.g. vxlan) want to use the one from struct ip_tunnel_info. With these parameters, the function no longer needs the full struct ip_tunnel_info as argument and we can pass only the relevant part of it (struct ip_tunnel_key). Suggested-by: Guillaume Nault Signed-off-by: Beniamino Galvani Reviewed-by: David Ahern Signed-off-by: David S. Miller Stable-dep-of: aa6c6d9ee064 ("bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()") Signed-off-by: Sasha Levin commit e7dc07429b89e53cf9031075d59ae926588b88e3 Author: Beniamino Galvani Date: Mon Oct 16 09:15:21 2023 +0200 ipv4: remove "proto" argument from udp_tunnel_dst_lookup() [ Upstream commit 78f3655adcb52412275f282267ee771421731632 ] The function is now UDP-specific, the protocol is always IPPROTO_UDP. Suggested-by: Guillaume Nault Signed-off-by: Beniamino Galvani Reviewed-by: David Ahern Signed-off-by: David S. Miller Stable-dep-of: aa6c6d9ee064 ("bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()") Signed-off-by: Sasha Levin commit 670887effc423aaa3b41dd1785a0fc03975f2282 Author: Beniamino Galvani Date: Mon Oct 16 09:15:20 2023 +0200 ipv4: rename and move ip_route_output_tunnel() [ Upstream commit bf3fcbf7e7a08015d3b169bad6281b29d45c272d ] At the moment ip_route_output_tunnel() is used only by bareudp. Ideally, other UDP tunnel implementations should use it, but to do so the function needs to accept new parameters that are specific for UDP tunnels, such as the ports. Prepare for these changes by renaming the function to udp_tunnel_dst_lookup() and move it to file net/ipv4/udp_tunnel_core.c. Suggested-by: Guillaume Nault Signed-off-by: Beniamino Galvani Reviewed-by: David Ahern Signed-off-by: David S. Miller Stable-dep-of: aa6c6d9ee064 ("bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()") Signed-off-by: Sasha Levin commit 5868ef0056788262123e3a23d1bcd2af5abb1e6c Author: Xin Long Date: Sun Apr 26 10:46:41 2026 -0400 sctp: discard stale INIT after handshake completion [ Upstream commit 8a92cb475ca90d84db769e4d4383e631ace0d6e5 ] After an association reaches ESTABLISHED, the peer’s init_tag is already known from the handshake. Any subsequent INIT with the same init_tag is not a valid restart, but a delayed or duplicate INIT. Drop such INIT chunks in sctp_sf_do_unexpected_init() instead of processing them as new association attempts. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/5788c76c1ee122a3ed00189e88dcf9df1fba226c.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d538dad34859a6c900a0a6285819925d6d5270e Author: Xin Long Date: Sun Apr 26 10:46:40 2026 -0400 netfilter: skip recording stale or retransmitted INIT [ Upstream commit 576a5d2bad4814c881a829576b1261b9b8159d2b ] An INIT whose init_tag matches the peer's vtag does not provide new state information. It indicates either: - a stale INIT (after INIT-ACK has already been seen on the same side), or - a retransmitted INIT (after INIT has already been recorded on the same side). In both cases, the INIT must not update ct->proto.sctp.init[] state, since it does not advance the handshake tracking and may otherwise corrupt INIT/INIT-ACK validation logic. Allow INIT processing only when the conntrack entry is newly created (SCTP_CONNTRACK_NONE), or when the init_tag differs from the stored peer vtag. Note it skips the check for the ct with old_state SCTP_CONNTRACK_NONE in nf_conntrack_sctp_packet(), as it is just created in sctp_new() where it set ct->proto.sctp.vtag[IP_CT_DIR_REPLY] = ih->init_tag. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Signed-off-by: Xin Long Reviewed-by: Marcelo Ricardo Leitner Acked-by: Florian Westphal Link: https://patch.msgid.link/ee56c3e416452b2a40589a2a85245ac2ad5e9f4b.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f9dd6f665ece0ba211e6267f6e2cf483b2ac796 Author: Christian A. Ehrhardt Date: Tue Apr 28 21:22:49 2026 +0200 ASoC: codecs: ab8500: Fix casting of private data [ Upstream commit a201aef1a88b675e9eb8487e27d14e2eef3cef80 ] ab8500_filter_controls[i].private_value is initialized using .private_value = (unsigned long)&(struct filter_control) {.count = xcount, .min = xmin, .max = xmax} thus it's a pointer to a struct filter_control casted to unsigned long. So to get back that pointer .private_data must be cast back, not its address. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Signed-off-by: Christian A. Ehrhardt Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260428192255.2294705-2-u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a57881c862021816fc675d38a115da084aff15c5 Author: Heiko Schocher Date: Sat Apr 25 05:13:39 2026 +0200 net: phy: dp83869: fix setting CLK_O_SEL field. [ Upstream commit 46f74a3f7d57d9cc0110b09cbc8163fa0a01afa2 ] Table 7-121 in datasheet says we have to set register 0xc6 to value 0x10 before CLK_O_SEL can be modified. No more infos about this field found in datasheet. With this fix, setting of CLK_O_SEL field in IO_MUX_CFG register worked through dts property "ti,clk-output-sel" on a DP83869HMRGZR. Signed-off-by: Heiko Schocher Reviewed-by: Simon Horman Fixes: 01db923e8377 ("net: phy: dp83869: Add TI dp83869 phy") Link: https://patch.msgid.link/20260425031339.3318-1-hs@nabladev.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8798bbe416bdcb458e4ed31d7099f12a5e151977 Author: William A. Kennington III Date: Thu Apr 23 00:46:52 2026 -0700 net: mctp i2c: check length before marking flow active [ Upstream commit 4ca07b9239bd0478ae586632a2ed72be37ed8407 ] Currently, mctp_i2c_get_tx_flow_state() is called before the packet length sanity check. This function marks a new flow as active in the MCTP core. If the sanity check fails, mctp_i2c_xmit() returns early without calling mctp_i2c_lock_nest(). This results in a mismatched locking state: the flow is active, but the I2C bus lock was never acquired for it. When the flow is later released, mctp_i2c_release_flow() will see the active state and queue an unlock marker. The TX thread will then decrement midev->i2c_lock_count from 0, causing it to underflow to -1. This underflow permanently breaks the driver's locking logic, allowing future transmissions to occur without holding the I2C bus lock, leading to bus collisions and potential hardware hangs. Move the mctp_i2c_get_tx_flow_state() call to after the length sanity check to ensure we only transition the flow state if we are actually going to proceed with the transmission and locking. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: William A. Kennington III Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260423074741.201460-1-william@wkennington.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c67a955c93db74a982a5f4db8dc1867ccfaf8a53 Author: Takashi Iwai Date: Mon Apr 27 17:15:04 2026 +0200 ALSA: usb-audio: Fix potential leak of pd at parsing UAC3 streams [ Upstream commit c39f0bc03f84ba64c9144c95714df1dc36150f6d ] At parsing UAC3 streams, we allocate a PD object at each time, and either assign or free it. But there is a case where the PD object may be leaked; namely, in __snd_usb_parse_audio_interface() loop, when an audioformat shares the same endpoint with others, it's put to a link and returns from snd_usb_add_audio_stream(), but the PD is forgotten afterwards. Overall, the treatment of PD object in the parser code is a bit flaky, and we should be more careful about the object ownership. This patch tries to fix the above case and improve the code a bit. The pd object is now managed with the auto-cleanup in the loop, and the ownership is updated when the pd object gets assigned to the stream, which guarantees the release of the leftover object. Fixes: 7edf3b5e6a45 ("ALSA: usb-audio: AudioStreaming Power Domain parsing") Link: https://patch.msgid.link/20260427151508.12544-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8a89054a1ec0767aec25ed2bbac933da6ba3cf5a Author: Florian Westphal Date: Fri Apr 24 16:58:38 2026 +0200 neigh: let neigh_xmit take skb ownership [ Upstream commit 4438113be604ee67a7bf4f81da6e1cca41332ce4 ] neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb. Fixes: 4fd3d7d9e868 ("neigh: Add helper function neigh_xmit") Signed-off-by: Florian Westphal Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260424145843.74055-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a078eeaffe8aa5d174db9ac93541ffee7439ecf7 Author: Eric Dumazet Date: Thu Apr 18 09:51:04 2024 +0000 neighbour: add RCU protection to neigh_tables[] [ Upstream commit f8f2eb9de69a1119117d198547c13d7a1123a5a9 ] In order to remove RTNL protection from neightbl_dump_info() and neigh_dump_info() later, we need to add RCU protection to neigh_tables[]. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 4438113be604 ("neigh: let neigh_xmit take skb ownership") Signed-off-by: Sasha Levin commit 4f1c88644a68de91a05f3bd6ff1f001e9035794e Author: Paul Geurts Date: Wed Apr 22 12:09:30 2026 +0200 NFC: trf7970a: Ignore antenna noise when checking for RF field [ Upstream commit a9bc28aa4e64320668131349436a650bf42591a5 ] The main channel Received Signal Strength Indicator (RSSI) measurement is used to determine whether an RF field is present or not. RSSI != 0 is interpreted as an RF Field is present. This does not take RF noise and measurement inaccuracy into account, and results in false positives in the field. Define a noise level and make sure the RF field is only interpreted as present when the RSSI is above the noise level. Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field") Signed-off-by: Paul Geurts Reviewed-by: Krzysztof Kozlowski Reviewed-by: Mark Greer Link: https://patch.msgid.link/20260422100930.581237-1-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3546def4041dcada40a5eaecd0e6a21b64c3acee Author: Morduan Zang Date: Fri Apr 24 09:55:17 2026 +0800 net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit [ Upstream commit adbe2cdf75461891e50dbe11896ac78e9af1f874 ] When rtl8150_start_xmit() fails to submit the tx URB, the URB is never handed to the USB core and write_bulk_callback() will not run. The driver returns NETDEV_TX_OK, which tells the networking stack that the skb has been consumed, but nothing actually frees the skb on this error path: dev->tx_skb = skb; ... if ((res = usb_submit_urb(dev->tx_urb, GFP_ATOMIC))) { ... /* no kfree_skb here */ } return NETDEV_TX_OK; This leaks the skb on every submit failure and also leaves dev->tx_skb pointing at memory that the driver itself may later free, which is fragile. Free the skb with dev_kfree_skb_any() in the error path and clear dev->tx_skb so no stale pointer is left behind. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Andrew Lunn Signed-off-by: Morduan Zang Link: https://patch.msgid.link/E7D3E1C013C5A859+20260424015517.9574-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 423b5b86e14e190f6e3161eb5f2ea5f908295ba7 Author: Zhan Jun Date: Thu Apr 23 08:49:12 2026 +0800 net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() [ Upstream commit 23f0e34c64acba15cad4d23e50f41f533da195fa ] syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/ Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71 Reviewed-by: Andrew Lunn Signed-off-by: Zhan Jun Link: https://patch.msgid.link/809895186B866C10+20260423004913.136655-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 468defa0b70902a22f4478c1207624bc1b31c124 Author: Ido Schimmel Date: Thu Apr 23 09:36:07 2026 +0300 vrf: Fix a potential NPD when removing a port from a VRF [ Upstream commit 2674d603a9e6970463b2b9ebcf8e31e90beae169 ] RCU readers that identified a net device as a VRF port using netif_is_l3_slave() assume that a subsequent call to netdev_master_upper_dev_get_rcu() will return a VRF device. They then continue to dereference its l3mdev operations. This assumption is not always correct and can result in a NPD [1]. There is no RCU synchronization when removing a port from a VRF, so it is possible for an RCU reader to see a new master device (e.g., a bridge) that does not have l3mdev operations. Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE flag. Skip this synchronization when a net device is removed from a VRF as part of its deletion and when the VRF device itself is deleted. In the latter case an RCU grace period will pass by the time RTNL is released. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181) [...] Call Trace: l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189) __inet_bind (net/ipv4/af_inet.c:499 (discriminator 3)) inet_bind_sk (net/ipv4/af_inet.c:469) __sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1)) __x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking") Reported-by: Haoze Xie Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Yuan Tan Closes: https://lore.kernel.org/netdev/20260419145332.3988923-1-n05ec@lzu.edu.cn/ Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260423063607.1208202-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97d0a6f12875216c8da909854289450c723fca4b Author: Eric Dumazet Date: Thu Apr 23 06:35:27 2026 +0000 net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats() [ Upstream commit 59b145771c7982cfe9020d4e9e22da92d6b5ae31 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill tc_fq_pie_xstats with live data. Alternative would be to add READ_ONCE() and WRITE_ONCE() annotations, but the spinlock is needed anyway to scan q->new_flows and q->old_flows. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423063527.2568262-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de870c92c9bd7abeb6a92b52ab45aeb677199009 Author: Eric Dumazet Date: Thu Apr 23 06:28:39 2026 +0000 net/sched: sch_choke: annotate data-races in choke_dump_stats() [ Upstream commit d3aeb889dcbd78e95f500d383799a23d949796e0 ] choke_dump_stats() only runs with RTNL held. It reads fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423062839.2524324-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2573fc3bfcdcd5818a04986c3d6bb745c9f8842e Author: Stephen Hemminger Date: Fri Apr 17 20:19:43 2026 -0700 net/sched: netem: fix slot delay calculation overflow [ Upstream commit 51e94e1e2fef351c74d69eb53666df808d26af95 ] get_slot_next() computes a random delay between min_delay and max_delay using: get_random_u32() * (max_delay - min_delay) >> 32 This overflows signed 64-bit arithmetic when the delay range exceeds approximately 2.1 seconds (2^31 nanoseconds), producing a negative result that effectively disables slot-based pacing. This is a realistic configuration for WAN emulation (e.g., slot 1s 5s). Use mul_u64_u32_shr() which handles the widening multiply without overflow. Fixes: 0a9fe5c375b5 ("netem: slotting with non-uniform distribution") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-6-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8334f870793741c0a4d778b4b15504cbd80e98ae Author: Stephen Hemminger Date: Fri Apr 17 20:19:42 2026 -0700 net/sched: netem: validate slot configuration [ Upstream commit 01801c359a74737b9b1aa28568b60374d857241a ] Reject slot configurations that have no defensible meaning: - negative min_delay or max_delay - min_delay greater than max_delay - negative dist_delay or dist_jitter - negative max_packets or max_bytes Negative or out-of-order delays underflow in get_slot_next(), producing garbage intervals. Negative limits trip the per-slot accounting (packets_left/bytes_left <= 0) on the first packet of every slot, defeating the rate-limiting half of the slot feature. Note that dist_jitter has been silently coerced to its absolute value by get_slot() since the feature was introduced; rejecting negatives here converts that silent coercion into -EINVAL. The abs() can be removed in a follow-up. Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-5-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74fcd8e127200a50ee22ba2b45c164722bdb9177 Author: Stephen Hemminger Date: Fri Apr 17 20:19:40 2026 -0700 net/sched: netem: fix queue limit check to include reordered packets [ Upstream commit 4185701fcce6b426b6c3630b25330dddd9c47b0d ] The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check. Fixes: f8d4bc455047 ("net/sched: netem: account for backlog updates from child qdisc") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-3-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fca48518ca82b4877416842765e82b1d612504b1 Author: Stephen Hemminger Date: Fri Apr 17 20:19:39 2026 -0700 net/sched: netem: fix probability gaps in 4-state loss model [ Upstream commit 732b463449fd0ef90acd13cda68eab1c91adb00c ] The 4-state Markov chain in loss_4state() has gaps at the boundaries between transition probability ranges. The comparisons use: if (rnd < a4) else if (a4 < rnd && rnd < a1 + a4) When rnd equals a boundary value exactly, neither branch matches and no state transition occurs. The redundant lower-bound check (a4 < rnd) is already implied by being in the else branch. Remove the unnecessary lower-bound comparisons so the ranges are contiguous and every random value produces a transition, matching the GI (General and Intuitive) loss model specification. This bug goes back to original implementation of this model. Fixes: 661b79725fea ("netem: revised correlated loss generator") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-2-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b7b6ae0e93b8d512e208b1378d74af052e4f4e7 Author: Nikola Z. Ivanov Date: Sun Apr 26 23:14:34 2026 +0300 netdevsim: zero initialize struct iphdr in dummy sk_buff [ Upstream commit 35eaa6d8d6c2ee65e96f507add856e0eacf24591 ] Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header. Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support") Signed-off-by: Nikola Z. Ivanov Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426201434.742030-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1dd70a613a849436b15b8965aa8c96c0a4520f31 Author: Daan De Meyer Date: Mon Apr 27 22:01:39 2026 +0100 cdrom, scsi: sr: propagate read-only status to block layer via set_disk_ro() [ Upstream commit 0898a817621a2f0cddca8122d9b974003fe5036d ] The cdrom core never calls set_disk_ro() for a registered device, so BLKROGET on a CD-ROM device always returns 0 (writable), even when the drive has no write capabilities and writes will inevitably fail. This causes problems for userspace that relies on BLKROGET to determine whether a block device is read-only. For example, systemd's loop device setup uses BLKROGET to decide whether to create a loop device with LO_FLAGS_READ_ONLY. Without the read-only flag, writes pass through the loop device to the CD-ROM and fail with I/O errors. systemd-fsck similarly checks BLKROGET to decide whether to run fsck in no-repair mode (-n). The write-capability bits in cdi->mask come from two different sources: CDC_DVD_RAM and CDC_CD_RW are populated by the driver from the MODE SENSE capabilities page (page 0x2A) before register_cdrom() is called, while CDC_MRW_W and CDC_RAM require the MMC GET CONFIGURATION command and were only probed by cdrom_open_write() at device open time. This meant that any attempt to compute the writable state from the full mask at probe time was incorrect, because the GET CONFIGURATION bits were still unset (and cdi->mask is initialized such that capabilities are assumed present). Fix this by factoring the GET CONFIGURATION probing out of cdrom_open_write() into a new exported helper, cdrom_probe_write_features(), and having sr call it from sr_probe() right after get_capabilities() has populated the MODE SENSE bits. register_cdrom() then calls set_disk_ro() based on the full write-capability mask (CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW) so the block layer reflects the drive's actual write support. The feature queries used (CDF_MRW and CDF_RWRT via GET CONFIGURATION with RT=00) report drive-level capabilities that are persistent across media, so a single probe before register_cdrom() is sufficient and the redundant probe at open time is dropped. With set_disk_ro() now accurate, the long-vestigial cd->writeable flag in sr can go: get_capabilities() used to set cd->writeable based on the same four mask bits, but because CDC_MRW_W and CDC_RAM default to "capability present" in cdi->mask and aren't touched by MODE SENSE, the condition that gated cd->writeable was always true, making it unconditionally 1. Replace the corresponding gate in sr_init_command() with get_disk_ro(cd->disk), which turns a previously no-op check into a real one and also catches kernel-internal bio writers that bypass blkdev_write_iter()'s bdev_read_only() check. The sd driver (SCSI disks) does not have this problem because it checks the MODE SENSE Write Protect bit and calls set_disk_ro() accordingly. The sr driver cannot use the same approach because the MMC specification does not define the WP bit in the MODE SENSE device-specific parameter byte for CD-ROM devices. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daan De Meyer Reviewed-by: Phillip Potter Reviewed-by: Martin K. Petersen Signed-off-by: Phillip Potter Link: https://patch.msgid.link/20260427210139.1400-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 333c0fc639460a35fd27dab32dd0559b22899497 Author: John Madieu Date: Sat Apr 25 09:29:34 2026 +0000 spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ [ Upstream commit b4683a239a409d65f88052f5630c748a8ba070cd ] rockchip_spi_isr() decides whether the current interrupt was the cs-inactive event by reading IMR: if (rs->cs_inactive && readl_relaxed(rs->regs + ROCKCHIP_SPI_IMR) & INT_CS_INACTIVE) ctlr->target_abort(ctlr); IMR is the interrupt mask register: it tells which sources are enabled, not which one fired. In the PIO path, rockchip_spi_prepare_irq() enables both INT_RF_FULL and INT_CS_INACTIVE in IMR when rs->cs_inactive is true: if (rs->cs_inactive) writel_relaxed(INT_RF_FULL | INT_CS_INACTIVE, rs->regs + ROCKCHIP_SPI_IMR); so the IMR check is always true once cs_inactive is enabled, and every PIO interrupt - including normal RF_FULL completions - is dispatched to ctlr->target_abort(), aborting the transfer. The bug is reachable on ROCKCHIP_SPI_VER2_TYPE2 in target mode with a DMA-capable controller when the transfer is short enough to fall back to PIO (rockchip_spi_can_dma() returns false below fifo_len). Read ISR (which is RISR masked by IMR) so the check actually reflects which interrupt fired, and parenthesise the expression for clarity while at it. Fixes: 869f2c94db92 ("spi: rockchip: Stop spi slave dma receiver when cs inactive") Signed-off-by: John Madieu Link: https://patch.msgid.link/20260425092936.2590132-2-john.madieu@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 82b56b3bde8b3e449ce0f0330d2f9b0f5d3c4f00 Author: Yang Yingliang Date: Fri Aug 18 17:31:44 2023 +0800 spi: rockchip: switch to use modern name [ Upstream commit 1a3ccff3bc39acc04e69e3a65833d474471598ec ] Change legacy name master/slave to modern name host/target or controller. No functional changed. Signed-off-by: Yang Yingliang Acked-by: Heiko Stuebner Link: https://lore.kernel.org/r/20230818093154.1183529-14-yangyingliang@huawei.com Signed-off-by: Mark Brown Stable-dep-of: b4683a239a40 ("spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ") Signed-off-by: Sasha Levin commit fda8c809f31d43b490b656e760438f13d959fbd7 Author: Lizhe Date: Sun Feb 26 14:33:34 2023 +0800 drivers/spi-rockchip.c : Remove redundant variable slave [ Upstream commit 8c220e6c6da9c2f70a78ba8b3121893b3634a54c ] variable slave in spi_alloc_master() or spi_alloc_slave() has been assigned. it is not necessary to be assigned again Signed-off-by: Lizhe Link: https://lore.kernel.org/r/20230226063334.7489-1-sensor1010@163.com Signed-off-by: Mark Brown Stable-dep-of: b4683a239a40 ("spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ") Signed-off-by: Sasha Levin commit b3264c977e79d8a25778d4fd11520f00fea1329c Author: Florian Westphal Date: Thu Apr 23 02:19:11 2026 +0200 netfilter: nf_conntrack_sip: don't use simple_strtoul [ Upstream commit 8cf6809cddcbe301aedfc6b51bcd4944d45795f6 ] Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(), and ct_sip_parse_request() with a new sip_parse_port() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings. The previous code dereferenced pointers without bounds checks after sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed. Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes: - Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters. - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10. - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range. - epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it. Based on an earlier patch from Jenny Guanni Qu . Fixes: 05e3ced297fe ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Reported-by: Jenny Guanni Qu . Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f98b7f85e04b40e28b08c461ded0cc79f14f5509 Author: Jiexun Wang Date: Fri Apr 17 20:25:06 2026 +0800 netfilter: xt_policy: fix strict mode inbound policy matching [ Upstream commit 4b2b4d7d4e203c92db8966b163edfacb1f0e1e29 ] match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout. Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently. Fixes: c4b885139203 ("[NETFILTER]: x_tables: replace IPv4/IPv6 policy match by address family independant version") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0e05ca458f6876d39a54e3f30e318e4ad89197e9 Author: Timur Kristóf Date: Sat Apr 18 23:49:33 2026 +0200 drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2) [ Upstream commit fe2b84f9228e2a0903221a4d0d8c350b018e9c0c ] This commit fixes amdgpu to work on the Radeon HD 7870 XT which has never worked with the Linux open source drivers before. Some boards have "harvested" chips, meaning that some parts of the chip are disabled and fused, and it's sold for cheaper and under a different marketing name. On a harvested chip, any of the following can be disabled: - CUs (Compute Units) - RBs (Render Backend, aka. ROP) - Memory channels (ie. the chip has a lower bandwidth) - TCCs (ie. less L2 cache) Handle chips with harvested TCCs by patching the registers that configure how TCCs are mapped. If some TCCs are disabled, we need to make sure that the disabled TCCs are not used, and the remaining TCCs are used optimally. TCP_CHAN_STEER_LO/HI control which TCC is used by TCP channels. TCP_ADDR_CONFIG.NUM_TCC_BANKS controls how many channels are used. Note that the TCC configuration is highly relevant to performance. Suboptimal configuration (eg. CHAN_STEER=0) can significantly reduce gaming performance. For optimal performance: - Rely on the CHAN_STEER from the golden registers table, only skip disabled TCCs but keep the mapping order. - Limit NUM_TCC_BANKS to number of active TCCs to avoid thrashing, which performs better than using the same TCC twice. v2: - Also consider CGTS_USER_TCC_DISABLE for disabled TCCs. Link: https://bugs.freedesktop.org/show_bug.cgi?id=60879 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2664 Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 00218d15528fab9f6b31241fe5904eea4fcaa30d) Signed-off-by: Sasha Levin commit 1ecf6c3b5f339ccc1ddf727c47c99ffec2932ca1 Author: Timur Kristóf Date: Sat Apr 18 23:49:31 2026 +0200 drm/amdgpu/uvd3.1: Don't validate the firmware when already validated [ Upstream commit 13e4cf116dbf7a1fb8123a59bea2c098f30d3736 ] UVD 3.1 firmware validation seems to always fail after attempting it when it had already been validated. (This works similarly with the VCE 1.0 as well.) Don't attempt repeating the validation when it's already done. This caused issues in situations when the system isn't able to suspend the GPU properly and so the GPU isn't actually powered down. Then amdgpu would fail when calling the IP block resume function. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2887 Fixes: bb7978111dd3 ("drm/amdgpu: fix SI UVD firmware validate resume fail") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 889a2cfd889c4a4dd9d0c89ce9a8e60b78be71dd) Signed-off-by: Sasha Levin commit c950f86d6e592328d5e4bcfd3f421de3961bac4a Author: Alexandre Demers Date: Thu Feb 27 00:05:04 2025 -0500 drm/amdgpu: fix spelling typos [ Upstream commit ce43abd7ec9464cf954f90e1c69e11768b02fa0a ] Found some typos while exploring amdgpu code. Signed-off-by: Alexandre Demers Signed-off-by: Alex Deucher Stable-dep-of: 13e4cf116dbf ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Sasha Levin commit 388c3704a9063baa4fe4ed4d88b979a83f3c9709 Author: Keith Busch Date: Tue Apr 21 09:14:02 2026 -0700 nvme-pci: fix missed admin queue sq doorbell write [ Upstream commit 1cc4cdae2a3b7730d462d69e30f213fd2efe7807 ] We can batch admin commands submitted through io_uring_cmd passthrough, which means bd->last may be false and skips the doorbell write to aggregate multiple commands per write. If a subsequent command can't be dispatched for whatever reason, we have to provide the blk-mq ops' commit_rqs callback in order to ensure we properly update the doorbell. Fixes: 58e5bdeb9c2b ("nvme: enable uring-passthrough for admin commands") Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 84e8536c981338d0d8cc6e712cf71a936a93e13f Author: Pablo Neira Ayuso Date: Mon Apr 20 23:15:32 2026 +0200 netfilter: arp_tables: fix IEEE1394 ARP payload parsing [ Upstream commit 1e8e3f449b1e73b73a843257635b9c50f0cc0f0a ] Weiming Shi says: "arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()." Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi . Fixes: 6752c8db8e0c ("firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.") Reported-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3df42a854686fa06484e37ac1a3931c8e3e3453c Author: Maurizio Lombardi Date: Mon Mar 16 15:39:35 2026 +0100 nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers [ Upstream commit ea8e356acb165cb1fd75537a52e1f66e5e76c538 ] Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke Reviewed-by: Yunje Shin Reviewed-by: Chaitanya Kulkarni Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit e7aa3364e76ee8430664f8a7f64efb1651e1a017 Author: Breno Leitao Date: Mon Apr 20 06:25:09 2026 -0700 tracing: branch: Fix inverted check on stat tracer registration [ Upstream commit 3b75dd76e64a04771861bb5647951c264919e563 ] init_annotated_branch_stats() and all_annotated_branch_stats() check the return value of register_stat_tracer() with "if (!ret)", but register_stat_tracer() returns 0 on success and a negative errno on failure. The inverted check causes the warning to be printed on every successful registration, e.g.: Warning: could not register annotated branches stats while leaving real failures silent. The initcall also returned a hard-coded 1 instead of the actual error. Invert the check and propagate ret so that the warning fires on real errors and the initcall reports the correct status. Cc: Mathieu Desnoyers Cc: Ingo Molnar Cc: Frederic Weisbecker Link: https://patch.msgid.link/20260420-tracing-v1-1-d8f4cd0d6af1@debian.org Fixes: 002bb86d8d42 ("tracing/ftrace: separate events tracing and stats tracing engine") Signed-off-by: Breno Leitao Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 36b47bb4046f90ac2a1d073a656a5d26237f66a2 Author: Mark Harmstone Date: Thu Apr 16 18:15:23 2026 +0100 btrfs: fix double-decrement of bytes_may_use in submit_one_async_extent() [ Upstream commit 82323b1a7088b7a5c3e528a5d634bff447fa286f ] submit_one_async_extent() calls btrfs_reserve_extent(), which decrements bytes_may_use. If the call btrfs_create_io_em() fails, we jump to out_free_reserve, which calls extent_clear_unlock_delalloc(). Because we're specifying EXTENT_DO_ACCOUNTING, i.e. EXTENT_CLEAR_META_RESV | EXTENT_CLEAR_DATA_RESV, this decreases bytes_may_use again. This can lead to problems later on, as an initial write can fail only for the writeback to silently ENOSPC. Fix this by replacing EXTENT_DO_ACCOUNTING with EXTENT_CLEAR_META_RESV. This parallels a4fe134fc1d8eb ("btrfs: fix a double release on reserved extents in cow_one_range()"), which is the same fix in cow_one_range(). Fixes: 151a41bc46df ("Btrfs: fix what bits we clear when erroring out from delalloc") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4c508a58d0a8e35ca754322ce90501bd7e9c0a80 Author: Wolfram Sang Date: Fri Apr 17 09:42:36 2026 +0200 mailbox: mailbox-test: make data_ready a per-instance variable [ Upstream commit 6e937f4e769e60947909e3525965f0137b9039e8 ] While not the default case, multiple tests can be run simultaneously. Then, data_ready being a global variable will be overwritten and the per-instance lock will not help. Turn the global variable into a per-instance one to avoid this problem. Fixes: e339c80af95e ("mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 65077e6f0a3a05929a78674999452a8aec483082 Author: Wolfram Sang Date: Fri Apr 17 09:42:35 2026 +0200 mailbox: mailbox-test: initialize struct earlier [ Upstream commit bbcf9af68bfedb3d9cc3c7eae62f5c844d8b78b9 ] The waitqueue must be initialized before the debugfs files are created because from that time, requests from userspace can already be made. Similarily, drvdata and spinlock needs to be initialized before we request the channel, otherwise dangling irqs might run into problems like a NULL pointer exception. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit c494a11da45ad7ec9b0ff216c3e3ace351193bb6 Author: Wolfram Sang Date: Fri Apr 17 09:42:34 2026 +0200 mailbox: mailbox-test: don't free the reused channel [ Upstream commit 88ebadbf0deefdaccdab868b44ff70a0a257f473 ] The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit d44872a569b8fbacde457ff2587a775e5004bb79 Author: Wolfram Sang Date: Mon Apr 13 12:42:38 2026 +0200 mailbox: add sanity check for channel array [ Upstream commit c1aad75595fb67edc7fda8af249d3b886efa1be9 ] Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here. Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox") Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 7257f930013d0be4f3629bc4a6df71acb848fb6e Author: cuitao Date: Tue Apr 14 09:53:27 2026 +0800 cgroup/rdma: fix integer overflow in rdmacg_try_charge() [ Upstream commit c802f460dd485c1332b5a35e7adcfb2bc22536a2 ] The expression `rpool->resources[index].usage + 1` is computed in int arithmetic before being assigned to s64 variable `new`. When usage equals INT_MAX (the default "max" value), the addition overflows to INT_MIN. This negative value then passes the `new > max` check incorrectly, allowing a charge that should be rejected and corrupting usage to negative. Fix by casting usage to s64 before the addition so the arithmetic is done in 64-bit. Fixes: 39d3e7584a68 ("rdmacg: Added rdma cgroup controller") Signed-off-by: cuitao Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 187069ccc3474516af32350e20d7e449160fa6de Author: Wolfram Sang Date: Fri Apr 10 14:53:00 2026 +0200 mailbox: mailbox-test: free channels on probe error [ Upstream commit c02053a9055d5fdfd32432287cca8958db1d5bc5 ] On probe error, free the previously obtained channels. This not only prevents a leak, but also UAF scenarios because the client structure will be removed nonetheless because it was allocated with devm. Link: https://sashiko.dev/#/patchset/20260327151217.5327-2-wsa%2Brenesas%40sang-engineering.com Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 05fdee2f6fb2cb4b3c7463d002fecdbe97e692f4 Author: Yuho Choi Date: Sun Apr 19 21:01:18 2026 -0400 fbdev: offb: fix PCI device reference leak on probe failure [ Upstream commit 869b93ba04088713596e68453c1146f52f713290 ] offb_init_nodriver() gets a referenced PCI device with pci_get_device(). If pci_enable_device() fails, the function returns without dropping that reference. Release the PCI device reference before returning from the pci_enable_device() failure path. Fixes: 5bda8f7b5468 ("video: fbdev: offb: Call pci_enable_device() before using the PCI VGA device") Co-developed-by: Myeonghun Pak Signed-off-by: Myeonghun Pak Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Co-developed-by: Taegyu Kim Signed-off-by: Taegyu Kim Signed-off-by: Yuho Choi Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit b24a1011b7ad4cc4007a1166d96491ac5757ba0d Author: Anthony Pighin (Nokia) Date: Tue Nov 25 18:00:10 2025 +0000 rtc: abx80x: Disable alarm feature if no interrupt attached [ Upstream commit 0fedce7244e4b85c049ce579c87e298a1b0b811d ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") exposed an issue where the rtc-abx80x driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid. For example, when a RTC_UIE_ON ioctl is handled, it should abort at the feature validation. Instead, it proceeds to the rtc_timer_enqueue(), which used to return an error from the set_alarm call. However, following the race condition handling, which likely should not be discarding predecing errors, a success condition is returned to the ioctl() caller. This results in (for example): hwclock: select() to /dev/rtc0 to wait for clock tick timed out Notwithstanding the validity of the race condition handling, if an interrupt wasn't specified, or could not be attached, the driver should clear the alarm feature bit. Fixes: 718a820a303c ("rtc: abx80x: add alarm support") Signed-off-by: Anthony Pighin Link: https://patch.msgid.link/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6ff8cca5cdb4f2e0ea6d28ecd78479dd3f221ebc Author: Bae Yeonju Date: Sat Mar 21 13:45:02 2026 +0900 fs/adfs: validate nzones in adfs_validate_bblk() [ Upstream commit dd9d3e16c2d5fa166e13dce07413be51f42c8f5d ] Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller. Fixes: f6f14a0d71b0 ("fs/adfs: map: move map-specific sb initialisation to map.c") Signed-off-by: Bae Yeonju Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 814d856cffed1b427f9b95f4b2bb1bb31be73c9d Author: Kohei Enju Date: Wed Apr 22 02:30:24 2026 +0000 vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll() [ Upstream commit e08a9fac5cf8c3fecf4755e7e3ac059f78b8f83d ] syzbot reported "sleeping function called from invalid context" in vhost_net_busy_poll(). Commit 030881372460 ("vhost_net: basic polling support") introduced a busy-poll loop and preempt_{disable,enable}() around it, where each iteration calls a sleepable function inside the loop. The purpose of disabling preemption was to keep local_clock()-based timeout accounting on a single CPU, rather than as a requirement of busy-poll itself: https://lore.kernel.org/1448435489-5949-4-git-send-email-jasowang@redhat.com From this perspective, migrate_disable() is sufficient here, so replace preempt_disable() with migrate_disable(), avoiding sleepable accesses from a preempt-disabled context. Fixes: 030881372460 ("vhost_net: basic polling support") Tested-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Reported-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e6a414.050a0220.24bfd3.002d.GAE@google.com/T/ Signed-off-by: Kohei Enju Acked-by: Michael S. Tsirkin Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3556656c6daebf8def751c7e71d11dd0a180d24 Author: Lee Jones Date: Tue Apr 21 13:45:26 2026 +0100 tipc: fix double-free in tipc_buf_append() [ Upstream commit d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a ] tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and contents") Suggested-by: Tung Nguyen Signed-off-by: Lee Jones Reviewed-by: Tung Nguyen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 01e5752f451a93e2c817b7b0043881adba7a6f10 Author: Alexey Kodanev Date: Wed Apr 22 16:05:36 2026 +0000 nfp: fix swapped arguments in nfp_encode_basic_qdr() calls [ Upstream commit 4078c5611d7585548b249377ebd60c272e410490 ] There is a mismatch between the passed arguments and the actual nfp_encode_basic_qdr() function parameter names: static int nfp_encode_basic_qdr(u64 addr, int dest_island, int cpp_tgt, int mode, bool addr40, int isld1, int isld0) { ... But "dest_island" and "cpp_tgt" are swapped at every call-site. For example: return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island, mode, addr40, isld1, isld0); As a result, nfp_encode_basic_qdr() receives "dest_island" as CPP target type, which is always NFP_CPP_TARGET_QDR(2) for these calls, and "cpp_tgt" as the destination island ID, which can accidentally match or be outside the valid NFP_CPP_TARGET_* types (e.g. '-1' for any destination). Since code already worked for years, also add extra pr_warn() to error paths in nfp_encode_basic_qdr() to help identify any potential address verification failures. Detected using the static analysis tool - Svace. Fixes: 4cb584e0ee7d ("nfp: add CPP access core") Signed-off-by: Alexey Kodanev Link: https://patch.msgid.link/20260422160536.61855-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09253a032437979b9a731ff0704998ac89ee14a6 Author: Mieczyslaw Nalewaj Date: Sun Apr 19 21:37:07 2026 +0200 net: dsa: realtek: rtl8365mb: fix mode mask calculation [ Upstream commit 0c078021d3861966614d5e594ee03587f0c9e74d ] The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting the 4-bit mask (0xF) by only (_extint % 2) bits instead of (_extint % 2) * 4. This caused the mask to overlap with the adjacent nibble when configuring odd-numbered external interfaces, selecting the wrong bits entirely. Align the shift calculation with the existing ...MODE_OFFSET macro. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Signed-off-by: Abdulkader Alrezej Signed-off-by: Mieczyslaw Nalewaj Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/400a6387-a444-4576-af6d-26be5410bce3@yahoo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 105060554a322af7bcdca5d6519d750ca80efb56 Author: Eric Dumazet Date: Tue Apr 21 14:16:55 2026 +0000 net/sched: sch_sfb: annotate data-races in sfb_dump_stats() [ Upstream commit 1ada03fdef82d3d7d2edb9dcd3acc91917675e48 ] sfb_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_sfb_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260421141655.3953721-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c1996e34ba21ac8275ad59c5dea8f703617cd92 Author: Eric Dumazet Date: Tue Apr 21 14:23:09 2026 +0000 net/sched: sch_red: annotate data-races in red_dump_stats() [ Upstream commit a8f5192809caf636d05ba47c144f282cfd0e3839 ] red_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_red_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142309.3964322-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f333ce84c6831619c36b6ae92cc783dd1903b91 Author: Eric Dumazet Date: Tue Apr 21 14:25:09 2026 +0000 net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats() [ Upstream commit bbfaa73ea6871db03dc05d7f05f00557a8981f25 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill st.qdisc_stats with live data. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142509.3967231-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b574cae0c1836f5329fef18c73e6014f7374b80 Author: Eric Dumazet Date: Tue Apr 21 14:29:44 2026 +0000 net/sched: sch_pie: annotate data-races in pie_dump_stats() [ Upstream commit 5154561d9b119f781249f8e845fecf059b38b483 ] pie_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_pie_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142944.4009941-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7fdc649a9fa13b484df08bf4388b8b1674e061ef Author: Eric Dumazet Date: Tue Apr 21 14:33:49 2026 +0000 net_sched: sch_hhf: annotate data-races in hhf_dump_stats() [ Upstream commit a6edf2cd4156b71e07258876b7626692e158f7e8 ] hhf_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421143349.4052215-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e67cc262afb384e835c3327e9d954eeaedc6a87 Author: Michael Bommarito Date: Sat Apr 18 10:10:47 2026 -0400 net/rds: zero per-item info buffer before handing it to visitors [ Upstream commit c88eb7e8d8397a8c1db59c425332c5a30b2a1682 ] rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson Fixes: ec16227e1414 ("RDS/IB: Infiniband transport") Signed-off-by: Michael Bommarito Reviewed-by: Sharath Srinivasan Reviewed-by: Allison Henderson Assisted-by: Claude:claude-opus-4-7 Link: https://patch.msgid.link/20260418141047.3398203-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3a93ce6e25757b8f375e38b8f91e1d9da4edc1a Author: Hyunwoo Kim Date: Tue Apr 21 00:31:47 2026 +0900 ksmbd: scope conn->binding slowpath to bound sessions only [ Upstream commit b0da97c034b6107d14e537e212d4ce8b22109a58 ] When the binding SESSION_SETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbd_session_lookup_all() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked. Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbd_chann_list). The channel entry is installed by the existing binding_session path in ntlm_authenticate()/krb5_authenticate() when a SESSION_SETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table. The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f54fd05be74fe3c79c81b29f4df73aea5e02212d Author: DaeMyung Kang Date: Sun Apr 19 20:02:54 2026 +0900 ksmbd: destroy tree_conn_ida in ksmbd_session_destroy() [ Upstream commit c049ee14eb4343b69b6f7755563f961f5e153423 ] When per-session tree_conn_ida was converted from a dynamically allocated ksmbd_ida to an embedded struct ida, ksmbd_ida_free() was removed from ksmbd_session_destroy() but no matching ida_destroy() was added. The session is therefore freed with the IDA's backing xarray still intact. The kernel IDA API expects ida_init() and ida_destroy() to be paired over an object's lifetime, so add the missing cleanup before the enclosing session is freed. Also move ida_init() to right after the session is allocated so that it is always paired with the destroy call even on the early error paths of __session_create() (ksmbd_init_file_table() or __init_smb2_session() failures), both of which jump to the error label and invoke ksmbd_session_destroy() on a partially initialised session. No leak has been observed in testing; this is a pairing fix to match the IDA lifetime rules, not a response to a reproduced regression. Fixes: d40012a83f87 ("cifsd: declare ida statically") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5a5d15b7c85d228f3ad55c586fd974b404ed7a8f Author: Jun Yan Date: Mon Mar 30 22:51:11 2026 +0800 arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number [ Upstream commit 174a0ef3b33434f475c87e66f37980e39b73805a ] Correct the interrupt number assigned to the Realtek PHY in the p230 following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm: fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY interrupt improvements [1]. [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/ Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260330145111.115318-1-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 335957df4ed60f02a2ec0432fbedbf0cc7241d8b Author: Weiming Shi Date: Thu Apr 16 18:01:51 2026 +0800 slip: bound decode() reads against the compressed packet length [ Upstream commit 4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7 ] slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20260414134126.758795-2-horms@kernel.org/ Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260416100147.531855-5-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4aa9eca6fda2919027dfd7a7cc69334982d89586 Author: Weiming Shi Date: Thu Apr 16 04:41:31 2026 +0800 slip: reject VJ receive packets on instances with no rstate array [ Upstream commit e76607442d5b73e1ba6768f501ef815bb58c2c0e ] slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work. Fixes: 4ab42d78e37a ("ppp, slip: Validate VJ compression slot parameters completely") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415204130.258866-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit edc806f9122961f0d3819f7c69c14cccde31f277 Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:57 2026 +0200 netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check [ Upstream commit 711987ba281fd806322a7cd244e98e2a81903114 ] The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Kito Xu (veritas501) Closes: https://lore.kernel.org/netfilter-devel/20260414074556.2512750-1-hxzene@gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1e19a07291bb8682c14c39a64725a3ae54ab8ccc Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:56 2026 +0200 netfilter: nfnetlink_osf: fix out-of-bounds read on option matching [ Upstream commit f5ca450087c3baf3651055e7a6de92600f827af3 ] In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset. Fixes: 1a6a0951fc00 ("netfilter: nfnetlink_osf: add missing fmatch check") Suggested-by: Florian Westphal Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ce76e1432dd81f9610ba14976c152a80c30cd04a Author: Yingnan Zhang <342144303@qq.com> Date: Wed Apr 15 22:40:29 2026 +0800 ipvs: fix MTU check for GSO packets in tunnel mode [ Upstream commit 67bf42cae41d847fd6e5749eb68278ca5d748b25 ] Currently, IPVS skips MTU checks for GSO packets by excluding them with the !skb_is_gso(skb) condition. This creates problems when IPVS tunnel mode encapsulates GSO packets with IPIP headers. The issue manifests in two ways: 1. MTU violation after encapsulation: When a GSO packet passes through IPVS tunnel mode, the original MTU check is bypassed. After adding the IPIP tunnel header, the packet size may exceed the outgoing interface MTU, leading to unexpected fragmentation at the IP layer. 2. Fragmentation with problematic IP IDs: When net.ipv4.vs.pmtu_disc=1 and a GSO packet with multiple segments is fragmented after encapsulation, each segment gets a sequentially incremented IP ID (0, 1, 2, ...). This happens because: a) The GSO packet bypasses MTU check and gets encapsulated b) At __ip_finish_output, the oversized GSO packet is split into separate SKBs (one per segment), with IP IDs incrementing c) Each SKB is then fragmented again based on the actual MTU This sequential IP ID allocation differs from the expected behavior and can cause issues with fragment reassembly and packet tracking. Fix this by properly validating GSO packets using skb_gso_validate_network_len(). This function correctly validates whether the GSO segments will fit within the MTU after segmentation. If validation fails, send an ICMP Fragmentation Needed message to enable proper PMTU discovery. Fixes: 4cdd34084d53 ("netfilter: nf_conntrack_ipv6: improve fragmentation handling") Signed-off-by: Yingnan Zhang <342144303@qq.com> Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9a109751b297b0f2135495749ef5a18ba31ec7d4 Author: Pablo Neira Ayuso Date: Wed Apr 15 12:21:00 2026 +0200 netfilter: xtables: restrict several matches to inet family [ Upstream commit b6fe26f86a1649f84e057f3f15605b08eda15497 ] This is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") to allow ipv4 and ipv6 only. - xt_mac - xt_owner - xt_physdev These extensions are not used by ebtables in userspace. Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4 specific. Fixes: ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") Reported-by: "Kito Xu (veritas501)" Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ab64e61c9323fa6de21bd20da1ddb29a0fb65d34 Author: Florian Westphal Date: Tue Apr 14 19:13:46 2026 +0200 netfilter: conntrack: remove sprintf usage [ Upstream commit 6e7066bdb481a87fe88c4fa563e348c03b2d373d ] Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..] Fixes: 9fafcd7b2032 ("[NETFILTER]: nf_conntrack/nf_nat: add SIP helper port") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0694618cf3e9b120666e31f5f383a6e466d95a0d Author: Xiang Mei Date: Tue Apr 14 15:14:01 2026 -0700 netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO [ Upstream commit 2195574dc6d9017d32ac346987e12659f931d932 ] nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as "should not happen". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622) Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Weiming Shi Suggested-by: Florian Westphal Suggested-by: Pablo Neira Ayuso Signed-off-by: Xiang Mei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9349e8563d60319aec0638e722499d046e7211b0 Author: Pablo Neira Ayuso Date: Tue Apr 14 13:06:38 2026 +0200 netfilter: nft_osf: restrict it to ipv4 [ Upstream commit b336fdbb7103fb1484e1dcb6741151d4b5a41e35 ] This expression only supports for ipv4, restrict it. Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf") Acked-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b39f763d720d623218bc1d95ace6855d7b474e81 Author: Weiming Shi Date: Wed Apr 15 19:46:54 2026 -0700 openvswitch: cap upcall PID array size and pre-size vport replies [ Upstream commit 2091c6aa0df6aba47deb5c8ab232b1cb60af3519 ] The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent. Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's.") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Weiming Shi Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260416024653.153456-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fcca1df05322bb04e344dd1178b54b76a08eb7c3 Author: Qingfang Deng Date: Wed Apr 15 10:24:51 2026 +0800 pppoe: drop PFC frames [ Upstream commit cc1ff87bce1ccd38410ab10960f576dcd17db679 ] RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames. If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures. To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding. Fixes: 7fb1b8ca8fa1 ("ppp: Move PFC decompression to PPP generic layer") Signed-off-by: Qingfang Deng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415022456.141758-2-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d45c7e99caf915b0f6c716bd8ffe9d45b9685761 Author: Michael Bommarito Date: Wed Apr 15 23:19:03 2026 -0400 sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks [ Upstream commit 0cf004ffb61cd32d140531c3a84afe975f9fc7ea ] sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data. Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Acked-by: Xin Long Link: https://patch.msgid.link/20260416031903.1447072-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38bdbc897c0d83a3e2b925a51b69420f1feba29a Author: Eric Dumazet Date: Thu Apr 16 10:35:05 2026 +0000 ipv6: fix possible UAF in icmpv6_rcv() [ Upstream commit f996edd7615e686ada141b7f3395025729ff8ccb ] Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call. Fixes: 4b3418fba0fe ("ipv6: icmp: include addresses in debug messages") Signed-off-by: Eric Dumazet Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Joe Damato Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260416103505.2380753-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3f83dd4b3ac5fd59861b02ea3902d21dc3c91208 Author: Matt Vollrath Date: Thu Apr 16 17:53:36 2026 -0700 e1000e: Unroll PTP in probe error handling [ Upstream commit aa3f7fe409350857c25d050482a2eef2cfd69b58 ] If probe fails after registering the PTP clock and its delayed work, these resources must be released. This was not an issue until a 2016 fix moved the e1000e_ptp_init() call before the jump to err_register. Fixes: aa524b66c5ef ("e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl") Signed-off-by: Matt Vollrath Tested-by: Avigail Dahan Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-12-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b2d47c9c8cf85cad267ff629b63edac9db224fd Author: Kohei Enju Date: Thu Apr 16 17:53:33 2026 -0700 i40e: don't advertise IFF_SUPP_NOFCS [ Upstream commit a24162f18825684ad04e3a5d0531f8a50d679347 ] i40e advertises IFF_SUPP_NOFCS, allowing users to use the SO_NOFCS socket option. However, this option is silently ignored, as the driver does not check skb->no_fcs, and always enables FCS insertion offload. Fix this by removing the advertisement of IFF_SUPP_NOFCS. This behavior can be reproduced with a simple AF_PACKET socket: import socket s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW) s.setsockopt(socket.SOL_SOCKET, 43, 1) # SO_NOFCS s.bind(("eth0", 0)) s.send(b'\xff' * 64) Previously, send() succeeds but the driver ignores SO_NOFCS. With this change, send() fails with -EPROTONOSUPPORT, as expected. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-9-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2eec9c2a36567b54dafe5244fdd527709d8b48b6 Author: Eric Dumazet Date: Thu Apr 16 20:03:18 2026 +0000 tcp: annotate data-races around (tp->write_seq - tp->snd_nxt) [ Upstream commit 3a63b3d160560ef51e43fb4c880a5cde8078053c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() annotations to keep KCSAN happy. WRITE_ONCE() annotations are already present. Fixes: e08ab0b377a1 ("tcp: add bytes not sent to SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-14-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f132820f92ba2036ec82aadde5abdb5f6be8ae39 Author: Eric Dumazet Date: Thu Apr 16 20:03:14 2026 +0000 tcp: annotate data-races around tp->dsack_dups [ Upstream commit a984705ca88b976bf1087978fd98b7f3993da88c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e10b6554ff2 ("tcp: add dsack blocks received stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-10-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68f4e974fc4bc524f561d3e1746ac21cd5d99bbf Author: Eric Dumazet Date: Thu Apr 16 20:03:13 2026 +0000 tcp: annotate data-races around tp->bytes_retrans [ Upstream commit 5efc7b9f7cbd43401f1af81d3d7f2be00f93390d ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: fb31c9b9f6c8 ("tcp: add data bytes retransmitted stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 629e3e6d7464bfcc67b10ece7ddecf53bba3b6ff Author: Eric Dumazet Date: Thu Apr 16 20:03:12 2026 +0000 tcp: annotate data-races around tp->bytes_sent [ Upstream commit ee43e957ce2ec77b2ec47fef28f3c0df6ab01a31 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: ba113c3aa79a ("tcp: add data bytes sent stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dac313664e8ba74ba84430f78c5cd3e261a22e35 Author: Eric Dumazet Date: Thu Apr 16 20:03:07 2026 +0000 tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans [ Upstream commit 21e92a38cfd891538598ba8f805e0165a820d532 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e98102f4897 ("tcp: record pkts sent and retransmistted") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3fd3e1e0c3504237262b290e97cfb787dc7cec5 Author: Eric Dumazet Date: Fri Mar 17 15:55:39 2023 +0000 tcp: preserve const qualifier in tcp_sk() [ Upstream commit e9d9da91548b21e189fcd0259a0f2d26d1afc509 ] We can change tcp_sk() to propagate its argument const qualifier, thanks to container_of_const(). We have two places where a const sock pointer has to be upgraded to a write one. We have been using const qualifier for lockless listeners to clearly identify points where writes could happen. Add tcp_sk_rw() helper to better document these. tcp_inbound_md5_hash(), __tcp_grow_window(), tcp_reset_check() and tcp_rack_reo_wnd() get an additional const qualififer for their @tp local variables. smc_check_reset_syn_req() also needs a similar change. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: 21e92a38cfd8 ("tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans") Signed-off-by: Sasha Levin commit 87bf574c24e02c2289b5887ee28722ce7f824e18 Author: Greg Kroah-Hartman Date: Mon Dec 5 13:12:03 2022 +0100 container_of: add container_of_const() that preserves const-ness of the pointer [ Upstream commit 64f6a5d1922bf6d2b2d845de20d4563a6f328e2d ] container_of does not preserve the const-ness of a pointer that is passed into it, which can cause C code that passes in a const pointer to get a pointer back that is not const and then scribble all over the data in it. To prevent this, container_of_const() will preserve the const status of the pointer passed into it using the newly available _Generic() method. Suggested-by: Jason Gunthorpe Suggested-by: Sakari Ailus Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Jason Gunthorpe Reviewed-by: Andy Shevchenko Reviewed-by: Sakari Ailus Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20221205121206.166576-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 21e92a38cfd8 ("tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans") Signed-off-by: Sasha Levin commit 9c22234529a83e9da5ceaed9a3228c9187752c8d Author: Greg Kroah-Hartman Date: Mon Oct 24 14:39:33 2022 +0200 container_of: remove container_of_safe() [ Upstream commit 848dba781f1951636c966c9f3a6a41a5b2f8b572 ] It came in from a staging driver that has been long removed from the tree, and there are no in-kernel users of the macro, and it's very dubious if anyone should ever use this thing, so just remove it entirely. Reviewed-by: Sakari Ailus Acked-by: Rafael J. Wysocki Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221024123933.3331116-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 21e92a38cfd8 ("tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans") Signed-off-by: Sasha Levin commit 7256996e1ef553716817f3bfd077c2f3b48b582f Author: Vinicius Costa Gomes Date: Fri Apr 10 18:57:57 2026 -0700 net/sched: taprio: fix use-after-free in advance_sched() on schedule switch [ Upstream commit 105425b1969c5affe532713cfac1c0b320d7ac2b ] In advance_sched(), when should_change_schedules() returns true, switch_schedules() is called to promote the admin schedule to oper. switch_schedules() queues the old oper schedule for RCU freeing via call_rcu(), but 'next' still points into an entry of the old oper schedule. The subsequent 'next->end_time = end_time' and rcu_assign_pointer(q->current_entry, next) are use-after-free. Fix this by selecting 'next' from the new oper schedule immediately after switch_schedules(), and using its pre-calculated end_time. setup_first_end_time() sets the first entry's end_time to base_time + interval when the schedule is installed, so the value is already correct. The deleted 'end_time = sched_base_time(admin)' assignment was also harmful independently: it would overwrite the new first entry's pre-calculated end_time with just base_time. Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule") Reported-by: Junxi Qian Signed-off-by: Vinicius Costa Gomes Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0be4e87fe26ca86fc08a6d873491d830b898ad77 Author: Vladimir Oltean Date: Tue Feb 7 15:54:32 2023 +0200 net/sched: taprio: rename close_time to end_time [ Upstream commit e5517551112ff2395611e552443932152f83672d ] There is a confusion in terms in taprio which makes what is called "close_time" to be actually used for 2 things: 1. determining when an entry "closes" such that transmitted skbs are never allowed to overrun that time (?!) 2. an aid for determining when to advance and/or restart the schedule using the hrtimer It makes more sense to call this so-called "close_time" "end_time", because it's not clear at all to me what "closes". Future patches will hopefully make better use of the term "to close". This is an absolutely mechanical change. Signed-off-by: Vladimir Oltean Reviewed-by: Kurt Kanzenbach Signed-off-by: David S. Miller Stable-dep-of: 105425b1969c ("net/sched: taprio: fix use-after-free in advance_sched() on schedule switch") Signed-off-by: Sasha Levin commit 8f9d0ec10100b55b91d616892ab7b78a6bc9ddf9 Author: Vladimir Oltean Date: Tue Feb 7 15:54:28 2023 +0200 net/sched: taprio: refactor one skb dequeue from TXQ to separate function [ Upstream commit 92f966674f6a257eddfa60a85f9b6741d6087ccb ] Future changes will refactor the TXQ selection procedure, and a lot of stuff will become messy, the indentation of the bulk of the dequeue procedure would increase, etc. Break out the bulk of the function into a new one, which knows the TXQ (child qdisc) we should perform a dequeue from. Signed-off-by: Vladimir Oltean Reviewed-by: Kurt Kanzenbach Signed-off-by: David S. Miller Stable-dep-of: 105425b1969c ("net/sched: taprio: fix use-after-free in advance_sched() on schedule switch") Signed-off-by: Sasha Levin commit e68337c28387044b4ca27eb678340a9f517ba962 Author: Vladimir Oltean Date: Tue Feb 7 15:54:27 2023 +0200 net/sched: taprio: continue with other TXQs if one dequeue() failed [ Upstream commit 1638bbbe4ececa615b273497d347d59ad71060a2 ] This changes the handling of an unlikely condition to not stop dequeuing if taprio failed to dequeue the peeked skb in taprio_dequeue(). I've no idea when this can happen, but the only side effect seems to be that the atomic_sub_return() call right above will have consumed some budget. This isn't a big deal, since either that made us remain without any budget (and therefore, we'd exit on the next peeked skb anyway), or we could send some packets from other TXQs. I'm making this change because in a future patch I'll be refactoring the dequeue procedure to simplify it, and this corner case will have to go away. Signed-off-by: Vladimir Oltean Reviewed-by: Kurt Kanzenbach Signed-off-by: David S. Miller Stable-dep-of: 105425b1969c ("net/sched: taprio: fix use-after-free in advance_sched() on schedule switch") Signed-off-by: Sasha Levin commit 6275796f22bb382f3e9aa58ed0b4ef7bdad78cb8 Author: Jiayuan Chen Date: Mon Apr 13 19:45:19 2026 +0800 nexthop: fix IPv6 route referencing IPv4 nexthop [ Upstream commit 29c95185ba32b621fbc3800fb86e7dc3edf5c2be ] syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3 Fixes: 7bf4796dd099 ("nexthops: add support for replace") Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260413114522.147784-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7ec84fe014f20b7e8684f6ee0c08251118f8d124 Author: Dudu Lu Date: Mon Apr 13 19:00:41 2026 +0800 net/sched: sch_cake: fix NAT destination port not being updated in cake_update_flowkeys [ Upstream commit f9e40664706927d7ae22a448a3383e23c38a4c0b ] cake_update_flowkeys() is supposed to update the flow dissector keys with the NAT-translated addresses and ports from conntrack, so that CAKE's per-flow fairness correctly identifies post-NAT flows as belonging to the same connection. For the source port, this works correctly: keys->ports.src = port; But for the destination port, the assignment is reversed: port = keys->ports.dst; This means the NAT destination port is never updated in the flow keys. As a result, when multiple connections are NATed to the same destination, CAKE treats them as separate flows because the original (pre-NAT) destination ports differ. This breaks CAKE's NAT-aware flow isolation when using the "nat" mode. The bug was introduced in commit b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") which refactored the original direct assignment into a compare-and-conditionally-update pattern, but wrote the destination port update backwards. Fix by reversing the assignment direction to match the source port pattern. Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") Signed-off-by: Dudu Lu Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260413110041.44704-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6fec3bbda92af06e9d0506675d11f4fd4bee839e Author: Peng Fan Date: Sun Mar 29 21:00:13 2026 +0800 arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT [ Upstream commit 42a9f5a16328ed78a88e0498556965b6c6ec515c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4b61cdd0855c9ddf1003a8cfa4d4fa836ea4d687 Author: Peng Fan Date: Sun Mar 29 21:00:12 2026 +0800 arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT [ Upstream commit 0fb37990774113afd943eaa91323679388584b6d ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4866005f3e3487f4c757bf860faa428f6a12fd58 Author: René Rebe Date: Wed Nov 26 17:42:56 2025 +0100 PCMCIA: Fix garbled log messages for KERN_CONT [ Upstream commit bfeaa6814bd3f9a1f6d525b3b35a03b9a0368961 ] For years the PCMCIA info messages are messed up by superfluous newlines. While f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") converted the code to pr_cont(), dev_info enforces a \n via vprintk_store setting LOG_NEWLINE, breaking subsequent pr_cont. Fix by logging the device name manually to allow pr_cont to work for more readable and not \n distorted logs. Fixes: f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") Signed-off-by: René Rebe Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit ab98183e360f75980e2350d4d61e4ff7207b4ba5 Author: Peng Fan Date: Thu Mar 26 15:28:15 2026 +0800 arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT [ Upstream commit f9ed5afc988da3e22543725e35be6addbb0497bc ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 8d6712695bc8e ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 575a33a5741fb9620bc3e27bc258bc23a8b6722d Author: Peng Fan Date: Thu Mar 26 15:28:09 2026 +0800 arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT [ Upstream commit ea8c90f5c7ceeb6657a8fe564aa7b190dce298a6 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eefe06b295087 ("arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus SoM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit dfb2cf434829819268fe50f41542aad318ad62b2 Author: Paul Moses Date: Wed Apr 1 03:07:49 2026 -0500 crypto: ccp - copy IV using skcipher ivsize [ Upstream commit a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4 ] AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. Fixes: 2b789435d7f3 ("crypto: ccp - CCP AES crypto API support") Signed-off-by: Paul Moses Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 02548da36144c9a8ae75a1b9f49843d3c3ab7906 Author: T Pratham Date: Wed Apr 15 20:06:58 2026 +0530 crypto: sa2ul - Fix AEAD fallback algorithm names [ Upstream commit 8451ab6ad686ffdcdf9ddadaa446a79ab48e5590 ] For authenc AEAD algorithms, sa2ul is trying to register very specific -ce version as a fallback. This causes registration failure on SoCs which do not have ARMv8-CE enabled/available. Change the fallback algorithm from the specific driver name to generic algorithm name so that the kernel can allocate any available fallback. Fixes: d2c8ac187fc92 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: T Pratham Reviewed-by: Manorit Chawdhry Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5982f9673788efb1451a9c70800f3df9f0b1acdb Author: Ville Syrjälä Date: Tue Mar 24 15:48:38 2026 +0200 drm/i915/wm: Verify the correct plane DDB entry [ Upstream commit a97c88a176b6b8d116f4d3f508f3bd02bc77b462 ] Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai (cherry picked from commit f002f7c7439de18117a31ca84dc87a59719c3dd6) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit 1b8ad95d66f183a91b94ab0806af83f7579c3202 Author: Stanislav Lisovskiy Date: Tue Apr 2 18:50:07 2024 +0300 drm/i915: Loop over all active pipes in intel_mbus_dbox_update [ Upstream commit e8333ab22cd8c750b7c14d3da7c0eef3ba85527f ] We need to loop through all active pipes, not just the ones, that are in current state, because disabling and enabling even a particular pipe affects credits in another one. Reviewed-by: Uma Shankar Signed-off-by: Stanislav Lisovskiy Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-6-ville.syrjala@linux.intel.com Stable-dep-of: a97c88a176b6 ("drm/i915/wm: Verify the correct plane DDB entry") Signed-off-by: Sasha Levin commit 814d10c6d589cb41073526c918c230075d4ba7b4 Author: Gustavo Sousa Date: Tue Mar 12 13:36:35 2024 -0300 drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update() [ Upstream commit 66a0e0681392420b326f00ba732e6bda099eda29 ] As of Xe2LPD, it is now possible to select the source of the MDCLK as either the CD2XCLK or the CDCLK PLL. Previous display IPs were hardcoded to use the CD2XCLK. For those, the ratio between MDCLK and CDCLK remained constant, namely 2. For Xe2LPD, when we select the CDCLK PLL as the source, the ratio will vary according to the squashing configuration (since the cd2x divisor is fixed for all supported configurations). To help the transition to supporting changes in the ratio, extract the function intel_dbuf_mdclk_cdclk_ratio_update() from the existing logic and call it using 2 as hardcoded ratio. Upcoming changes will use that function for updates in the ratio due to CDCLK changes. Bspec: 50057, 69445, 49213, 68868 Reviewed-by: Matt Roper Signed-off-by: Gustavo Sousa Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-5-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi Stable-dep-of: a97c88a176b6 ("drm/i915/wm: Verify the correct plane DDB entry") Signed-off-by: Sasha Levin commit f2b10734b022eb967f1e6b842e4f9e00049f0d6a Author: Ville Syrjälä Date: Wed Oct 4 18:56:00 2023 +0300 drm/i915: Constify watermark state checker [ Upstream commit 487a2db8bc4eb79c53c9ff8fca65a7fc8350df6c ] The skl+ wm state checker has no reason to modify the crtc state, so make it const. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20231004155607.7719-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula Stable-dep-of: a97c88a176b6 ("drm/i915/wm: Verify the correct plane DDB entry") Signed-off-by: Sasha Levin commit d3ff0c121bbaef026df6248ab7ef6f0b068b0647 Author: Yongpeng Yang Date: Fri Apr 10 23:05:39 2026 +0800 f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() [ Upstream commit 5909bedbed38c558bee7cb6758ceedf9bc3a9194 ] In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation. Fixes: b6a06cbbb5f7 ("f2fs: support hot file extension") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 6edbef073ff0ee98cb60ea45d98b24d6a8f9aab5 Author: Christophe JAILLET Date: Thu Aug 15 08:47:28 2024 +0800 f2fs: Use sysfs_emit_at() to simplify code [ Upstream commit f7a678bbe5a8f22cfcef5369757cc9b95f73e027 ] This file already uses sysfs_emit(). So be consistent and also use sysfs_emit_at(). This slightly simplifies the code and makes it more readable. Reviewed-by: Chao Yu Signed-off-by: Christophe JAILLET Signed-off-by: Jaegeuk Kim Stable-dep-of: 5909bedbed38 ("f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()") Signed-off-by: Sasha Levin commit 85f9a9b56fa009acd6323de69f127a09d317b42a Author: Brian Masney Date: Mon Mar 30 10:32:37 2026 -0400 clk: visconti: pll: initialize clk_init_data to zero [ Upstream commit 1603cbb64173a0e9fa7500f2a686f4aa011c58b9 ] Sashiko reported the following: > The struct clk_init_data init is declared on the stack without being > fully zero-initialized. While fields like name, flags, parent_names, > num_parents, and ops are explicitly assigned, the parent_data and > parent_hws fields are left containing stack garbage. clk_core_populate_parent_map() currently prefers the parent names over the parent data and hws, so this isn't a problem at the moment. If that ordering ever changed in the future, then this could lead to some unexpected crashes. Let's just go ahead and make sure that the struct clk_init_data is initialized to zero as a good practice. Fixes: b4cbe606dc367 ("clk: visconti: Add support common clock driver and reset driver") Link: https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com Signed-off-by: Brian Masney Reviewed-by: Benoît Monin Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 584954f1da4be4998a15583f440c8c79890879fe Author: Geert Uytterhoeven Date: Tue Mar 31 17:21:43 2026 +0200 lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug() [ Upstream commit 36776b7f8a8955b4e75b5d490a75fee0c7a2a7ef ] print_hex_dump_bytes() claims to be a simple wrapper around print_hex_dump(), but it actally calls print_hex_dump_debug(), which means no output is printed if (dynamic) DEBUG is disabled. Update the documentation to match the implementation. Fixes: 091cb0994edd20d6 ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds") Signed-off-by: Geert Uytterhoeven Reviewed-by: Petr Mladek Link: https://patch.msgid.link/3d5c3069fd9102ecaf81d044b750cd613eb72a08.1774970392.git.geert+renesas@glider.be Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 70bc229599429d99527e9cde9bce2ff89a92fabd Author: Konrad Dybcio Date: Tue Jan 20 12:19:26 2026 +0100 clk: qcom: dispcc-sc7180: Add missing MDSS resets [ Upstream commit b0bc6011c5499bdfddd0390262bfa13dce1eff74 ] The MDSS resets have so far been left undescribed. Fix that. Fixes: dd3d06622138 ("clk: qcom: Add display clock controller driver for SC7180") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Taniya Das Tested-by: Val Packett # sc7180-ecs-liva-qc710 Link: https://lore.kernel.org/r/20260120-topic-7180_dispcc_bcr-v1-2-0b1b442156c3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit de145e368c70eb2188e8ac6db7cca60c503e2a17 Author: Konrad Dybcio Date: Tue Jan 20 12:19:25 2026 +0100 dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets [ Upstream commit fc6e29d42872680dca017f2e5169eefe971f8d89 ] The MDSS resets have so far been left undescribed. Fix that. Fixes: 75616da71291 ("dt-bindings: clock: Introduce QCOM sc7180 display clock bindings") Signed-off-by: Konrad Dybcio Reviewed-by: Taniya Das Acked-by: Krzysztof Kozlowski Tested-by: Val Packett # sc7180-ecs-liva-qc710 Link: https://lore.kernel.org/r/20260120-topic-7180_dispcc_bcr-v1-1-0b1b442156c3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: b0bc6011c549 ("clk: qcom: dispcc-sc7180: Add missing MDSS resets") Signed-off-by: Sasha Levin commit 486cda9776fe6147f31015bb0f1ae40e7cd54958 Author: Geert Uytterhoeven Date: Thu Mar 5 11:11:16 2026 +0100 clk: xgene: Fix mapping leak in xgene_pllclk_init() [ Upstream commit f520a492e07bc6718e26cfb7543ab4cadd8bb0e2 ] If xgene_register_clk_pll() fails, the mapped register block is never unmapped. Fixes: 308964caeebc45eb ("clk: Add APM X-Gene SoC clock driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 578b1b223bf0a920ba1e587d1d15c296aff87e8d Author: Arnd Bergmann Date: Fri Mar 20 16:18:49 2026 +0100 clk: qoriq: avoid format string warning [ Upstream commit 096abbb6682ee031a0f5ce9f4c71ead9fa63d31e ] clang-22 warns about the use of non-variadic format arguments passed into snprintf(): drivers/clk/clk-qoriq.c:925:39: error: diagnostic behavior may be improved by adding the 'format(printf, 7, 8)' attribute to the declaration of 'create_mux_common' [-Werror,-Wmissing-format-attribute] 910 | static struct clk * __init create_mux_common(struct clockgen *cg, | __attribute__((format(printf, 7, 8))) 911 | struct mux_hwclock *hwc, 912 | const struct clk_ops *ops, 913 | unsigned long min_rate, 914 | unsigned long max_rate, 915 | unsigned long pct80_rate, 916 | const char *fmt, int idx) 917 | { 918 | struct clk_init_data init = {}; 919 | struct clk *clk; 920 | const struct clockgen_pll_div *div; 921 | const char *parent_names[NUM_MUX_PARENTS]; 922 | char name[32]; 923 | int i, j; 924 | 925 | snprintf(name, sizeof(name), fmt, idx); | ^ drivers/clk/clk-qoriq.c:910:28: note: 'create_mux_common' declared here 910 | static struct clk * __init create_mux_common(struct clockgen *cg, Rework this to pass the 'int idx' as a varargs argument, allowing the format string to be verified at the caller location. Fixes: 0dfc86b3173f ("clk: qoriq: Move chip-specific knowledge into driver") Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c2f877a8e35648c2ea0e630dded3e76a4156d6a0 Author: Sebastian Krzyszkowiak Date: Wed Jan 28 00:47:21 2026 +0100 clk: imx8mq: Correct the CSI PHY sels [ Upstream commit d16f57caa78776e6e8a88b96cb2597797b376138 ] According to i.MX 8M Quad Reference Manual (Section 5.1.2 Table 5-1) MIPI_CSI1_PHY_REF_CLK_ROOT and MIPI_CSI2_PHY_REF_CLK_ROOT have SYSTEM_PLL2_DIV3 available as their second source, which corresponds to sys2_pll_333m rather than sys2_pll_125m. Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM") Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260128-imx8mq-csi-clk-v1-1-ac028ed26e8c@puri.sm Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 412d23dc078879cafeb4b1b9b9ef83b1c60d0485 Author: Felix Gu Date: Tue Feb 3 22:07:58 2026 +0800 clk: imx: imx6q: Fix device node reference leak in of_assigned_ldb_sels() [ Upstream commit 9faf207208951460f3f7eefbc112246c8d28ff1b ] The function of_assigned_ldb_sels() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 5d283b083800 ("clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-2-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 3a2ebcfed96295058f75086ecce3c0e5c24e236e Author: Felix Gu Date: Tue Feb 3 22:07:57 2026 +0800 clk: imx: imx6q: Fix device node reference leak in pll6_bypassed() [ Upstream commit 4b84d496c804b470124cd3a08e928df6801d8eae ] The function pll6_bypassed() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 3cc48976e9763 ("clk: imx6q: handle ENET PLL bypass") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-1-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit b19dc4bd05afe0d9f54b0975014f35df1578af3b Author: Val Packett Date: Thu Mar 12 08:12:13 2026 -0300 clk: qcom: dispcc-sm8250: Enable parents for pixel clocks [ Upstream commit acf7a91d0b0e9e3ef374944021de62062125b7e4 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-9-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bc8641334c629a21618e2c639a9a6bafda1d07c5 Author: Val Packett Date: Thu Mar 12 08:12:12 2026 -0300 clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk [ Upstream commit 8c522da70f0c2e5148c4c13ccb1c64cca57a6fdb ] mdss_gdsc can get stuck on boot due to RCGs being left on from last boot. As a fix, commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") introduced a callback to ensure the RCG is off upon init. However, the fix depends on all shared RCGs being marked as such in code. For SM8150/SC8180X/SM8250 the MDSS vsync clock was using regular ops, unlike the same clock in the SC7180 code. This was causing display to frequently fail to initialize after rebooting on the Surface Pro X. Fix by using shared ops for this clock. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-8-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 284476d8f99bd828e76eca3dd6bb7745543509a1 Author: Val Packett Date: Thu Mar 12 08:12:09 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for PCIe power domains [ Upstream commit ccb92c78b42edd26225b4d5920847dfee3e1b093 ] As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. This fixes the link not surviving upon resume: nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS read failed (134) nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: Disabling device after reset failure: -19 Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260312112321.370983-5-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7f765a0b5c93e04bfe276e78ccbaa10372232c01 Author: Val Packett Date: Thu Mar 12 08:12:08 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for USB power domains [ Upstream commit 25bc96f26cd6c19dde13a0b9859183e531d6fbfc ] The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.0.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset (The reinitialization usually succeeds, but it does slow down resume.) To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-4-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ccbde14a533c34e58677e3b4608cf700d5b02da7 Author: Val Packett Date: Thu Mar 12 08:12:07 2026 -0300 clk: qcom: gcc-sc8180x: Add missing GDSCs [ Upstream commit 3565741eb985a8a7cc6656eb33496195468cb99e ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-3-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 039db324ee5f2c5541094a8d0f713417f0a533ec Author: Val Packett Date: Thu Mar 12 08:12:06 2026 -0300 dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs [ Upstream commit 76404ffbf07f28a5ec04748e18fce3dac2e78ef6 ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Signed-off-by: Val Packett Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260312112321.370983-2-val@packett.cool Signed-off-by: Bjorn Andersson Stable-dep-of: 3565741eb985 ("clk: qcom: gcc-sc8180x: Add missing GDSCs") Signed-off-by: Sasha Levin commit 5efc3ef4758f8d98c257419fa21daca3227de61a Author: Junrui Luo Date: Wed Mar 4 23:42:58 2026 +0800 scsi: target: core: Fix integer overflow in UNMAP bounds check [ Upstream commit 2bf2d65f76697820dbc4227d13866293576dd90a ] sbc_execute_unmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow. Add an overflow check matching the pattern already used for WRITE_SAME in the same file. Fixes: 86d7182985d2 ("target: Add sbc_execute_unmap() helper") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881593C61AD52C69FBDB0BDAF7CA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fe671d3c84ffb1b763d590c25195755adeaadaba Author: Yang Erkun Date: Tue Jan 27 14:20:43 2026 +0800 scsi: sg: Resolve soft lockup issue when opening /dev/sgX [ Upstream commit d06a310b45e153872033dd0cf19d5a2279121099 ] The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size. Fixes: 6460e75a104d ("[SCSI] sg: fixes for large page_size") Signed-off-by: Yang Erkun Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260127062044.3034148-3-yangerkun@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ff0a5ddbb3b5b319588b70f755a503310395dd17 Author: Dmitry Baryshkov Date: Mon Jan 12 04:12:23 2026 +0200 clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source [ Upstream commit 141af1be817c42c7f1e1605348d4b1983d319bea ] The clk_dp_ops are supposed to be used for DP-related clocks with a proper MND divier. Use standard RCG2 ops for dptx1_aux_clk_src, the same as all other DPTX AUX clocks in this driver. Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260112-dp-aux-clks-v1-2-456b0c11b069@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit abda65bdd13084c771842adaac1f652d0660dd82 Author: Florian Westphal Date: Mon Mar 30 14:27:39 2026 +0200 RDMA/core: Prefer NLA_NUL_STRING [ Upstream commit 6ed3d14fc45d3da6025e7fe4a6a09066856698e2 ] These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator. Either this needs to switch to nla_strcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLA_NUL_STRING. As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLA_NUL_STRING use is the simpler solution. Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Link: https://patch.msgid.link/r/20260330122742.13315-1-fw@strlen.de Signed-off-by: Florian Westphal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 75c738d4f27fa18a2a033de153bd40302bde6a66 Author: Pengpeng Hou Date: Wed Apr 8 08:38:21 2026 +0800 platform/x86: dell-wmi-sysman: bound enumeration string aggregation [ Upstream commit 3c34471c26abc52a37f5ad90949e2e4b8027eb14 ] populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260408084501.1-dell-wmi-sysman-v2-pengpeng@iscas.ac.cn [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 89b00596edfea95e22f53b33df63e4e65d58c25b Author: Fedor Pchelkin Date: Fri Apr 3 16:42:39 2026 +0300 platform/x86: dell_rbu: avoid uninit value usage in packet_size_write() [ Upstream commit f8fd138c2363c0e2d3235c32bfb4fb5c6474e4ae ] Ensure the temp value has been properly parsed from the user-provided buffer and initialized to be used in later operations. While at it, prefer a convenient kstrtoul() helper. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: ad6ce87e5bd4 ("[PATCH] dell_rbu: changes in packet update mechanism") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260403134240.604837-1-pchelkin@ispras.ru [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit bc7a0c34c4ca259cfddf3bc18fc5b3c6411d26ed Author: Pengpeng Hou Date: Fri Mar 27 14:19:55 2026 +0800 fs/ntfs3: terminate the cached volume label after UTF-8 conversion [ Upstream commit a6cd43fe9b083fa23fe1595666d5738856cb261a ] ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Pengpeng Hou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 88f3f156ea5327ac1d87e77fdd088cce78b6a390 Author: Andy Shevchenko Date: Wed Feb 4 21:21:49 2026 +0100 nfs/blocklayout: Fix compilation error (`make W=1`) in bl_write_pagelist() [ Upstream commit f83c8dda456ce4863f346aa26d88efa276eda35d ] Clang compiler is not happy about set but unused variable (when dprintk() is no-op): .../blocklayout/blocklayout.c:384:9: error: variable 'count' set but not used [-Werror,-Wunused-but-set-variable] Remove a leftover from the previous cleanup. Fixes: 3a6fd1f004fc ("pnfs/blocklayout: remove read-modify-write handling in bl_write_pagelist") Acked-by: Anna Schumaker Reviewed-by: Jeff Layton Signed-off-by: Andy Shevchenko Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7c8e5d608bbc5b7ab6b3fc995b7bf445bdca1a7c Author: Abdun Nihaal Date: Tue Jan 20 15:56:20 2026 +0530 mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata() [ Upstream commit a5a65a7fb2f7796bbe492cd6be59c92cb64377d1 ] The memory allocated for cell.name using kmemdup() is not freed when mfd_add_devices() fails. Fix that by using devm_kmemdup(). Fixes: 8e00593557c3 ("mfd: Add mc13892 support to mc13xxx") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260120102622.66921-1-nihaal@cse.iitm.ac.in Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 31cadccde50358794877c84dcbc027c03c494257 Author: Rafael J. Wysocki Date: Fri Mar 20 11:31:54 2026 +0100 platform/x86: panasonic-laptop: Fix OPTD notifier registration and cleanup [ Upstream commit 8baeff2c1d33dad8572216c6ad3a7425852507d4 ] An ACPI notify handler is leaked if device_create_file() returns an error in acpi_pcc_hotkey_add(). Also, it is pointless to call pcc_unregister_optd_notifier() in acpi_pcc_hotkey_remove() if pcc->platform is NULL and it is better to arrange the cleanup code in that function in the same order as the rollback code in acpi_pcc_hotkey_add(). Address the above by placing the pcc_register_optd_notifier() call in acpi_pcc_hotkey_add() after the device_create_file() return value check and placing the pcc_unregister_optd_notifier() call in acpi_pcc_hotkey_remove() right before the device_remove_file() call. Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2411055.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 11207e42a332eb8bbcb9fe74df9edd2a807c5607 Author: Randy Dunlap Date: Thu Jan 29 23:29:37 2026 -0800 tty: hvc_iucv: fix off-by-one in number of supported devices [ Upstream commit f2a880e802ad12d1e38039d1334fb1475d0f5241 ] MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops. Fixes: 44a01d5ba8a4 ("[S390] s390/hvc_console: z/VM IUCV hypervisor console support") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260130072939.1535869-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c4f416ade57cee333094fc7c9fa21a172e5a04de Author: Chen Ni Date: Thu Feb 26 11:30:48 2026 +0800 leds: lgm-sso: Remove duplicate assignments for priv->mmap [ Upstream commit 7186d0330c3f3e86de577687a82f4ebd96dcb5ac ] Remove duplicate assignment of priv->mmap in intel_sso_led_probe(). Fixes: fba8a6f2263b ("leds: lgm-sso: Fix clock handling") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260226033048.3715915-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 59a420942fc21333cc9ca38fd0897afc3136ae02 Author: Rafael J. Wysocki Date: Wed Mar 4 19:54:08 2026 +0100 platform/surface: surfacepro3_button: Drop wakeup source on remove [ Upstream commit 1410a228ab2d36fe2b383415a632ae12048d4f3a ] The wakeup source added by device_init_wakeup() in surface_button_add() needs to be dropped during driver removal, so update the driver to do that. Fixes: 19351f340765 ("platform/x86: surfacepro3: Support for wakeup from suspend-to-idle") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4368848.1IzOArtZ34@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7249271521012fbb78d6f0d7d3bd63243bcce23d Author: Chen Ni Date: Tue Feb 3 10:16:25 2026 +0800 backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt() [ Upstream commit 797cc011ae02bda26f93d25a4442d7a1a77d84df ] The devm_gpiod_get_optional() function may return an ERR_PTR in case of genuine GPIO acquisition errors, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the call in sky81452_bl_parse_dt(). On error, return the error code to ensure proper failure handling rather than proceeding with invalid pointers. Fixes: e1915eec54a6 ("backlight: sky81452: Convert to GPIO descriptors") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260203021625.578678-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6f1b8d6a27976ca653adff59633669863c2dae9d Author: Nuno Sa Date: Thu Jun 6 09:22:37 2024 +0200 dev_printk: add new dev_err_probe() helpers [ Upstream commit dbbe7eaf0e4795bf003ac06872aaf52b6b6b1310 ] This is similar to dev_err_probe() but for cases where an ERR_PTR() or ERR_CAST() is to be returned simplifying patterns like: dev_err_probe(dev, ret, ...); return ERR_PTR(ret) or dev_err_probe(dev, PTR_ERR(ptr), ...); return ERR_CAST(ptr) Signed-off-by: Nuno Sa Link: https://patch.msgid.link/20240606-dev-add_dev_errp_probe-v3-1-51bb229edd79@analog.com Signed-off-by: Jonathan Cameron Stable-dep-of: 797cc011ae02 ("backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt()") Signed-off-by: Sasha Levin commit 1226887386598acb7cfee4458e06bc9f20dfd980 Author: Andy Shevchenko Date: Fri Jul 21 16:13:09 2023 +0300 driver core: Move dev_err_probe() to where it belogs [ Upstream commit 9e0cace7a6254070159ebd86497eadc29ea307ca ] dev_err_probe() belongs to the printing API, hence move the definition from device.h to dev_printk.h. There is no change to the callers at all, since: 1) implementation is located in the same core.c; 2) dev_printk.h is guaranteed to be included by device.h. Signed-off-by: Andy Shevchenko Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20230721131309.16821-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 797cc011ae02 ("backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt()") Signed-off-by: Sasha Levin commit 1eab71d9e735cad332d5988421e0b620c8fc5aeb Author: Greg Kroah-Hartman Date: Fri Mar 24 13:27:06 2023 +0100 driver core: device.h: remove extern from function prototypes [ Upstream commit f43243c66e5e9ad839d235f82a58e73a7e7612af ] The kernel coding style does not require 'extern' in function prototypes in .h files, so remove them from include/linux/device.h as they are not needed. Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20230324122711.2664537-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 797cc011ae02 ("backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt()") Signed-off-by: Sasha Levin commit 87187fe0b9267d7c2972d49f015990498d9b8a98 Author: Billy Tsai Date: Tue Apr 7 16:53:23 2026 +0800 i3c: mipi-i3c-hci: fix IBI payload length calculation for final status [ Upstream commit d35a6db887eeae7c57b719521e39d64f929c6dc3 ] In DMA mode, the IBI status descriptor encodes the payload using CHUNKS (number of chunks) and DATA_LENGTH (valid bytes in the last chunk). All preceding chunks are implicitly full-sized. The current code accumulates full chunk sizes for non-final status descriptors, but for the final status descriptor it only adds DATA_LENGTH. This ignores the contribution of the preceding full chunks described by the same final status entry. As a result, the computed IBI payload length is truncated whenever the final status spans multiple chunks. For example, with a chunk size of 4 bytes, CHUNKS=2 and DATA_LENGTH=1 should result in a total payload size of 5 bytes, but the current code reports only 1 byte. Fix the calculation by adding the size of (CHUNKS - 1) full chunks plus DATA_LENGTH for the last chunk. Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407-i3c-hci-dma-v2-1-a583187b9d22@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8d17a3eab8633646d705f77a499e2b51d23e802a Author: Arnaldo Carvalho de Melo Date: Wed Apr 8 14:31:57 2026 -0300 perf util: Kill die() prototype, dead for a long time [ Upstream commit e5cce1b9c82fbd48e2f1f7a25a9fad8ee228176f ] In fef2a735167a827a ("perf tools: Kill die()") the die() function was removed, but not the prototype in util.h, now when building with LIBPERL=1, during a 'make -C tools/perf build-test' routine test, it is failing as perl likes die() calls and then this clashes with this remnant, remove it. Fixes: fef2a735167a827a ("perf tools: Kill die()") Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 112d7c9d915ddf33c14ce7ee40cdd4368f618791 Author: Leo Yan Date: Thu Apr 2 17:04:47 2026 +0100 perf expr: Return -EINVAL for syntax error in expr__find_ids() [ Upstream commit 3a61fd866ef9aaa1d3158b460f852b74a2df07f4 ] expr__find_ids() propagates the parser return value directly. For syntax errors, the parser can return a positive value, but callers treat it as success, e.g., for below case on Arm64 platform: metric expr 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) for backend_bound parsing metric: 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) Failure to read '#slots' literal: #slots = nan syntax error Convert positive parser returns in expr__find_ids() to -EINVAL, as a result, the error value will be respected by callers. Before: perf stat -C 5 Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Segmentation fault After: perf stat -C 5 Failure to read '#slots'Cannot find metric or group `Default' Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap") Signed-off-by: Leo Yan Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7585a711e16e29e2599fc3447da3aecbb85a4cdc Author: Yu-Chun Lin Date: Fri Mar 20 23:15:06 2026 +0800 pinctrl: abx500: Fix type of 'argument' variable [ Upstream commit 34006f77890d050e6d80cbee365b5d703c1140b4 ] The argument variable is assigned the return value of pinconf_to_config_argument(), which returns a u32. Change its type from enum pin_config_param to unsigned int to correctly store the configuration argument. Fixes: 03b054e9696c ("pinctrl: Pass all configs to driver on pin_config_set()") Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 42830a04888f8d75cf7531b28b7d6bcbb00660ed Author: Mike Leach Date: Wed Mar 18 10:36:39 2026 +0000 perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE trace [ Upstream commit 6c478e7b3eba3f387a2d6c749e3e3ee0f8ad1c53 ] Building perf with CORESIGHT=1 and the optional CSTRACE_RAW=1 enables additional debug printing of raw trace data when using command:- perf report --dump. This raw trace prints the CoreSight formatted trace frames, which may be used to investigate suspected issues with trace quality / corruption / decode. These frames are not present in ETE + TRBE trace. This fix removes the unnecessary call to print these frames. This fix also rationalises implementation - original code had helper function that unnecessarily repeated initialisation calls that had already been made. Due to an addtional fault with the OpenCSD library, this call when ETE/TRBE are being decoded will cause a segfault in perf. This fix also prevents that problem for perf using older (<= 1.8.0 version) OpenCSD libraries. Fixes: 68ffe3902898 ("perf tools: Add decoder mechanic to support dumping trace data") Reported-by: Leo Yan Signed-off-by: Mike Leach Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3c7e561f30f956b570c16925555cea0de54b8b7e Author: Ian Rogers Date: Thu Mar 12 15:31:31 2026 -0700 perf branch: Avoid incrementing NULL [ Upstream commit c969a9d7bbf46f983c4a48566b3b2f7340b02296 ] If the entry is NULL the value is meaningless so early return NULL to avoid an increment of NULL. This was happening in calls from has_stitched_lbr when running the "perf record LBR tests". The return value isn't used in that case, so returning NULL as no effect. Fixes: 42bbabed09ce ("perf tools: Add hw_idx in struct branch_stack") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 050274abaafa36e09fb2d2bcbabb880f8bf098a3 Author: Andy Shevchenko Date: Fri Feb 27 17:43:35 2026 +0100 pinctrl: cy8c95x0: Avoid returning positive values to user space [ Upstream commit 5ad32c3607cf241a1a2680cabd64cbcd757227aa ] When probe fails due to unclear interrupt status register, it returns a positive number instead of the proper error code. Fix this accordingly. Fixes: e6cbbe42944d ("pinctrl: Add Cypress cy8c95x0 support") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202602271847.vVWkqLBD-lkp@intel.com/ Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bce936b5d6c29ae66e98a5690a7684873343d1af Author: Andy Shevchenko Date: Mon Feb 23 19:06:54 2026 +0100 pinctrl: cy8c95x0: Unify messages with help of dev_err_probe() [ Upstream commit 014884732095b982412d13d3220c3fe8483b9b3e ] Unify error messages that might appear during probe phase by switching to use dev_err_probe(). Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit 347c7039a110281e38aaef46b403076adcae8fbf Author: Andy Shevchenko Date: Mon Feb 23 19:06:53 2026 +0100 pinctrl: cy8c95x0: remove duplicate error message [ Upstream commit 970dacb3b9f0fedbbbcfd7dbf1f4f22340b3f359 ] The pin control core is covered to report any error via message. The devm_request_threaded_irq() already prints an error message. Remove the duplicates. While at it, drop the info message as the same information about an IRQ in use can be retrieved differently. Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit f75074c425273ba29b1d1b7ce3a98efd27031050 Author: Ethan Tidmore Date: Fri Feb 27 15:56:23 2026 -0600 pinctrl: pinctrl-pic32: Fix resource leak [ Upstream commit fe5560688f3ba98364c7de7b4f8dc240ffd1ff75 ] Fix three possible resource leaks by using the devres version of clk_prepare_enable(). Also, update error message accordingly. Detected by Smatch: drivers/pinctrl/pinctrl-pic32.c:2211 pic32_pinctrl_probe() warn: 'pctl->clk' from clk_prepare_enable() not released on lines: 2208. drivers/pinctrl/pinctrl-pic32.c:2274 pic32_gpio_probe() warn: 'bank->clk' from clk_prepare_enable() not released on lines: 2264,2272. Fixes: 2ba384e6c3810 ("pinctrl: pinctrl-pic32: Add PIC32 pin control driver") Signed-off-by: Ethan Tidmore Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ddb34492827af2754c1165d4db59a774396fbd00 Author: Puranjay Mohan Date: Fri Apr 17 07:33:52 2026 -0700 bpf, arm32: Reject BPF-to-BPF calls and callbacks in the JIT [ Upstream commit e1d486445af3c392628532229f7ce5f5cf7891b6 ] The ARM32 BPF JIT does not support BPF-to-BPF function calls (BPF_PSEUDO_CALL) or callbacks (BPF_PSEUDO_FUNC), but it does not reject them either. When a program with subprograms is loaded (e.g. libxdp's XDP dispatcher uses __noinline__ subprograms, or any program using callbacks like bpf_loop or bpf_for_each_map_elem), the verifier invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each subprogram. For BPF_PSEUDO_CALL, since ARM32 does not reject it, the JIT silently emits code using the wrong address computation: func = __bpf_call_base + imm where imm is a pc-relative subprogram offset, producing a bogus function pointer. For BPF_PSEUDO_FUNC, the ldimm64 handler ignores src_reg and loads the immediate as a normal 64-bit value without error. In both cases, build_body() reports success and a JIT image is allocated. ARM32 lacks the jit_data/extra_pass mechanism needed for the second JIT pass in bpf_jit_subprogs(). On the second pass, bpf_int_jit_compile() performs a full fresh compilation, allocating a new JIT binary and overwriting prog->bpf_func. The first allocation is never freed. bpf_jit_subprogs() then detects the function pointer changed and aborts with -ENOTSUPP, but the original JIT binary has already been leaked. Each program load/unload cycle leaks one JIT binary allocation, as reported by kmemleak: unreferenced object 0xbf0a1000 (size 4096): backtrace: bpf_jit_binary_alloc+0x64/0xfc bpf_int_jit_compile+0x14c/0x348 bpf_jit_subprogs+0x4fc/0xa60 Fix this by rejecting both BPF_PSEUDO_CALL in the BPF_CALL handler and BPF_PSEUDO_FUNC in the BPF_LD_IMM64 handler, falling through to the existing 'notyet' path. This causes build_body() to fail before any JIT binary is allocated, so bpf_int_jit_compile() returns the original program unjitted. bpf_jit_subprogs() then sees !prog->jited and cleanly falls back to the interpreter with no leak. Acked-by: Daniel Borkmann Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs") Reported-by: Jonas Rebmann Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de Tested-by: Jonas Rebmann Signed-off-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260417143353.838911-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8e50981d7dcb708e696ff380982968e14b94920c Author: Yihan Ding Date: Thu Apr 16 20:01:41 2026 +0800 bpf: allow UTF-8 literals in bpf_bprintf_prepare() [ Upstream commit b960430ea8862ef37ce53c8bf74a8dc79d3f2404 ] bpf_bprintf_prepare() only needs ASCII parsing for conversion specifiers. Plain text can safely carry bytes >= 0x80, so allow UTF-8 literals outside '%' sequences while keeping ASCII control bytes rejected and format specifiers ASCII-only. This keeps existing parsing rules for format directives unchanged, while allowing helpers such as bpf_trace_printk() to emit UTF-8 literal text. Update test_snprintf_negative() in the same commit so selftests keep matching the new plain-text vs format-specifier split during bisection. Fixes: 48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf") Signed-off-by: Yihan Ding Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260416120142.1420646-2-dingyihan@uniontech.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 69e72d836536233d0b3d3c3694af19e4dc6e7245 Author: Daniel Borkmann Date: Thu Apr 16 14:27:19 2026 +0200 bpf: Fix precedence bug in convert_bpf_ld_abs alignment check [ Upstream commit e5f635edd393aeaa7cad9e42831d397e6e2e1eed ] Fix an operator precedence issue in convert_bpf_ld_abs() where the expression offset + ip_align % size evaluates as offset + (ip_align % size) due to % having higher precedence than +. That latter evaluation does not make any sense. The intended check is (offset + ip_align) % size == 0 to verify that the packet load offset is properly aligned for direct access. With NET_IP_ALIGN == 2, the bug causes the inline fast-path for direct packet loads to almost never be taken on !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS platforms. This forces nearly all cBPF BPF_LD_ABS packet loads through the bpf_skb_load_helper slow path on the affected archs. Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260416122719.661033-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c6f4015eac2e3cbc3cb7a17539e10bbb5c2049c3 Author: Michal Luczaj Date: Tue Apr 14 16:13:19 2026 +0200 bpf, sockmap: Take state lock for af_unix iter [ Upstream commit 64c2f93fc3254d3bf5de4445fb732ee5c451edb6 ] When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-5-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4 Author: Michal Luczaj Date: Tue Apr 14 16:13:18 2026 +0200 bpf, sockmap: Fix af_unix null-ptr-deref in proto update [ Upstream commit dca38b7734d2ea00af4818ff3ae836fab33d5d5a ] unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; CPU1 close ---------- skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) // use after free? sock_hold(sk_pair) 2.1 BPF program invoking helper function bpf_sock_map_update() -> BPF_CALL_4(bpf_sock_map_update(), ...) Helper limited to BPF_PROG_TYPE_SOCK_OPS. Nevertheless, a unix sock might be accessible via bpf_map_lookup_elem(). Which implies sk already having psock, which in turn implies sk already having sk_pair. Since sk_psock_destroy() is queued as RCU work, sk_pair won't go away while BPF executes the update. 2.2 BPF program invoking helper function bpf_map_update_elem() -> sock_map_update_elem() 2.2.1 Unix sock accessible to BPF prog only via sockmap lookup in BPF_PROG_TYPE_SOCKET_FILTER, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SK_REUSEPORT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_SK_LOOKUP. Pretty much the same as case 2.1. 2.2.2 Unix sock accessible to BPF program directly: BPF_PROG_TYPE_TRACING, narrowed down to BPF_TRACE_ITER. Sockmap iterator (sock_map_seq_ops) is safe: unix sock residing in a sockmap means that the sock already went through the proto update step. Unix sock iterator (bpf_iter_unix_seq_ops), on the other hand, gives access to socks that may still be unconnected. Which means iterator prog can race sockmap/proto update against connect(). BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x253/0x4d0 Write of size 4 at addr 0000000000000080 by task test_progs/3140 Call Trace: dump_stack_lvl+0x5d/0x80 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x253/0x4d0 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e While the introduced NULL check prevents null-ptr-deref in the BPF program path as well, it is insufficient to guard against a poorly timed close() leading to a use-after-free. This will be addressed in a subsequent patch. Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Closes: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ Reported-by: Michal Luczaj Reported-by: 钱一铭 Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-4-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit bd3592129f24243713673a07225cf1f15a9bb835 Author: Michal Luczaj Date: Tue Apr 14 16:13:16 2026 +0200 bpf, sockmap: Fix af_unix iter deadlock [ Upstream commit 4d328dd695383224aa750ddee6b4ad40c0f8d205 ] bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-2-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit a5dfeb3b61065039488342d43ae06d4729d955d4 Author: Daniel Borkmann Date: Wed Apr 15 14:14:03 2026 +0200 bpf, arm64: Fix off-by-one in check_imm signed range check [ Upstream commit 1dd8be4ec722ce54e4cace59f3a4ba658111b3ec ] check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced. Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260415121403.639619-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit eeceb6f4dd42065fdda3a526a93d08b8fb90fb69 Author: Oliver Neukum Date: Tue Mar 24 15:24:54 2026 +0100 HID: usbhid: fix deadlock in hid_post_reset() [ Upstream commit 8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72 ] You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset") Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 13cc3d501d3146d5c42d301b4e568ba33c23cdb1 Author: Richard Genoud Date: Tue Mar 17 15:24:30 2026 +0100 mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob [ Upstream commit 848c13996c55fe4ea6bf5acc3ce6c8c5c944b5f6 ] When dumping the OOB, the bytes at the end where actually copied from the beginning of the OOB instead of current_offset. That leads to something like: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b instead of: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff (example with BCH16, user data [8,0], no scrambling) *cur_off (offset from the beginning of the page) was compared to offset (offset from the beginning of the OOB), and then, the nand_change_read_column_op() sets the current position to the beginning of the OOB instead of OOB+offset Fixes: 15d6f118285f ("mtd: rawnand: sunxi: Stop supporting ECC_HW_SYNDROME mode") Reviewed-by: Jernej Skrabec Signed-off-by: Richard Genoud Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 9da63c9838989e9e1b12aa85f3fd62e0adfe34b5 Author: Cosmin Tanislav Date: Wed Mar 11 17:39:57 2026 +0200 mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions [ Upstream commit e882626c1747653f1f01ea9d12e278e613b11d0f ] In order to parse sub-partitions, add_mtd_partitions() calls parse_mtd_partitions() for all previously found partitions. Each partition will end up being passed to parse_fixed_partitions(), and its of_node will be treated as the ofpart_node. Commit 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") added of_node_put() calls for ofpart_node on all exit paths. In the case where the partition passed to parse_fixed_partitions() has a parent, it is treated as a dedicated partitions node, and of_node_put() is wrongly called for it, even if of_node_get() was not called explicitly. On repeated bind / unbinds of the MTD, the extra of_node_put() ends up decrementing the refcount down to 0, which should never happen, resulting in the following error: OF: ERROR: of_node_release() detected bad of_node_put() on /soc/spi@80007000/flash@0/partitions/partition@0 Call of_node_get() to balance the call to of_node_put() done for dedicated partitions nodes. Fixes: 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 62d29c2f0fcbdb3c37af44249709c3e75f58d81f Author: Cosmin Tanislav Date: Wed Mar 11 17:39:56 2026 +0200 mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path [ Upstream commit 0c87dea1aab86116211cb37387c404c9e9231c39 ] ofpart_none can only be reached after the for_each_child_of_node() loop finishes. for_each_child_of_node() correctly calls of_node_put() for all device nodes it iterates over as long as we don't break or jump out of the loop. Calling of_node_put() inside the ofpart_none path will wrongly decrement the ref count of the last node in the for_each_child_of_node() loop. Move the call to of_node_put() under the ofpart_fail label to fix this. Fixes: ebd5a74db74e ("mtd: ofpart: Check availability of reg property instead of name property") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit cfd08a8e5e0fcad39ebd633554cb67347966382c Author: Shiji Yang Date: Wed Jan 28 20:42:56 2026 +0800 mtd: spi-nor: swp: check SR_TB flag when getting tb_mask [ Upstream commit 94645aa41bf9ecb87c2ce78b1c3405bfb6074a37 ] When the chip does not support top/bottom block protect, the tb_mask must be set to 0, otherwise SR1 bit5 will be unexpectedly modified. Signed-off-by: Shiji Yang Fixes: 3dd8012a8eeb ("mtd: spi-nor: add TB (Top/Bottom) protect support") Reviewed-by: Michael Walle Reviewed-by: Miquel Raynal Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit be4cb47833aa60a893ae16e0d8f2d8070da9356d Author: Jonas Gorski Date: Thu Dec 18 10:54:30 2025 +0100 mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation [ Upstream commit 3620d67b48493c6252bbc873dc88dde81641d56b ] After commit 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") spi_nor_post_sfdp_fixups() isn't called anymore if no SFDP is detected. Update the documentation accordingly. Fixes: 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") Signed-off-by: Jonas Gorski Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 004308b541f3abaae849bedb4c398d301c6e334d Author: Takahiro Kuwano Date: Wed Nov 5 16:47:59 2025 +0900 mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook [ Upstream commit f74de390557bf2bcc5dca4a357b41c0701d3f76e ] Certain chips have inconsistent Sector Map Parameter Table (SMPT) data, which leads to the wrong map ID being identified, causing failures to detect the correct sector map. To fix this, introduce smpt_map_id() into the struct spi_nor_fixups. This function will be called after the initial SMPT-based detection, allowing chip-specific logic to correct the map ID. Infineon S25FS512S needs this fixup as it has inconsistency between map ID definition and configuration register value actually obtained. Co-developed-by: Marek Vasut Signed-off-by: Marek Vasut Reviewed-by: Tudor Ambarus Tested-by: Marek Vasut # S25FS512S Signed-off-by: Takahiro Kuwano Reviewed-by: Tudor Ambarus > Signed-off-by: Pratyush Yadav Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 677ae4baeec32b760a6acdc1183f4cb430ea154c Author: Takahiro Kuwano Date: Wed Nov 5 16:47:58 2025 +0900 mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook [ Upstream commit 653f6def567c81f37302f9591ffd54df3e2a11eb ] SMPT contains config detection info that describes opcode, address, and dummy cycles to read sector map config. The dummy cycles parameter can be SMPT_CMD_READ_DUMMY_IS_VARIABLE and in that case nor->read_dummy (initialized as 0) is used. In Infineon flash chips, Read Any Register command with variable dummy cycle is defined in SMPT. S25Hx/S28Hx flash has 0 dummy cycle by default to read volatile regiters and nor->read_dummy can work. S25FS-S flash has 8 dummy cycles so we need a hook that can fix dummy cycles with actually used value. Inroduce smpt_read_dummy() in struct spi_nor_fixups. It is called when the dummy cycle field in SMPT config detection is 'varialble'. Reviewed-by: Tudor Ambarus Tested-by: Marek Vasut # S25FS512S Signed-off-by: Takahiro Kuwano Signed-off-by: Pratyush Yadav Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 9457f2bd55ca6c454967db92c374bf107494abaa Author: Tudor Ambarus Date: Fri Apr 7 15:40:58 2023 +0900 mtd: spi-nor: Allow post_sfdp hook to return errors [ Upstream commit e570f7872a34dc290014c80c7bad365d6577836b ] Multi die flashes like s25hl02gt need to determine the page_size at run-time by querying a configuration register for each die. Since the number of dice is determined in an optional SFDP table, SCCR MC, the page size configuration must be done in the post_sfdp hook. Allow post_sfdp to return errors, as reading the configuration register might return errors. Link: https://lore.kernel.org/r/924ab710f128448ec62537cfbb377336e390043c.1680849425.git.Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit b60fba92f0aec43651dce9847c89f70d211b8d28 Author: Takahiro Kuwano Date: Thu Mar 2 16:35:07 2023 +0900 mtd: spi-nor: spansion: Add support for Infineon S25FS256T [ Upstream commit 6afcc84080c415df81765c6d773edcba8fc30f6c ] Infineon S25FS256T is 256Mbit Quad SPI NOR flash. The key features and differences comparing to other Spansion/Cypress flash familes are: - 4-byte address mode by factory default - Quad mode is enabled by factory default - OP_READ_FAST_4B(0Ch) is not supported - Supports mixture of 128KB and 64KB sectors by OTP configuration (this patch supports uniform 128KB only due to complexity of non-uniform layout) Tested on Xilinx Zynq-7000 FPGA board. Link: https://www.infineon.com/dgdlac/Infineon-S25FS256T_256Mb_SEMPER_Nano_Flash_Quad_SPI_1.8V-DataSheet-v12_00-EN.pdf?fileId=8ac78c8c80027ecd0180740c5a46707a Signed-off-by: Takahiro Kuwano Link: https://lore.kernel.org/r/097ef04484966593ba1326d0a99462753d7d1073.1677557525.git.Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 153dfdeba55a6fc0fed2f152420d45a4e0f31238 Author: Takahiro Kuwano Date: Thu Mar 2 16:35:06 2023 +0900 mtd: spi-nor: spansion: Make RD_ANY_REG_OP macro take number of dummy bytes [ Upstream commit d628783c46d3c317deb0671ceb986be358fbaf69 ] Currently Read Any Register op is used to read volatile registers without any dummy cycles, but the op requires dummy cycles depending on register type (volatiler or non-volatile), device family, and device configuration. Add 'ndummy' argument to RD_ANY_REG_OP macro to support other use cases. Suggested-by: Tudor Ambarus Signed-off-by: Takahiro Kuwano Link: https://lore.kernel.org/r/03756e9e3ac41d2016a71d2afb702398dd0b19ed.1677557525.git.Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 6d610030924358c1e283c77592bd6ffd76601509 Author: Tudor Ambarus Date: Thu Jul 28 07:14:50 2022 +0300 mtd: spi-nor: spansion: Replace hardcoded values for addr_nbytes/addr_mode_nbytes [ Upstream commit 05ebc1ccb8affcbaaa9f8b8fe56839cbfc9b9144 ] We track in the core the internal address mode of the flash. Stop using hardcoded values for the number of bytes of address and use nor->addr_nbytes and nor->params->addr_mode_nbytes instead. Signed-off-by: Tudor Ambarus Tested-by: Takahiro Kuwano Link: https://lore.kernel.org/r/20220728041451.85559-2-tudor.ambarus@microchip.com Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 293fe83ca577125b0ab755fd3ba59583bc124581 Author: Takahiro Kuwano Date: Wed Aug 31 13:59:05 2022 +0900 mtd: spi-nor: spansion: Rename s28hs512t prefix [ Upstream commit 06051322704bf38cbd721e14bdbd6e43c8e6d7e1 ] Change prefix to support all other devices in SEMPER S28 family. Signed-off-by: Takahiro Kuwano Signed-off-by: Tudor Ambarus Reviewed-by: Michael Walle Link: https://lore.kernel.org/r/8cf6bc9bffd50e486867c0817de1fa56c5d308ec.1661915569.git.Takahiro.Kuwano@infineon.com Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit f7e831e633436cdff7ea760322e71e66e6dac1a5 Author: Haibo Chen Date: Mon Dec 8 17:14:14 2025 +0800 mtd: spi-nor: core: correct the op.dummy.nbytes when check read operations [ Upstream commit 756564a536ecd8c9d33edd89f0647a91a0b03587 ] When check read operation, need to setting the op.dummy.nbytes based on current read operation rather than the nor->read_proto. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Haibo Chen Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 2e347e6d651de1052329215ee0497d2cb4897874 Author: Chen Ni Date: Fri Feb 27 09:43:36 2026 +0800 mtd: physmap_of_gemini: Fix disabled pinctrl state check [ Upstream commit b7c0982184b0661f5b1b805f3a56f1bd3757b63e ] The condition for checking the disabled pinctrl state incorrectly checks gf->enabled_state instead of gf->disabled_state. This causes misleading error messages and could lead to incorrect behavior when only one of the pinctrl states is defined. Fix the condition to properly check gf->disabled_state. Fixes: 9d3b5086f6d4 ("mtd: physmap_of_gemini: Handle pin control") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 20132a977123950d65aaa02ad01c0155d27dd7c0 Author: Denis Benato Date: Sat Feb 28 20:10:09 2026 +0100 HID: asus: do not abort probe when not necessary [ Upstream commit 7253091766ded0fd81fe8d8be9b8b835495b06e8 ] In order to avoid dereferencing a NULL pointer asus_probe is aborted early and control of some asus devices is transferred over hid-generic after erroring out even when such NULL dereference cannot happen: only early abort when the NULL dereference can happen. Also make the code shorter and more adherent to coding standards removing square brackets enclosing single-line if-else statements. Fixes: d3af6ca9a8c3 ("HID: asus: fix UAF via HID_CLAIMED_INPUT validation") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e42f00da78923cd4b1a7b5aa1d7138744a0f5ea8 Author: Denis Benato Date: Sat Feb 28 20:10:07 2026 +0100 HID: asus: make asus_resume adhere to linux kernel coding standards [ Upstream commit 51d33b42b8ae23da92819d28439fdd5636c45186 ] Linux kernel coding standars requires functions opening brackets to be in a newline: move the opening bracket of asus_resume in its own line. Fixes: 546edbd26cff ("HID: hid-asus: reset the backlight brightness level on resume") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit fbc07bea2b47fd7ecf2ce9ba7147d1da9459d0f2 Author: Daniel Hodges Date: Sat Jan 31 18:40:15 2026 -0800 ima: check return value of crypto_shash_final() in boot aggregate [ Upstream commit 870819434c8dfcc3158033b66e7851b81bb17e21 ] The return value of crypto_shash_final() is not checked in ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the function returns success and a corrupted boot aggregate digest could be used for IMA measurements. Capture the return value and propagate any error to the caller. Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash") Signed-off-by: Daniel Hodges Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e5c223f46c2e0691461dd97510c15e1f77148872 Author: Pengpeng Hou Date: Wed Apr 1 19:22:23 2026 +0800 tracing: Rebuild full_name on each hist_field_name() call [ Upstream commit 5ec1d1e97de134beed3a5b08235a60fc1c51af96 ] hist_field_name() uses a static MAX_FILTER_STR_VAL buffer for fully qualified variable-reference names, but it currently appends into that buffer with strcat() without rebuilding it first. As a result, repeated calls append a new "system.event.field" name onto the previous one, which can eventually run past the end of full_name. Build the name with snprintf() on each call and return NULL if the fully qualified name does not fit in MAX_FILTER_STR_VAL. Link: https://patch.msgid.link/20260401112224.85582-1-pengpeng@iscas.ac.cn Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanussi Tested-by: Tom Zanussi Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 37c1920f1cfd9d6c9b5ce075caa11aa9e8c4bee6 Author: Frank Li Date: Wed Feb 25 16:41:38 2026 -0500 dmaengine: mxs-dma: Fix missing return value from of_dma_controller_register() [ Upstream commit ab2bf6d4c0a0152907b18d25c1b118ea5ea779df ] Propagate the return value of of_dma_controller_register() in probe() instead of ignoring it. Fixes: a580b8c5429a6 ("dmaengine: mxs-dma: add dma support for i.MX23/28") Signed-off-by: Frank Li Link: https://patch.msgid.link/20260225-mxsdma-module-v3-2-8f798b13baa6@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8cd48ca82ebd9a8a66cfba490e4f0764ffbea8d5 Author: Cole Leavitt Date: Wed Feb 18 11:02:10 2026 -0700 soundwire: bus: demote UNATTACHED state warnings to dev_dbg() [ Upstream commit 2c96956fe764f8224f9ec93b2a9160a578949a7a ] The dev_warn() messages in sdw_handle_slave_status() for UNATTACHED transitions were added in commit d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") to debug attachment failures with dynamic debug enabled. These warnings fire during normal operation -- for example when a codec driver triggers a hardware reset after firmware download, causing the device to momentarily go UNATTACHED before re-attaching -- producing misleading noise on every boot. Demote the messages to dev_dbg() so they remain available via dynamic debug for diagnosing real attachment failures without alarming users during expected initialization sequences. Fixes: d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") Signed-off-by: Cole Leavitt Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260218180210.9263-1-cole@unwrap.rs Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4f1f8df7619cf8c66e0ed3d542d843f83850509c Author: Khairul Anuar Romli Date: Mon Feb 2 14:02:19 2026 +0800 dmaengine: dw-axi-dmac: Remove unnecessary return statement from void function [ Upstream commit 48278a72fce8a8d30efaedeb206c9c3f05c1eb3f ] checkpatch.pl --strict reports a WARNING in dw-axi-dmac-platform.c: WARNING: void function return statements are not generally useful FILE: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c According to Linux kernel coding style [Documentation/process/ coding-style.rst], explicit "return;" statements at the end of void functions are redundant and should be omitted. The function will automatically return upon reaching the closing brace, so the extra statement adds unnecessary clutter without functional benefit. This patch removes the superfluous "return;" statement in dw_axi_dma_set_hw_channel() to comply with kernel coding standards and eliminate the checkpatch warning. Fixes: 32286e279385 ("dmaengine: dw-axi-dmac: Remove free slot check algorithm in dw_axi_dma_set_hw_channel") Signed-off-by: Khairul Anuar Romli Link: https://patch.msgid.link/20260202060224.12616-4-karom.9560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 76bd722db0a92b84ccd99e03796a0b6f1ae71c31 Author: ZhengYuan Huang Date: Fri Apr 10 10:02:08 2026 +0800 ocfs2: validate group add input before caching [ Upstream commit 70b672833f4025341c11b22c7f83778a5cd611bc ] [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup. Link: https://lkml.kernel.org/r/20260410020209.3786348-1-gality369@gmail.com Fixes: 7909f2bf8353 ("[PATCH 2/2] ocfs2: Implement group add for online resize") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0998674eec138c55e9e349b9cbd9dbc5129a9cc8 Author: ZhengYuan Huang Date: Fri Apr 10 11:42:20 2026 +0800 ocfs2: validate bg_bits during freefrag scan [ Upstream commit 8f687eeed3da3012152b0f9473f578869de0cd7b ] [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer. Link: https://lkml.kernel.org/r/20260410034220.3825769-1-gality369@gmail.com Fixes: d24a10b9f8ed ("Ocfs2: Add a new code 'OCFS2_INFO_FREEFRAG' for o2info ioctl.") Signed-off-by: ZhengYuan Huang Reviewed-by: Heming Zhao Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 6f702b00b8124c5d3525f19172934544826a114d Author: ZhengYuan Huang Date: Fri Apr 10 12:03:39 2026 +0800 ocfs2: fix listxattr handling when the buffer is full [ Upstream commit d12f558e6200b3f47dbef9331ed6d115d2410e59 ] [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer. Link: https://lkml.kernel.org/r/20260410040339.3837162-1-gality369@gmail.com Fixes: 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ce6b443882a767cd5ae7b778324fa014f8ad0318 Author: Christoph Hellwig Date: Fri Mar 27 07:16:35 2026 +0100 arm64/xor: fix conflicting attributes for xor_block_template [ Upstream commit 675a0dd596e712404557286d0a883b54ee28e4f4 ] Commit 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") changes the definition to __ro_after_init instead of const, but failed to update the external declaration in xor.h. This was not found because xor-neon.c doesn't include , and can't easily do that due to current architecture of the XOR code. Link: https://lkml.kernel.org/r/20260327061704.3707577-4-hch@lst.de Fixes: 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Tested-by: Eric Biggers Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andreas Larsson Cc: Anton Ivanov Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Chris Mason Cc: Christian Borntraeger Cc: Dan Williams Cc: David S. Miller Cc: David Sterba Cc: Heiko Carstens Cc: Herbert Xu Cc: "H. Peter Anvin" Cc: Huacai Chen Cc: Ingo Molnar Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Li Nan Cc: Madhavan Srinivasan Cc: Magnus Lindholm Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Richard Henderson Cc: Richard Weinberger Cc: Russell King Cc: Song Liu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b3e1bcfba3ed017d9a97dca969e14ef60a09c1b8 Author: Aaro Koskinen Date: Fri Mar 27 19:15:10 2026 +0200 ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX [ Upstream commit 7e74b606dd39c46d4378d6f6563f560a00ab8694 ] On OMAP16XX, the UART enable bit shifts are written instead of the actual bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled; the UART gets disabled and some random bits get enabled. Fix that. Fixes: 34c86239b184 ("ARM: OMAP1: clock: Fix early UART rate issues") Signed-off-by: Aaro Koskinen Link: https://patch.msgid.link/aca7HnXZ-aCSJPW7@darkstar.musicnaut.iki.fi Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit d808da8ad004a5013f30c6515f5161851afc12db Author: Alexander Koskovich Date: Sun Mar 8 04:26:37 2026 +0000 arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP [ Upstream commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d ] This resolves the following error seen on the ASUS ROG Phone 3: cpu cpu7: Voltage update failed freq=3091200 cpu cpu7: failed to update OPP for freq=3091200 Fixes: 8e0e8016cb79 ("arm64: dts: qcom: sm8250: Add CPU opp tables") Signed-off-by: Alexander Koskovich Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ddd9a40516473237e8126d63029ea5449ff271ff Author: Alok Tiwari Date: Sun Mar 29 12:53:23 2026 -0700 soc: qcom: aoss: compare against normalized cooling state [ Upstream commit cd3c4670db3ffe997be9548c7a9db3952563cf14 ] qmp_cdev_set_cur_state() normalizes the requested state to a boolean (cdev_state = !!state). The existing early-return check compares qmp_cdev->state == state, which can be wrong if state is non-boolean (any non-zero value). Compare qmp_cdev->state against cdev_state instead, so the check matches the effective state and avoids redundant updates. Signed-off-by: Alok Tiwari Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260329195333.1478090-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit be27e05bcbc5ff2eb8bb39857fd43c5b1b827871 Author: Alok Tiwari Date: Mon Mar 30 02:51:11 2026 -0700 soc: qcom: llcc: fix v1 SB syndrome register offset [ Upstream commit 24e7625df5ce065393249b78930781be593bc381 ] The llcc_v1_edac_reg_offset table uses 0x2304c for trp_ecc_sb_err_syn0, which is inconsistent with the surrounding TRP ECC registers (0x2034x) and with llcc_v2_1_edac_reg_offset, where trp_ecc_sb_err_syn0 is 0x2034c adjacent to trp_ecc_error_status0/1 at 0x20344/0x20348. Use 0x2034c for llcc v1 so the SB syndrome register follows the expected +0x4 progression from trp_ecc_error_status1. This fixes EDAC reading the wrong register for SB syndrome reporting. Fixes: c13d7d261e36 ("soc: qcom: llcc: Pass LLCC version based register offsets to EDAC driver") Signed-off-by: Alok Tiwari Reviewed-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260330095118.2657362-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2a0673836f019e7c032acbf48d022d5ccf02a845 Author: Junrui Luo Date: Sat Mar 7 15:21:09 2026 +0800 ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison [ Upstream commit 01b61e8dda9b0fdb0d4cda43de25f4e390554d7b ] The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness. Link: https://lkml.kernel.org/r/SYBPR01MB78813DA26B50EC5E01F00566AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 1f8b91275912cd428289c1fb424bebd7ff5302bd Author: Junrui Luo Date: Sat Mar 7 15:21:08 2026 +0800 ocfs2/dlm: validate qr_numregions in dlm_match_regions() [ Upstream commit 7ab3fbb01bc6d79091bc375e5235d360cd9b78be ] Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops. Link: https://lkml.kernel.org/r/SYBPR01MB7881A334D02ACEE5E0645801AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Link: https://lkml.kernel.org/r/SYBPR01MB788166F524AD04E262E174BEAF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 297261b343371c4f0b31055d53d285138ec21565 Author: Michal Grzedzicki Date: Fri Feb 13 11:39:59 2026 -0800 unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts() failure [ Upstream commit a98621a0f187a934c115dcfe79a49520ae892111 ] When set_cred_ucounts() fails in ksys_unshare() new_nsproxy is leaked. Let's call put_nsproxy() if that happens. Link: https://lkml.kernel.org/r/20260213193959.2556730-1-mge@meta.com Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Signed-off-by: Michal Grzedzicki Reviewed-by: Andrew Morton Cc: Alexey Gladkov (Intel) Cc: Ben Segall Cc: David Hildenbrand Cc: Dietmar Eggemann Cc: Ingo Molnar Cc: Juri Lelli Cc: Kees Cook Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes (Oracle) Cc: Mel Gorman Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Valentin Schneider Cc: Vincent Guittot Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 933980f948dd921245bf0761b626e6957e16bcc3 Author: Sumit Gupta Date: Wed Jan 21 15:42:03 2026 +0530 soc/tegra: cbb: Set ERD on resume for err interrupt [ Upstream commit b6ff71c5d1d4ad858ddf6f39394d169c96689596 ] Set the Error Response Disable (ERD) bit to mask SError responses and use interrupt-based error reporting. When the ERD bit is set, inband error responses to the initiator via SError are suppressed, and fabric errors are reported via an interrupt instead. The register is set during boot but the info is lost during system suspend and needs to be set again on resume. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b5b68c15bfad274d994cf2cef8ef5242d7298de1 Author: David Heidelberg Date: Fri Mar 20 18:33:11 2026 +0100 arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered during boot [ Upstream commit 3b0dd81eea6b7a239fce456ce4545af76f1a9715 ] The regulator must be on, since it provides the display subsystem and therefore the bootloader had turned it on before Linux booted. Fixes: 77809cf74a8c ("arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)") Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260320-beryllium-booton-v2-1-931d1be21eae@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 38684f8a9f5ca69c7d3a094e55901cca2fafc12a Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:13 2026 +0200 arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit db0c5ef1abda6effdc5c85d6688fb6af2b351ae5 ] The reported problem of some non-working UHS-I speed modes on SM8450 originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards"). The tests show that the rootcause of the problem was related to an overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs"). Since then both SDR50 and SDR104 speed modes are working fine on SM8450, tested on SM8450-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s Remove the restrictions on SD card speed modes from the SM8450 platform dtsi file and enable UHS-I speed modes. Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4b25e8ffa912668d475200c1cc5e3f9676283bfa Author: Konrad Dybcio Date: Tue Mar 17 15:41:16 2026 +0100 arm64: dts: qcom: sm8450: Fix GIC_ITS range length [ Upstream commit 14044fa192c50265bc1f636108371044bbdcf7b7 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: fc8b0b9b630d ("arm64: dts: qcom: sm8450 add ITS device tree node") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-3-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 35567cb2d56cc5c3e0b0f9e034fd277071b85b56 Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:59 2026 +0200 soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available [ Upstream commit 91b59009c7d48b58dbc50fecb27f2ad20749a05a ] If OCMEM is declared in DT, it is expected that it is present and handled by the driver. The GPU driver will ignore -ENODEV error, which typically means that OCMEM isn't defined in DT. Let ocmem return -EPROBE_DEFER if it supposed to be used, but it is not probed (yet). Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-3-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4d8520912810fdc3f0b4e0457bb16c632c2c520b Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:58 2026 +0200 soc: qcom: ocmem: register reasons for probe deferrals [ Upstream commit 9dfd69cd89cd6afa4723be9098979abeef3bb8c6 ] Instead of printing messages to the dmesg, let the message be recorded as a reason for the OCMEM client deferral. Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Brian Masney Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-2-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d3a1b996336d3dc9db0ca81e220a4d9e06daefb3 Author: Krzysztof Kozlowski Date: Tue Aug 13 15:09:50 2024 +0200 soc: qcom: ocmem: use scoped device node handling to simplify error paths [ Upstream commit f4c1c19f5c0e5cf2870df91dedc6b40400fd9c8a ] Obtain the device node reference with scoped/cleanup.h to reduce error handling and make the code a bit simpler. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240813-b4-cleanup-h-of-node-put-other-v1-4-cfb67323a95c@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 9dfd69cd89cd ("soc: qcom: ocmem: register reasons for probe deferrals") Signed-off-by: Sasha Levin commit 1d90d5f9aac9031754dd6d19fd56e63605e87f3a Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:30 2026 +0900 arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count [ Upstream commit 820ed0c1a13c5fafb36232538d793f99a0986ef3 ] The gpio-ranges in the MT7986A pinctrl node were incorrectly defined, therefore, pin 100 cannot be used. Correct the range count to match the driver. Fixes: c3a064a32ed9 ("arm64: dts: mediatek: add pinctrl support for mt7986a") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit ac433dad8212fd948bebed40da50c5e901680028 Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:28 2026 +0900 arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count [ Upstream commit c4c4823c8a5baa10b8100b01f49d7c3f4a871689 ] The gpio-ranges in the MT6795 pinctrl node were incorrectly defined, therefore, GPIO196 cannot be used. Correct the range count to match the driver. Fixes: b888886a4536 ("arm64: dts: mediatek: mt6795: Add pinctrl controller node") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 34caa092c729819329c8c4fd36647d825b272912 Author: Sherry Sun Date: Thu Feb 5 15:34:53 2026 +0800 arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO (M.2 W_DISABLE1) [ Upstream commit d1e7eab6033f9885a02c4b4e8f09e34d8e9d21ab ] The current pin configuration for MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 sets the weak pull-up but does not enable the pull select field. Bit 8 in the IOMUX register must be set in order for the weak pull-up to actually take effect. Update the pinctrl setting from 0x40 to 0x140 to enable both the pull select and the weak pull-up, ensuring the line behaves as expected. Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support") Signed-off-by: Sherry Sun Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 1c1812905e7b10bc9e255b9dd604ba9f373c987c Author: Mikko Perttunen Date: Mon Jan 26 15:50:43 2026 +0900 memory: tegra30-emc: Fix dll_change check [ Upstream commit 0a93f2355cf4922ad2399dbef5ea1049fef116d4 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: e34212c75a68 ("memory: tegra: Introduce Tegra30 EMC driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-2-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 2369b1831161356e1bcb51385d3e532dc4fe2771 Author: Mikko Perttunen Date: Mon Jan 26 15:50:42 2026 +0900 memory: tegra124-emc: Fix dll_change check [ Upstream commit 9597ab9a8296ab337e6820f8a717ff621078b632 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-1-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit f0f2f9dcdeced2c671582a49a333db032d599c4f Author: Rafał Miłecki Date: Tue Feb 24 09:25:41 2026 +0100 ARM: dts: mediatek: mt7623: fix efuse fallback compatible [ Upstream commit 5978ff33cc6f0988388a2830dc5cd2ea4e81f36a ] Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: compatible: 'oneOf' conditional failed, one must be fixed: ['mediatek,mt7623-efuse', 'mediatek,mt8173-efuse'] is too long 'mediatek,mt8173-efuse' was expected 'mediatek,efuse' was expected from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: Unevaluated properties are not allowed ('compatible' was unexpected) from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# Fixes: 43c7a91b4b3a ("arm: dts: mt7623: add efuse nodes to the mt7623.dtsi file") Signed-off-by: Rafał Miłecki Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit cc2da381875d4a67026e4c8feb3dba51a2a2d1bc Author: Joshua Klinesmith Date: Mon Apr 6 22:31:12 2026 -0400 ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine [ Upstream commit 3e298897f41c61450c2e7a4f457e8b2485eb35b3 ] ksmbd_crypt_message() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash: pc : qce_skcipher_done+0x24/0x174 lr : vchan_complete+0x230/0x27c ... el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] Use the standard crypto_wait_req() pattern with crypto_req_done() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Link: https://github.com/openwrt/openwrt/issues/21822 Signed-off-by: Joshua Klinesmith Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 608e1f7bc9d171ab26c1fba288c97fc76363c27d Author: Thomas Huth Date: Fri Apr 10 17:46:37 2026 +0200 efi/capsule-loader: fix incorrect sizeof in phys array reallocation [ Upstream commit 48a428215782321b56956974f23593e40ce84b7a ] The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Thomas Huth Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 2fc4c868c9060f424fd4a7cacb0aec5082aba4de Author: Andreas Gruenbacher Date: Tue Apr 7 12:14:30 2026 +0200 gfs2: prevent NULL pointer dereference during unmount [ Upstream commit 74b4dbb946060a3233604d91859a9abd3708141d ] When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604071139.HNJiCaAi-lkp@intel.com/ Fixes: 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ca95342cb1b39062a03c115830286f0a426053d5 Author: Andreas Gruenbacher Date: Tue Mar 31 06:13:42 2026 +0200 gfs2: add some missing log locking [ Upstream commit fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8 ] Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush(). Fixes: 5e4c7632aae1c ("gfs2: Issue revokes more intelligently") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ac8a2e0d287ebf35e5d7e51e260b4e146648ba4a Author: Jan Kara Date: Fri Feb 27 14:22:16 2026 +0100 quota: Fix race of dquot_scan_active() with quota deactivation [ Upstream commit e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d ] dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it. Fixes: 869b6ea1609f ("quota: Fix slow quotaoff") Reported-by: Sam Sun Link: https://lore.kernel.org/all/CAEkJfYPTt3uP1vAYnQ5V2ZWn5O9PLhhGi5HbOcAzyP9vbXyjeg@mail.gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 82a562da22b460d627542b9697ccf0f7ad57d07e Author: Ricardo B. Marlière Date: Sat Mar 7 19:08:03 2026 -0300 ktest: Run POST_KTEST hooks on failure and cancellation [ Upstream commit bc6e165a452da909cef0efbc286e6695624db372 ] PRE_KTEST can be useful for setting up the environment and POST_KTEST to tear it down, however POST_KTEST only runs on the normal end-of-run path. It is skipped when ktest exits through dodie() or cancel_test(). Final cleanup hooks are skipped. Factor the final hook execution into run_post_ktest(), call it from the normal exit path and from the early exit paths, and guard it so the hook runs at most once. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-8-565d412f4925@suse.com Fixes: 921ed4c7208e ("ktest: Add PRE/POST_KTEST and TEST options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit a535c7962ca22617c195316538d69768848ec4a0 Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:59 2026 -0300 ktest: Honor empty per-test option overrides [ Upstream commit a2de57a3c8192dcd67cccaff6c341b93748d799b ] A per-test override can clear an inherited default option by assigning an empty value, but __set_test_option() still used option_defined() to decide whether a per-test key existed. That turned an empty per-test assignment back into "fall back to the default", so tests still could not clear inherited settings. For example: DEFAULTS (...) LOG_FILE = /tmp/ktest-empty-override.log CLEAR_LOG = 1 ADD_CONFIG = /tmp/.config TEST_START TEST_TYPE = build BUILD_TYPE = nobuild ADD_CONFIG = This would run the test with ADD_CONFIG[1] = /tmp/.config Fix by checking whether the per-test key exists before falling back. If it does exist but is empty, treat it as unset for that test and stop the fallback chain there. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-4-565d412f4925@suse.com Fixes: 22c37a9ac49d ("ktest: Allow tests to undefine default options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 92b7160b1bb6f4ca5e31499602835ccd578ca045 Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:56 2026 -0300 ktest: Avoid undef warning when WARNINGS_FILE is unset [ Upstream commit 057854f8a595160656fe77ed7bf0d2403724b915 ] check_buildlog() probes $warnings_file with -f even when WARNINGS_FILE is not configured. Perl warns about the uninitialized value and adds noise to the test log, which can hide the output we actually care about. Check that WARNINGS_FILE is defined before testing whether the file exists. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-1-565d412f4925@suse.com Fixes: 4283b169abfb ("ktest: Add make_warnings_file and process full warnings") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 72e3b0d9dc3ddcf5a0d7abe050ddfe3a809b8fbf Author: Andreas Gruenbacher Date: Mon Feb 23 12:04:05 2026 +0100 gfs2: Call unlock_new_inode before d_instantiate [ Upstream commit 2ff7cf7e0640ff071ebc5c7e3dc2df024a7c91e6 ] As Neil Brown describes in detail in the link referenced below, new inodes must be unlocked before they can be instantiated. An even better fix is to use d_instantiate_new(), which combines d_instantiate() and unlock_new_inode(). Fixes: 3d36e57ff768 ("gfs2: gfs2_create_inode rework") Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-fsdevel/177153754005.8396.8777398743501764194@noble.neil.brown.name/ Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 65ea79b029bdca8d756e3e825135f08fd19ff7b7 Author: Ming-Hung Tsai Date: Fri Apr 10 21:08:01 2026 +0800 dm cache: fix missing return in invalidate_committed's error path [ Upstream commit 8c0ee19db81f0fa1ff25fd75b22b17c0cc2acde3 ] In passthrough mode, dm-cache defers write submission until after metadata commit completes via the invalidate_committed() continuation. On commit error, invalidate_committed() calls invalidate_complete() to end the bio and free the migration struct, after which it should return immediately. The patch 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") omitted this early return, causing execution to fall through into the success path on error. This results in use-after-free on the migration struct in the subsequent calls. Fix by adding the missing return after the invalidate_complete() call. Fixes: 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dm-devel/adjMq6T5RRjv_uxM@stanley.mountain/ Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5ac43616ef4587d075190465de8e6875c0732768 Author: Cássio Gabriel Date: Fri Apr 10 00:54:32 2026 -0300 ALSA: sc6000: Keep the programmed board state in card-private data [ Upstream commit fb79bf127ac2577b4876132da6dba768018aad4c ] The driver may auto-select IRQ and DMA resources at probe time, but sc6000_init_board() still derives the SC-6000 soft configuration from the module parameter arrays. When irq=auto or dma=auto is used, the codec is created with the selected resources while the board is programmed with the unresolved values. Store the mapped ports and generated SC-6000 board configuration in card-private data, build that configuration from the live probe results instead of the raw module parameters, and keep the probe-time board programming in a shared helper. This fixes the resource-programming mismatch and leaves the driver with a stable board-state block that can be reused by suspend/resume. Fixes: c282866101bf ("ALSA: sc6000: add support for SC-6600 and SC-7000") Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260410-alsa-sc6000-pm-v1-1-4d9e95493d26@gmail.com Signed-off-by: Sasha Levin commit afbe04faccd3f47c060799615af8255ac2153412 Author: Takashi Iwai Date: Wed Aug 7 15:34:23 2024 +0200 ALSA: sc6000: Use standard print API [ Upstream commit e7c475b92043c02c3e6cd0c20e308fbb6f03ebde ] Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Some functions are changed to receive a device pointer to be passed to dev_*() calls. Reviewed-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240807133452.9424-34-tiwai@suse.de Stable-dep-of: fb79bf127ac2 ("ALSA: sc6000: Keep the programmed board state in card-private data") Signed-off-by: Sasha Levin commit 6aea4a99410615912d80a4ba0827c4e8d4a8312d Author: Pei Xiao Date: Tue Apr 7 15:26:59 2026 +0800 spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback [ Upstream commit ab00febad191d7a4400aa1c3468279fb508258d4 ] mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was missing from both probe unwind and remove-time cleanup. Add a devm cleanup action after successful registration so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failures and during device removal. Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/20263f885f1a9c9d559f95275298cd6de4b11ed5.1775546401.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 89b0990eb209ad794468290950e4c7f1ee8336df Author: Vidya Sagar Date: Wed Mar 25 00:37:50 2026 +0530 PCI: tegra194: Allow system suspend when the Endpoint link is not up [ Upstream commit c76f8eae7d4695b1176c4ea5eb93c17e16a20272 ] Host software initiates the L2 sequence. PCIe link is kept in L2 state during suspend. If Endpoint mode is enabled and the link is up, the software cannot proceed with suspend. However, when the PCIe Endpoint driver is probed, but the PCIe link is not up, Tegra can go into suspend state. So, allow system to suspend in this case. Fixes: de2bbf2b71bb ("PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP mode") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-10-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 8c22bf794c6e3042fa15532a8028872c88d1dfe6 Author: Vidya Sagar Date: Wed Mar 25 00:37:48 2026 +0530 PCI: tegra194: Disable direct speed change for Endpoint mode [ Upstream commit 976f6763f57970388bcd7118931f33f447916927 ] Pre-silicon simulation showed the controller operating in Endpoint mode initiating link speed change after completing Secondary Bus Reset. Ideally, the Root Port or the Switch Downstream Port should initiate the link speed change post SBR, not the Endpoint. So, as per the hardware team recommendation, disable direct speed change for the Endpoint mode to prevent it from initiating speed change after the physical layer link is up at Gen1, leaving speed change ownership with the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 4269e5f34e14cbcac8345e3e2b5b161aabfb5595 Author: Vidya Sagar Date: Wed Mar 25 00:37:47 2026 +0530 PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select" [ Upstream commit f62bc7917de1374dce86a852ffba8baf9cb7a56a ] The GPIO DT property "nvidia,refclk-select", to select the PCIe reference clock is optional. Use devm_gpiod_get_optional() to get it. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 96a9e303371be9d408915faee9f603e3b4aa591d Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:46 2026 +0530 PCI: tegra194: Disable PERST# IRQ only in Endpoint mode [ Upstream commit 40658a31b6e134169c648041efc84944c4c71dcd ] The PERST# GPIO interrupt is only registered when the controller is operating in Endpoint mode. In Root Port mode, the PERST# GPIO is configured as an output to control downstream devices, and no interrupt is registered for it. Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq() on pex_rst_irq, which causes issues in Root Port mode where this IRQ is not registered. Fix this by only disabling the PERST# IRQ when operating in Endpoint mode, where the interrupt is actually registered and used to detect PERST# assertion/deassertion from the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 25d8e1cefeef1812ef9b417e96c4fd3cbddee284 Author: Vidya Sagar Date: Wed Mar 25 00:37:45 2026 +0530 PCI: tegra194: Don't force the device into the D0 state before L2 [ Upstream commit 71d9f67701e1affc82d18ca88ae798c5361beddf ] As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold to assert WAKE# pin. The previous workaround that forced downstream devices to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State Power Management"; however, that spec does not explicitly require putting the device into D0 and only indicates that power removal may be initiated without transitioning to D3hot. Remove the D0 workaround so that Endpoint devices can use wake functionality (WAKE# from D3). With some Endpoints the link may not enter L2 when they remain in D3, but the Root Port continues with the usual flow after PME timeout, so there is no functional issue. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Vidya Sagar Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-5-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit fe61823aa35ecd9da02a3a69c579bad6fb036e8b Author: Manivannan Sadhasivam Date: Mon Sep 22 13:40:57 2025 +0530 PCI: tegra194: Rename 'root_bus' to 'root_port_bus' in tegra_pcie_downstream_dev_to_D0() [ Upstream commit e1bd928479fb1fa60e9034b0fdb1ab9f3fa92f33 ] In tegra_pcie_downstream_dev_to_D0(), PCI devices are transitioned to D0 state. For iterating over the devices, first the downstream bus of the Root Port is searched from the root bus. But the name of the variable that holds the Root Port downstream bus is named as 'root_bus', which is wrong. Rename the variable to 'root_port_bus'. Also, move the comment on 'bringing the devices to D0' to where the state is set exactly. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250922081057.15209-1-mani@kernel.org Stable-dep-of: 71d9f67701e1 ("PCI: tegra194: Don't force the device into the D0 state before L2") Signed-off-by: Sasha Levin commit 64c1911c7f18b716e6b8d0ae1578cdd6373e1406 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:44 2026 +0530 PCI: tegra194: Disable LTSSM after transition to Detect on surprise link down [ Upstream commit 9fa0c242f8d7acf1b124d4462d18f4023573ac1c ] After the link reaches a Detect-related LTSSM state, disable LTSSM so it does not keep toggling between Polling and Detect. Do this by polling for the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert(). Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 466711c88e695befee224f2b01e821fdc66b2629 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:43 2026 +0530 PCI: tegra194: Increase LTSSM poll time on surprise link down [ Upstream commit 74dd8efe4d6cead433162147333af989a568aac7 ] On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock -> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so the total time from L0 to Detect is ~96 ms. Increase the poll timeout to 120 ms to account for this. While at it, add LTSSM state defines for Detect-related states and use them in the poll condition. Use readl_poll_timeout() instead of readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path runs in non-atomic context. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 0ab7401559b3e733215e35a5d2b63ac4534e1c96 Author: Vidya Sagar Date: Wed Mar 25 00:37:42 2026 +0530 PCI: tegra194: Fix polling delay for L2 state [ Upstream commit adaffed907f14f954096555665ad6af2ae724d83 ] As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is polling for 10 msec with 1 usec delay which is aggressive. Use existing macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay. Since this function is used in non-atomic context only, use non-atomic poll function. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit fff83f353d05232d28ba099a3c4f4f6382a58ca7 Author: Frank Li Date: Mon Aug 21 14:48:13 2023 -0400 PCI: Add PCIE_PME_TO_L2_TIMEOUT_US L2 ready timeout value [ Upstream commit e78bd50b4078b3b2d9f85d97796b7c271e7860ca ] Add the PCIE_PME_TO_L2_TIMEOUT_US macro to define the L2 ready timeout as described in the PCI specifications. Link: https://lore.kernel.org/r/20230821184815.2167131-2-Frank.Li@nxp.com Signed-off-by: Frank Li Signed-off-by: Lorenzo Pieralisi Acked-by: Manivannan Sadhasivam Stable-dep-of: adaffed907f1 ("PCI: tegra194: Fix polling delay for L2 state") Signed-off-by: Sasha Levin commit 428f2d04006c9658f20dc62b96f0bbe9f6744a04 Author: Cássio Gabriel Date: Wed Mar 25 17:05:11 2026 -0300 ASoC: SOF: compress: return the configured codec from get_params [ Upstream commit 2c4fdd055f92a2fc8602dcd88bcea08c374b7e8b ] The SOF compressed offload path accepts codec parameters in sof_compr_set_params() and forwards them to firmware as extended data in the SOF IPC stream params message. However, sof_compr_get_params() still returns success without filling the snd_codec structure. Since the compress core allocates that structure zeroed and copies it back to userspace on success, SNDRV_COMPRESS_GET_PARAMS returns an all-zero codec description even after the stream has been configured successfully. The stale TODO in this callback conflates get_params() with capability discovery. Supported codec enumeration belongs in get_caps() and get_codec_caps(). get_params() should report the current codec settings. Cache the codec accepted by sof_compr_set_params() in the per-stream SOF compress state and return it from sof_compr_get_params(). Fixes: 6324cf901e14 ("ASoC: SOF: compr: Add compress ops implementation") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-sof-compr-get-params-v1-1-0758815f13c7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e46f81541b1bf5db45a8c7a9cbc35ffc696877dc Author: Daniel Baluta Date: Tue Jan 17 14:25:32 2023 +0200 ASoC: SOF: Add support for compress API for stream data/offset [ Upstream commit 090349a9feba3ceee3997d31d68ffe54e5b57acb ] snd_sof_pcm_stream keeps information about both PCM (snd_pcm_substream) and Compress (snd_compr_stream) streams. When PCM substream pointer is NULL this means we are dealing with a compress stream. Reviewed-by: Paul Olaru Reviewed-by: Iuliana Prodan Reviewed-by: Ranjani Sridharan Reviewed-by: Peter Ujfalusi Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20230117122533.201708-4-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Stable-dep-of: 2c4fdd055f92 ("ASoC: SOF: compress: return the configured codec from get_params") Signed-off-by: Sasha Levin commit f5c4bfbb4a8fbf89d76d37578619ec9b1051e08b Author: Daniel Baluta Date: Tue Jan 17 14:25:31 2023 +0200 ASoC: SOF: Prepare set_stream_data_offset for compress API [ Upstream commit 249f186d6b0211fc59d83db128030f2b298063a1 ] Make second parameter of set_stream_data_offset generic in order to be used for both PCM and compress streams. Current patch doesn't introduce any functional change, just prepare the code for compress support. Reviewed-by: Paul Olaru Reviewed-by: Iuliana Prodan Reviewed-by: Ranjani Sridharan Reviewed-by: Peter Ujfalusi Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20230117122533.201708-3-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Stable-dep-of: 2c4fdd055f92 ("ASoC: SOF: compress: return the configured codec from get_params") Signed-off-by: Sasha Levin commit bfb983c6f7892d39d3b4967ff05fc8bfc1b08b1f Author: Daniel Baluta Date: Tue Jan 17 14:25:30 2023 +0200 ASoC: SOF: Prepare ipc_msg_data to be used with compress API [ Upstream commit 1b905942d6cd182b7ef14e9f095178376d3847e6 ] Make second parameter of ipc_msg_data generic in order to be able to support compressed streams. This patch doesn't hold any functional change. With this case we can use ipc_msg_data, to retrieve information from DSP for both PCM/Compress API. Reviewed-by: Paul Olaru Reviewed-by: Iuliana Prodan Reviewed-by: Ranjani Sridharan Reviewed-by: Peter Ujfalusi Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20230117122533.201708-2-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Stable-dep-of: 2c4fdd055f92 ("ASoC: SOF: compress: return the configured codec from get_params") Signed-off-by: Sasha Levin commit 9cb3dc7cb30df45b2425e338665bfe0cf9374039 Author: V sujith kumar Reddy Date: Wed Nov 23 17:49:08 2022 +0530 ASoC: SOF: amd: Fix for reading position updates from stream box. [ Upstream commit aae7e412b0ec0378e392b18c50b612dae09cdb74 ] By default the position updates are read from dsp box when streambox size is not defined.if the streambox size is defined to some value then position updates can be read from the streambox. Signed-off-by: V sujith kumar Reddy Link: https://lore.kernel.org/r/20221123121911.3446224-2-vsujithkumar.reddy@amd.corp-partner.google.com Signed-off-by: Mark Brown Stable-dep-of: 2c4fdd055f92 ("ASoC: SOF: compress: return the configured codec from get_params") Signed-off-by: Sasha Levin commit 1e36f4b44ec8ad0ab0f88fb59c1167323ca7e3a8 Author: Panagiotis Petrakopoulos Date: Mon Apr 6 01:25:48 2026 +0300 ALSA: scarlett2: Add missing sentinel initializer field [ Upstream commit 2428cd6e8b6fa80c36db4652702ca0acd2ce3f08 ] A "-Wmissing-field-initializers" warning was emitted when compiling the module using the W=2 option. There is a sentinel initializer field missing in the end of scarlett2_devices[]. Tested using a Scarlett Solo 4th gen. Fixes: d98cc489029d ("ALSA: scarlett2: Move USB IDs out from device_info struct") Signed-off-by: Panagiotis Petrakopoulos Link: https://patch.msgid.link/20260405222548.8903-1-npetrakopoulos2003@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 455a562d2645cbbca0fb4c398711bd2b755a236a Author: Waiman Long Date: Wed Mar 11 16:05:26 2026 -0400 selftest: memcg: skip memcg_sock test if address family not supported [ Upstream commit 2d028f3e4bbbfd448928a8d3d2814b0b04c214f4 ] The test_memcg_sock test in memcontrol.c sets up an IPv6 socket and send data over it to consume memory and verify that memory.stat.sock and memory.current values are close. On systems where IPv6 isn't enabled or not configured to support SOCK_STREAM, the test_memcg_sock test always fails. When the socket() call fails, there is no way we can test the memory consumption and verify the above claim. I believe it is better to just skip the test in this case instead of reporting a test failure hinting that there may be something wrong with the memcg code. Link: https://lkml.kernel.org/r/20260311200526.885899-1-longman@redhat.com Fixes: 5f8f019380b8 ("selftests: cgroup/memcontrol: add basic test for socket accounting") Signed-off-by: Waiman Long Acked-by: Michal Koutný Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Koutný Cc: Mike Rapoport Cc: Muchun Song Cc: Roman Gushchin Cc: Shuah Khan Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f6691fa64b56dff3ecb5f8cd5e3cdb8d08ecda71 Author: Jane Chu Date: Mon Mar 2 13:10:15 2026 -0700 Documentation: fix a hugetlbfs reservation statement [ Upstream commit 7a197d346a44384a1a858a98ef03766840e561d4 ] Documentation/mm/hugetlbfs_reserv.rst has if (resv_needed <= (resv_huge_pages - free_huge_pages)) resv_huge_pages += resv_needed; which describes this code in gather_surplus_pages() needed = (h->resv_huge_pages + delta) - h->free_huge_pages; if (needed <= 0) { h->resv_huge_pages += delta; return 0; } which means if there are enough free hugepages to account for the new reservation, simply update the global reservation count without further action. But the description is backwards, it should be if (resv_needed <= (free_huge_pages - resv_huge_pages)) instead. Link: https://lkml.kernel.org/r/20260302201015.1824798-1-jane.chu@oracle.com Fixes: 70bc0dc578b3 ("Documentation: vm, add hugetlbfs reservation overview") Signed-off-by: Jane Chu Cc: David Hildenbrand Cc: Hillf Danton Cc: Jonathan Corbet Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cf30e1ee3697f069cde70764be667359dd79e63b Author: AnishMulay Date: Wed Feb 18 11:39:41 2026 -0500 selftests/mm: skip migration tests if NUMA is unavailable [ Upstream commit 54218f10dfbe88c8e41c744fd45a756cde60b8c4 ] Currently, the migration test asserts that numa_available() returns 0. On systems where NUMA is not available (returning -1), such as certain ARM64 configurations or single-node systems, this assertion fails and crashes the test. Update the test to check the return value of numa_available(). If it is less than 0, skip the test gracefully instead of failing. This aligns the behavior with other MM selftests (like rmap) that skip when NUMA support is missing. Link: https://lkml.kernel.org/r/20260218163941.13499-1-anishm7030@gmail.com Fixes: 0c2d08728470 ("mm: add selftests for migration entries") Signed-off-by: AnishMulay Reviewed-by: SeongJae Park Reviewed-by: Dev Jain Reviewed-by: Anshuman Khandual Tested-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit abd3c1927d33766aef39c4640880e3d2637429c2 Author: Chen-Yu Tsai Date: Tue Mar 24 17:35:41 2026 +0800 PCI: mediatek-gen3: Prevent leaking IRQ domains when IRQ not found [ Upstream commit 5573c44cb3fd01a9f62d569ae9ac870ef5f0e0ba ] In mtk_pcie_setup_irq(), the IRQ domains are allocated before the controller's IRQ is fetched. If the latter fails, the function directly returns an error, without cleaning up the allocated domains. Hence, reverse the order so that the IRQ domains are allocated after the controller's IRQ is found. This was flagged by Sashiko during a review of "[PATCH v6 0/7] PCI: mediatek-gen3: add power control support". Fixes: 814cceebba9b ("PCI: mediatek-gen3: Add INTx support") Signed-off-by: Chen-Yu Tsai Signed-off-by: Manivannan Sadhasivam Link: https://sashiko.dev/#/patchset/20260324052002.4072430-1-wenst%40chromium.org Link: https://patch.msgid.link/20260324093542.18523-1-wenst@chromium.org Signed-off-by: Sasha Levin commit 60a2666b7081168d010de4fdfee8bfd93c9ac27e Author: Gerd Bayer Date: Mon Mar 30 15:09:45 2026 +0200 PCI: Enable AtomicOps only if Root Port supports them [ Upstream commit 1ae8c4ce157037e266184064a182af9ef9af278b ] When inspecting the config space of a Connect-X physical function in an s390 system after it was initialized by the mlx5_core device driver, we found the function to be enabled to request AtomicOps despite the Root Port lacking support for completing them: 00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] Subsystem: Mellanox Technologies Device 0002 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn+ On s390 and many virtualized guests, the Endpoint is visible but the Root Port is not. In this case, pci_enable_atomic_ops_to_root() previously enabled AtomicOps in the Endpoint even though it can't tell whether the Root Port supports them as a completer. Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or the Root Port doesn't support AtomicOps. Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Reported-by: Alexander Schmidt Signed-off-by: Gerd Bayer [bhelgaas: commit log, check RP first to simplify flow] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260330-fix_pciatops-v7-2-f601818417e8@linux.ibm.com Signed-off-by: Sasha Levin commit 8e8cd78b6000c9d19db249a5a68287158f288ef3 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:08 2026 +0000 ASoC: qcom: qdsp6: topology: check widget type before accessing data [ Upstream commit d5bfdd28e0cdd45043ae6e0ac168a451d59283dc ] Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access. Fixes: 36ad9bf1d93d ("ASoC: qdsp6: audioreach: add topology support") Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d858557d6da798c6fba3cae395a058a64381c255 Author: Shengjiu Wang Date: Wed Apr 1 17:42:26 2026 +0800 ASoC: fsl_easrc: Change the type for iec958 channel status controls [ Upstream commit 47f28a5bd154a95d5aa563dde02a801bd32ddb81 ] Use the type SNDRV_CTL_ELEM_TYPE_IEC958 for iec958 channel status controls, the original type will cause mixer-test to iterate all 32bit values, which costs a lot of time. And using IEC958 type can reduce the control numbers. Also enable pm runtime before updating registers to make the regmap cache data align with the value in hardware. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-12-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7ff0d94a89d8630ec8dd55b30e91ef4c2b8d2c8f Author: Shengjiu Wang Date: Wed Apr 1 17:42:25 2026 +0800 ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits() [ Upstream commit aa21fe4a81458cf469c2615b08cbde5997dde25a ] The value type of controls "Context 0 IEC958 Bits Per Sample" should be integer, not enumerated, the issue is found by the mixer-test. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-11-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6d8648fa1cf3d18cc3e53fc0a2be47c132932095 Author: Shengjiu Wang Date: Wed Apr 1 17:42:24 2026 +0800 ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits() [ Upstream commit 00541b86fb578d4949cfdd6aff1f82d43fcf07af ] Add check of input value's range in fsl_easrc_iec958_put_bits(), otherwise the wrong value may be written from user space. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-10-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 022f7a53df6b37d304cb1e95d958fc67cd906dc4 Author: Shengjiu Wang Date: Wed Apr 1 17:42:23 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put() [ Upstream commit 64a496ba976324615b845d60739dfcdae3d57434 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-9-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4561d6960056474d37ea7fe234ab07fd8bfebbd3 Author: Shengjiu Wang Date: Wed Apr 1 17:42:22 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put() [ Upstream commit 1b61c8103c9317a9c37fe544c2d83cee1c281149 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_arc_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the arc_mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-8-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2e1ba5ce6f9edc82dfbcdfa84defee59efd4e777 Author: Shengjiu Wang Date: Wed Apr 1 17:42:21 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_quality_set() [ Upstream commit e5785093b1b45af7ee57d18619b2854a8aed073a ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_quality_set() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the quality variable. Also enable pm runtime before calling the function micfil_set_quality() to make the regmap cache data align with the value in hardware. Fixes: bea1d61d5892 ("ASoC: fsl_micfil: rework quality setting") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-7-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 93faf556230082d87f52a5a7ea288ad181fdfe31 Author: Felix Gu Date: Wed Jan 21 22:17:17 2026 +0800 pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe() [ Upstream commit c8e9b6a55702be6c6d034e973d519c52c3848415 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In imx_sc_pd_get_console_rsrc(), it does not release the reference. Fixes: 893cfb99734f ("firmware: imx: scu-pd: do not power off console domain") Signed-off-by: Felix Gu Reviewed-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ddd737993acda6e3ce16b9202c18aa959b7b6a1b Author: Felix Gu Date: Fri Jan 16 20:27:47 2026 +0800 pmdomain: ti: omap_prm: Fix a reference leak on device node [ Upstream commit 44c28e1c52764fef6dd1c1ada3a248728812e67f ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In omap_prm_domain_attach_dev, it does not release the reference. Fixes: 58cbff023bfa ("soc: ti: omap-prm: Add basic power domain support") Signed-off-by: Felix Gu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 02291d77620fe01de8b453f0a804a6ecc649070f Author: Akhil P Oommen Date: Fri Mar 27 05:43:50 2026 +0530 drm/msm/a6xx: Use barriers while updating HFI Q headers [ Upstream commit dc78b35d5ec09d1b0b8a937e6e640d2c5a030915 ] To avoid harmful compiler optimizations and IO reordering in the HW, use barriers and READ/WRITE_ONCE helpers as necessary while accessing the HFI queue index variables. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714653/ Message-ID: <20260327-a8xx-gpu-batch2-v2-1-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 35bbd623ea8ff0088686e96c4cb5ddd749c978b0 Author: Rob Clark Date: Wed Mar 25 11:41:05 2026 -0700 drm/msm/shrinker: Fix can_block() logic [ Upstream commit df0f439e3926817cf577ca6272aad68468ff7624 ] The intention here was to allow blocking if DIRECT_RECLAIM or if called from kswapd and KSWAPD_RECLAIM is set. Reported by Claude code review: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch9-20260309151119.290217-10-boris.brezillon@collabora.com/ on a panthor patch which had copied similar logic. Reported-by: Boris Brezillon Fixes: 7860d720a84c ("drm/msm: Fix build break with recent mm tree") Signed-off-by: Rob Clark Reviewed-by: Boris Brezillon Patchwork: https://patchwork.freedesktop.org/patch/714238/ Message-ID: <20260325184106.1259528-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 33ba7028166ee773cf755a4573986f3d696aea50 Author: Rob Clark Date: Wed Mar 25 11:40:42 2026 -0700 drm/msm/a6xx: Fix HLSQ register dumping [ Upstream commit c289a6db9ba6cb974f0317da142e4f665d589566 ] Fix the bitfield offset of HLSQ_READ_SEL state-type bitfield. Otherwise we are always reading TP state when we wanted SP or HLSQ state. Reported-by: Connor Abbott Suggested-by: Connor Abbott Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/714236/ Message-ID: <20260325184043.1259312-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit d2b7432a1791a7ad117f6da802168b0ce1fee6d6 Author: Lei Huang Date: Tue Mar 31 15:54:05 2026 +0800 ALSA: hda/realtek: fix code style (ERROR: else should follow close brace '}') [ Upstream commit d1888bf848ade6a9e71c7ba516fd215aa1bd8d65 ] Fix checkpatch code style errors: ERROR: else should follow close brace '}' #2300: FILE: sound/hda/codecs/realtek/alc269.c:2300: + } + else Fixes: 31278997add6 ("ALSA: hda/realtek - Add headset quirk for Dell DT") Signed-off-by: Lei Huang Link: https://patch.msgid.link/20260331075405.78148-1-huanglei814@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cd510ebee453a5b2df91270e352184382aad7411 Author: Luke D. Jones Date: Tue Jul 4 16:46:19 2023 +1200 ALSA: hda/realtek: Whitespace fix [ Upstream commit 72cea3a3175b50a4875b3c112fb13df20c6218a5 ] Remove an erroneous whitespace. Fixes: 31278997add6 ("ALSA: hda/realtek - Add headset quirk for Dell DT") Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230704044619.19343-6-luke@ljones.dev Signed-off-by: Takashi Iwai Stable-dep-of: d1888bf848ad ("ALSA: hda/realtek: fix code style (ERROR: else should follow close brace '}')") Signed-off-by: Sasha Levin commit 5b6ff0d812a03ad5004cb9df418be75307f8c357 Author: Timur Kristóf Date: Sun Mar 29 18:03:05 2026 +0200 drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board [ Upstream commit 4724bc5b8d78c34b993594f9406135408ccb312a ] On a specific Radeon R9 390X board, the GPU can "randomly" hang while gaming. Initially I thought this was a RADV bug and tried to work around this in Mesa: commit 8ea08747b86b ("radv: Mitigate GPU hang on Hawaii in Dota 2 and RotTR") However, I got some feedback from other users who are reporting that the above mitigation causes a significant performance regression for them, and they didn't experience the hang on their GPU in the first place. After some further investigation, it turns out that the problem is that the highest SCLK DPM level on this board isn't stable. Lowering SCLK to 1040 MHz (from 1070 MHz) works around the issue, and has a negligible impact on performance compared to the Mesa patch. (Note that increasing the voltage can also work around it, but we felt that lowering the SCLK is the safer option.) To solve the above issue, add an "sclk_cap" field to smu7_hwmgr and set this field for the affected board. The capped SCLK value correctly appears on the sysfs interface and shows up in GUI tools such as LACT. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3fe53c9e366a719c0fc01c551338483d96e6bcc8 Author: Timur Kristóf Date: Sun Mar 29 18:03:04 2026 +0200 drm/amd/pm/ci: Fill DW8 fields from SMC [ Upstream commit baf28ec5795c077406d6f52b8ad39e614153bce6 ] In ci_populate_dw8() we currently just read a value from the SMU and then throw it away. Instead of throwing away the value, we should use it to fill other fields in DW8 (like radeon). Otherwise the value of the other fiels is just cleared when we copy this data to the SMU later. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e052c8911926f7975f5381307e874b99641bc78c Author: Timur Kristóf Date: Sun Mar 29 18:03:03 2026 +0200 drm/amd/pm/ci: Clear EnabledForActivity field for memory levels [ Upstream commit 5facfd4c4c67e8500116ffec0d9da35d92b9c787 ] Follow what radeon did and what amdgpu does for other GPUs with SMU7. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2471880e1e41e2242f3af6525c9ee78aa901a322 Author: Timur Kristóf Date: Sun Mar 29 18:03:02 2026 +0200 drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0 [ Upstream commit d784759c07924280f3c313f205fc48eb62d7cb71 ] There is no AMD GPU with the ID 0x66B0, this looks like a typo. It should be 0x67B0 which is actually part of the PCI ID list, and should use the Hawaii XT powertune defaults according to the old radeon driver. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5ab7cfc9374767a5222f208342745b972e25ee9f Author: Timur Kristóf Date: Sun Mar 29 18:03:00 2026 +0200 drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock [ Upstream commit 0138610c14130425be53423b35336561829965e0 ] The DCE (display controller engine) requires a minimum voltage in order to function correctly, depending on which clock level it currently uses. Add a new table that contains display clock frequency levels and the corresponding required voltages. The clock frequency levels are taken from DC (and the old radeon driver's voltage dependency table for CI in cases where its values were lower). The voltage levels are taken from the following function: phm_initializa_dynamic_state_adjustment_rule_settings(). Furthermore, in case of CI, call smu7_patch_vddc() on the new table to account for leakage voltage (like in radeon). Use the display clock value from amd_pp_display_configuration to look up the voltage level needed by the DCE. Send the voltage to the SMU via the PPSMC_MSG_VddC_Request command. The previous implementation of this feature was non-functional because it relied on a "dal_power_level" field which was never assigned; and it was not at all implemented for CI ASICs. I verified this on a Radeon R9 M380 which previously booted to a black screen with DC enabled (default since Linux 6.19), but now works correctly. Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3945658dfeb2aae6ef06a2ab729a0f97dcd21e22 Author: Timur Kristóf Date: Sun Mar 29 18:02:59 2026 +0200 drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs [ Upstream commit 9851f29cb06c09f7dad3867d8b0feec3fc71b6c8 ] There are two known cases where MCLK DPM can causes issues: Radeon R9 M380 found in iMac computers from 2015. The SMU in this GPU just hangs as soon as we send it the PPSMC_MSG_MCLKDPM_Enable command, even when MCLK switching is disabled, and even when we only populate one MCLK DPM level. Apply workaround to all devices with the same subsystem ID. Radeon R7 260X due to old memory controller microcode. We only flash the MC ucode when it isn't set up by the VBIOS, therefore there is no way to make sure that it has the correct ucode version. I verified that this patch fixes the SMU hang on the R9 M380 which would previously fail to boot. This also fixes the UVD initialization error on that GPU which happened because the SMU couldn't ungate the UVD after it hung. Fixes: 86457c3b21cb ("drm/amd/powerplay: Add support for CI asics to hwmgr") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d3f76a2fd782e6dcfaec40a2be3e66b39b06ce3 Author: Timur Kristóf Date: Sun Mar 29 18:02:58 2026 +0200 drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled [ Upstream commit 894f0d34d66cb47fe718fe2ae5c18729d22c5218 ] When MCLK DPM is disabled for any reason, populate the MCLK table with the highest MCLK DPM level, so that the ASIC can use the highest possible memory clock to get good performance even when MCLK DPM is disabled. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cb609c6137f6218637f62c64ca04ad1feae6c1c4 Author: Cássio Gabriel Date: Wed Mar 25 02:24:04 2026 -0300 ALSA: core: Validate compress device numbers without dynamic minors [ Upstream commit 796e119e9b14763be905ad0d023c71a14bc2e931 ] Without CONFIG_SND_DYNAMIC_MINORS, ALSA reserves only two fixed minors for compress devices on each card: comprD0 and comprD1. snd_find_free_minor() currently computes the compress minor as type + dev without validating dev first, so device numbers greater than 1 spill into the HWDEP minor range instead of failing registration. ASoC passes rtd->id to snd_compress_new(), so this can happen on real non-dynamic-minor builds. Add a dedicated fixed-minor check for SNDRV_DEVICE_TYPE_COMPRESS in snd_find_free_minor() and reject out-of-range device numbers with -EINVAL before constructing the minor. Also remove the stale TODO in compress_offload.c that still claims multiple compress nodes are missing. Fixes: 3eafc959b32f ("ALSA: core: add support for compressed devices") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-alsa-compress-static-minors-v1-1-0628573bee1c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df4de2fcb342b661a67243dc9c0fc82c0ed4c641 Author: Sebastian Reichel Date: Tue Feb 17 16:25:26 2026 +0200 drm/panel: simple: Correct G190EAN01 prepare timing [ Upstream commit f1080f82570b797598c1ba7e9c800ae9e94aafc6 ] The prepare timing specified by the G190EAN01 datasheet should be between 30 and 50 ms. Considering it might take some time for the LVDS encoder to enable the signal, we should only wait the min. required time in the panel driver and not the max. allowed time. Fixes: 2f7b832fc992 ("drm/panel: simple: Add support for AUO G190EAN01 panel") Signed-off-by: Sebastian Reichel Signed-off-by: Ian Ray Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260217142528.68613-1-ian.ray@gehealthcare.com Signed-off-by: Sasha Levin commit f4c0258f77c1ca88d7ab2d8fe9d3c9db3f3a3ead Author: Alexander Koskovich Date: Tue Mar 24 11:48:27 2026 +0000 drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0 [ Upstream commit 913a709dea0eff9c7b2e9470f8c8594b9a0114ab ] The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was always correct just the name was wrong. Rename and reorder to maintain version sorting. Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Alexander Koskovich Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 1181a7028d37e0b1e720a36125a03f5db97e3d27 Author: Yuanjie Yang Date: Mon Mar 9 14:37:20 2026 +0800 drm/msm/dpu: fix mismatch between power and frequency [ Upstream commit bc1dccc518cc5ab5140fba06c27e7188e0ed342b ] During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") Signed-off-by: Yuanjie Yang Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/710077/ Link: https://lore.kernel.org/r/20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 7766eb7b9187dad6ca67114f1bfee498b42b98eb Author: Pei Xiao Date: Thu Mar 19 11:06:41 2026 +0800 spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo [ Upstream commit 9f61daf2c2debe9f5cf4e1a4471e56a89a6fe45a ] The hisi_spi_flush_fifo()'s inner while loop that lacks any timeout mechanism. Maybe the hardware never becomes empty, the loop will spin forever, causing the CPU to hang. Fix this by adding a inner_limit based on loops_per_jiffy. The inner loop now exits after approximately one jiffy if the FIFO remains non-empty, logs a ratelimited warning, and breaks out of the outer loop. Additionally, add a cpu_relax() inside the busy loop to improve power efficiency. Fixes: c770d8631e18 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/d834ce28172886bfaeb9c8ca00cfd9bf1c65d5a1.1773889292.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5f6d251e93f1b25572a75a6abd0424d120694b0f Author: Alex Deucher Date: Thu Feb 19 18:18:28 2026 -0500 drm/amdgpu/gfx10: look at the right prop for gfx queue priority [ Upstream commit 355d96cdec5c61fd83f7eb54f1a28e38809645d6 ] Look at hqd_queue_priority rather than hqd_pipe_priority. In practice, it didn't matter as both were always set for kernel queues, but that will change in the future. Fixes: b07d1d73b09e ("drm/amd/amdgpu: Enable high priority gfx queue") Reviewed-by：Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 65dae8b34f0810f3fa9f77c4c63650cd20820693 Author: Daniel Jordan Date: Fri Mar 13 11:24:33 2026 -0400 padata: Put CPU offline callback in ONLINE section to allow failure [ Upstream commit c8c4a2972f83c8b68ff03b43cecdb898939ff851 ] syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible. Fixes: 894c9ef9780c ("padata: validate cpumask without removed CPU during offline") Reported-by: syzbot+123e1b70473ce213f3af@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69af0a05.050a0220.310d8.002f.GAE@google.com/ Debugged-by: Thomas Gleixner Signed-off-by: Daniel Jordan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 81e8e38aad2e8e09f3c163e48dbad079650b0244 Author: Chuyi Zhou Date: Thu Feb 26 16:07:03 2026 +0800 padata: Remove cpu online check from cpu add and removal [ Upstream commit 73117ea6470dca787f70f33c001f9faf437a1c0b ] During the CPU offline process, the dying CPU is cleared from the cpu_online_mask in takedown_cpu(). After this step, various CPUHP_*_DEAD callbacks are executed to perform cleanup jobs for the dead CPU, so this cpu online check in padata_cpu_dead() is unnecessary. Similarly, when executing padata_cpu_online() during the CPUHP_AP_ONLINE_DYN phase, the CPU has already been set in the cpu_online_mask, the action even occurs earlier than the CPUHP_AP_ONLINE_IDLE stage. Remove this unnecessary cpu online check in __padata_add_cpu() and __padata_remove_cpu(). Signed-off-by: Chuyi Zhou Acked-by: Daniel Jordan Signed-off-by: Herbert Xu Stable-dep-of: c8c4a2972f83 ("padata: Put CPU offline callback in ONLINE section to allow failure") Signed-off-by: Sasha Levin commit 6005b00f47ecbc095feb14217ee8807efcdd6a8f Author: Andy Shevchenko Date: Fri Mar 20 15:36:46 2026 +0100 fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break [ Upstream commit caf6144053b4e1c815aa56afb54745a176f999df ] Clang is not happy about set but unused variable: drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used 412 | unsigned int mnp; | ^ 1 error generated. Since the commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") the 'mnp' became unused, but eliminating that code might have side-effects. The question here is what should we do with 'mnp'? The easiest way out is just mark it with __maybe_unused which will shut the compiler up and won't change any possible IO flow. So does this change. A dive into the history of the driver: The problem was revealed when the #if 0 guarded code along with unused pixel_vco variable was removed. That code was introduced in the original commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC from older DAC1064 handling. Modify PLL setting when both CRTCs use same pixel clocks."). NOTE: The two commits mentioned above pre-date Git era and available in history.git repository for archaeological purposes. Even without that guard the modern compilers may see that the pixel_vco wasn't ever used and seems a leftover after some debug or review made 25 years ago. The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem to have any side effects either than some unneeded CPU processing during runtime. I agree that's unlikely that timeout (or heating up the CPU) has any effect on the HW (GPU/display) functionality. Fixes: 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") Signed-off-by: Andy Shevchenko Reviewed-by: Jason Yan Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 62b68bb035dd18246f767017d0f2029c0e52dab8 Author: Guillaume Gonnet Date: Tue Mar 17 22:32:28 2026 +0100 dm init: ensure device probing has finished in dm-mod.waitfor= [ Upstream commit 99a2312f69805f4ba92d98a757625e0300a747ab ] The early_lookup_bdev() function returns successfully when the disk device is present but not necessarily its partitions. In this situation, dm_early_create() fails as the partition block device does not exist yet. In my case, this phenomenon occurs quite often because the device is an SD card with slow reading times, on which kernel takes time to enumerate available partitions. Fortunately, the underlying device is back to "probing" state while enumerating partitions. Waiting for all probing to end is enough to fix this issue. That's also the reason why this problem never occurs with rootwait= parameter: the while loop inside wait_for_root() explicitly waits for probing to be done and then the function calls async_synchronize_full(). These lines were omitted in 035641b, even though the commit says it's based on the rootwait logic... Anyway, calling wait_for_device_probe() after our while loop does the job (it both waits for probing and calls async_synchronize_full). Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices") Signed-off-by: Guillaume Gonnet Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 5530fabc9d64fc23260fd1192ac6eabf57266425 Author: Srinivasan Shanmugam Date: Thu Mar 12 19:29:54 2026 +0530 drm/amdgpu: Add default case in DVI mode validation [ Upstream commit e6020a55b8e364d15eac27f9c788e13114eec6b7 ] amdgpu_connector_dvi_mode_valid() assigns max_digital_pixel_clock_khz based on connector_object_id using a switch statement that lacks a default case. In practice this code path should never be hit because the existing cases already cover all digital connector types that this function is used for. This is also legacy display code which is not used for new hardware. Add a default case returning MODE_BAD to make the switch exhaustive and silence the static analyzer smatch error. The new branch is effectively defensive and should never be reached during normal operation. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Dan Carpenter Cc: Timur Kristóf Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 61d81e56fa4d6982714f4987efe28b38323ecb93 Author: Ethan Tidmore Date: Thu Feb 26 10:38:36 2026 -0600 drm/sun4i: Fix resource leaks [ Upstream commit 127367ad2e0f4870de60c6d719ae82ecf68d674c ] Three clocks are not being released in devm_regmap_init_mmio() error path. Add proper goto and set ret to the error code. Fixes: 8270249fbeaf0 ("drm/sun4i: backend: Create regmap after access is possible") Signed-off-by: Ethan Tidmore Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260226163836.10335-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit e7b6a1e480b4f12cc2e9a2fa6771fef7a3028aa9 Author: Felix Gu Date: Wed Mar 4 20:47:21 2026 +0800 spi: fsl-qspi: Use reinit_completion() for repeated operations [ Upstream commit 981b080a79724738882b0af1c5bb7ade30d94f24 ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Felix Gu Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20260304-spi-nxp-v2-3-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3ec74da927b4e171a6fc0e77b1188ba4d019af51 Author: Junrui Luo Date: Thu Mar 5 20:05:48 2026 +0800 dm log: fix out-of-bounds write due to region_count overflow [ Upstream commit c20e36b7631d83e7535877f08af8b0af72c44b1a ] The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit d1a79620c419a0af1911f99c873014b30740e303 Author: Ming-Hung Tsai Date: Wed Mar 4 19:56:28 2026 +0800 dm cache metadata: fix memory leak on metadata abort retry [ Upstream commit 044ca491d4086dc5bf233e9fcb71db52df32f633 ] When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta < unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 Fixes: 352b837a5541 ("dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 1443c32f24d6d8bcdf4beceef2afc09290b98717 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:10 2026 +0800 dm cache: fix dirty mapping checking in passthrough mode switching [ Upstream commit 322586745bd1a0e5f3559fd1635fdeb4dbd1d6b8 ] As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean. Fixes: 2ee57d587357 ("dm cache: add passthrough mode") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 1e0dcecf857ea167a84ddc15abdbb969a1a6f25d Author: Ming-Hung Tsai Date: Thu Mar 6 16:41:51 2025 +0800 dm cache: support shrinking the origin device [ Upstream commit c2662b1544cbd8ea3181381bb899b8e681dfedc7 ] This patch introduces formal support for shrinking the cache origin by reducing the cache target length via table reloads. Cache blocks mapped beyond the new target length must be clean and are invalidated during preresume. If any dirty blocks exist in the area being removed, the preresume operation fails without setting the NEEDS_CHECK flag in superblock, and the resume ioctl returns EFBIG. The cache device remains suspended until a table reload with target length that fits existing mappings is performed. Without this patch, reducing the cache target length could result in io errors (RHBZ: 2134334), out-of-bounds memory access to the discard bitset, and security concerns regarding data leakage. Verification steps: 1. create a cache metadata with some cached blocks mapped to the tail of the origin device. Here we use cache_restore v1.0 to build a metadata with one clean block mapped to the last origin block. cat <> cmeta.xml EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. bring up the cache whilst shrinking the cache origin by one block: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524160 linear /dev/sdc 262144" dmsetup create cache --table "0 524160 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 3. check the number of cached data blocks via dmsetup status. It is expected to be zero. dmsetup status cache | cut -d ' ' -f 7 In addition to the script above, this patch can be verified using the "cache/resize" tests in dmtest-python: ./dmtest run --rx cache/resize/shrink_origin --result-set default Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Stable-dep-of: 322586745bd1 ("dm cache: fix dirty mapping checking in passthrough mode switching") Signed-off-by: Sasha Levin commit b83686236da4d0fe07c4ec487d37d2a658419b7e Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:09 2026 +0800 dm cache: fix concurrent write failure in passthrough mode [ Upstream commit e4f66341779d0cf4c83c74793753a84094286d9e ] When bio prison cell lock acquisition fails due to concurrent writes to the same block in passthrough mode, dm-cache incorrectly returns an I/O error instead of properly handling the concurrency. This can occur in both process and workqueue contexts when invalidate_lock() is called for exclusive access to a data block. Fix this by deferring the write bios to ensure proper block device behavior. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently. Sometimes one of the processes will receive I/O errors. fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k fio-3.41 fio: io_u error on file /dev/mapper/cache: Input/output error: write offset=4096, buflen=4096 fio: pid=106, err=5/file:io_u.c:2008, func=io_u error, error=Input/output error test: (groupid=0, jobs=1): err= 0: pid=105 test: (groupid=0, jobs=1): err= 5 (file:io_u.c:2008, func=io_u error, error=Input/output error): pid=106 Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 9a5fdfb9e57ec3a8ad2b8fce5e5ffa42d53b130e Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:08 2026 +0800 dm cache policy smq: fix missing locks in invalidating cache blocks [ Upstream commit 2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45 ] In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 9fa18d0b981776b190ca4632942a7c2174052b78 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:07 2026 +0800 dm cache: fix write hang in passthrough mode [ Upstream commit 4ca8b8bd952df7c3ccdc68af9bd3419d0839a04b ] The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2b89993db1623ad9beff7355d1b99c165264ae7b Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:06 2026 +0800 dm cache: fix write path cache coherency in passthrough mode [ Upstream commit 0c5eef0aad508231d8e43ff8392692925e131b68 ] In passthrough mode, dm-cache defers write bio submission until cache invalidation completes to maintain existing coherency, requiring the target map function to return DM_MAPIO_SUBMITTED. The current map_bio() returns DM_MAPIO_REMAPPED, violating the required ordering constraint. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into the cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first data block, and check io ordering using ftrace echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_queue/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_complete/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_rq_complete/enable fio --filename=/dev/mapper/cache --name=test --rw=write --bs=64k \ --direct=1 --size 64k 5. ftrace logs show that write operations to the cache origin (252:2) and metadata operations (252:0) are unsynchronized: the origin write occurs before metadata commit. fio-146 [000] ..... 420.139562: block_bio_queue: 252,3 WS 0 + 128 [fio] fio-146 [000] ..... 420.149395: block_bio_queue: 252,2 WS 0 + 128 [fio] fio-146 [000] ..... 420.149763: block_bio_queue: 8,32 WS 262144 + 128 [fio] fio-146 [000] dNh1. 420.151446: block_rq_complete: 8,32 WS () 262144 + 128 be,0,4 [0] fio-146 [000] dNh1. 420.152731: block_bio_complete: 252,2 WS 0 + 128 [0] fio-146 [000] dNh1. 420.154229: block_bio_complete: 252,3 WS 0 + 128 [0] kworker/0:0-9 [000] ..... 420.160530: block_bio_queue: 252,0 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.161641: block_bio_queue: 8,32 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162533: block_bio_queue: 252,0 W 416 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162821: block_bio_queue: 8,32 W 416 + 8 [kworker/0:0] Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit c7fb6bc864c4910b344dafa36dd5028e9b980768 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:05 2026 +0800 dm cache: fix null-deref with concurrent writes in passthrough mode [ Upstream commit 7d1f98d668ee34c1d15bdc0420fdd062f24a27c0 ] In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 43b67761d486d719128e164536e58de5a81dff9b Author: Sander Vanheule Date: Fri Feb 20 16:26:34 2026 +0100 ASoC: sti: use managed regmap_field allocations [ Upstream commit 1696fad8b259a2d46e51cd6e17e4bcdbe02279fa ] The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-3-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c90b334f0203a5a26fe8ef7d2a7f31e09025e95 Author: Sander Vanheule Date: Fri Feb 20 16:26:33 2026 +0100 ASoC: sti: Return errors from regmap_field_alloc() [ Upstream commit 272aabef50bc3fe58edd26de000f4cdd41bdbe60 ] When regmap_field_alloc() fails, it can return an error. Specifically, it will return PTR_ERR(-ENOMEM) when the allocation returns a NULL pointer. The code then uses these allocations with a simple NULL check: if (player->clk_sel) { // May dereference invalid pointer (-ENOMEM) err = regmap_field_write(player->clk_sel, ...); } Ensure initialization fails by forwarding the errors from regmap_field_alloc(), thus avoiding the use of the invalid pointers. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-2-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ea51fd96aca01381e8f1ac0c671a57b7619193bb Author: Ethan Tidmore Date: Mon Feb 16 19:48:01 2026 -0600 drm/sun4i: backend: fix error pointer dereference [ Upstream commit 06277983eca4a31d3c2114fa33d99a6e82484b11 ] The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR() Fixes: 96180dde23b79 ("drm/sun4i: backend: Add a custom atomic_check for the frontend") Signed-off-by: Ethan Tidmore Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260217014801.60760-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 02ff8a7d3d0eecc546b9ab4c07b3d7c65d485583 Author: Alexander Konyukhov Date: Tue Feb 3 16:48:46 2026 +0300 drm/komeda: fix integer overflow in AFBC framebuffer size check [ Upstream commit 779ec12c85c9e4547519e3903a371a3b26a289de ] The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 65ad2392dd6d ("drm/komeda: Added AFBC support for komeda driver") Signed-off-by: Alexander Konyukhov Acked-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/r/20260203134907.1587067-1-Alexander.Konyukhov@kaspersky.com Signed-off-by: Sasha Levin commit acbf45bd584d924b320bee2a7fe2a26f64904d95 Author: Jiayuan Chen Date: Sat Apr 11 08:55:19 2026 +0800 net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master [ Upstream commit 1921f91298d1388a0bb9db8f83800c998b649cb3 ] syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected. Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave device") Reported-by: syzbot+80e046b8da2820b6ba73@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/698f84c6.a70a0220.2c38d7.00cc.GAE@google.com/T/ Suggested-by: Daniel Borkmann Acked-by: Daniel Borkmann Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260411005524.201200-2-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e2a5fe93289caf4038f16072c9180362618485e2 Author: Xin Long Date: Sun Apr 12 14:13:51 2026 -0400 sctp: fix missing encap_port propagation for GSO fragments [ Upstream commit bf6f95ae3b8b2638c0e1d6d802d50983ce5d0f45 ] encap_port in SCTP_INPUT_CB(skb) is used by sctp_vtag_verify() for SCTP-over-UDP processing. In the GSO case, it is only set on the head skb, while fragment skbs leave it 0. This results in fragment skbs seeing encap_port == 0, breaking SCTP-over-UDP connections. Fix it by propagating encap_port from the head skb cb when initializing fragment skbs in sctp_inq_pop(). Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/ea65ed61b3598d8b4940f0170b9aa1762307e6c3.1776017631.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ccd75c51f620374086f359e906917676e699a1c Author: Dudu Lu Date: Sun Apr 5 23:47:41 2026 +0800 Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp [ Upstream commit 42776497cdbc9a665b384a6dcb85f0d4bd927eab ] l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Dudu Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c7777f534a8018ae4bb1c80d8925af4df588a314 Author: Pauli Virtanen Date: Sun Mar 29 16:42:59 2026 +0300 Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER [ Upstream commit 5c7209a341ff2ac338b2b0375c34a307b37c9ac2 ] When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock. Fixes: 70c464256310 ("Bluetooth: Refactor connection request handling") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 356dee1bcac4d0d9152390561fa63331ebff211b Author: Jonathan Rissanen Date: Fri Mar 27 11:47:20 2026 +0100 Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error [ Upstream commit 68d39ea5e0adc9ecaea1ce8abd842ec972eb8718 ] When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4dddbb4fc2832e897e14ba90c15e79d8a9d21f3a Author: Luiz Augusto von Dentz Date: Mon Mar 16 14:34:13 2026 -0400 Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU [ Upstream commit 15bf35a660eb82a49f8397fc3d3acada8dae13db ] The code was printing skb->len and sdu_len in the places where it should be sdu_len and chan->imtu respectively to match the if conditions. Link: https://lore.kernel.org/linux-bluetooth/20260315132013.75ab40c5@kernel.org/T/#m1418f9c82eeff8510c1beaa21cf53af20db96c06 Fixes: e1d9a6688986 ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU") Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Signed-off-by: Sasha Levin commit e6aa481f21fc7a41ed344767ea25aae9d03fae71 Author: Sun Jian Date: Wed Apr 8 11:46:22 2026 +0800 bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb [ Upstream commit 12bec2bd4b76d81c5d3996bd14ec1b7f4d983747 ] bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers. Fixes: fa5cb548ced6 ("bpf: Setup socket family and addresses in bpf_prog_test_run_skb") Reported-by: syzbot+619b9ef527f510a57cfc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=619b9ef527f510a57cfc Signed-off-by: Sun Jian Link: https://lore.kernel.org/r/20260408034623.180320-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 67e901e28d177ac9a9bed76d69ce3471e704a89e Author: Taegu Ha Date: Thu Apr 9 16:11:15 2026 +0900 ppp: require CAP_NET_ADMIN in target netns for unattached ioctls [ Upstream commit 2bb6379416fd19f44c3423a00bfd8626259f6067 ] /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case. Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2") Signed-off-by: Taegu Ha Link: https://patch.msgid.link/20260409071117.4354-1-hataegu0826@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c244b79adffad89a5173cf8bfaa06a6b40bbd09b Author: Greg Jumper Date: Wed Apr 8 01:04:20 2026 -0700 net/rds: Restrict use of RDS/IB to the initial network namespace [ Upstream commit ebf71dd4aff46e8e421d455db3e231ba43d2fa8a ] Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces. Fixes: d5a8ac28a7ff ("RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net") Reported-by: syzbot+da8e060735ae02c8f3d1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1 Signed-off-by: Greg Jumper Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cafb57134d3acc8cb52f00b61042756d7c516ce2 Author: Håkon Bugge Date: Wed Apr 8 01:04:19 2026 -0700 net/rds: Optimize rds_ib_laddr_check [ Upstream commit 236f718ac885965fa886440b9898dfae185c9733 ] rds_ib_laddr_check() creates a CM_ID and attempts to bind the address in question to it. This in order to qualify the allegedly local address as a usable IB/RoCE address. In the field, ExaWatcher runs rds-ping to all ports in the fabric from all local ports. This using all active ToS'es. In a full rack system, we have 14 cell servers and eight db servers. Typically, 6 ToS'es are used. This implies 528 rds-ping invocations per ExaWatcher's "RDSinfo" interval. Adding to this, each rds-ping invocation creates eight sockets and binds the local address to them: socket(AF_RDS, SOCK_SEQPACKET, 0) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 4 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 5 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 6 bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 8 bind(8, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 9 bind(9, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 10 bind(10, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 So, at every interval ExaWatcher executes rds-ping's, 4224 CM_IDs are allocated, considering this full-rack system. After the a CM_ID has been allocated, rdma_bind_addr() is called, with the port number being zero. This implies that the CMA will attempt to search for an un-used ephemeral port. Simplified, the algorithm is to start at a random position in the available port space, and then if needed, iterate until an un-used port is found. The book-keeping of used ports uses the idr system, which again uses slab to allocate new struct idr_layer's. The size is 2092 bytes and slab tries to reduce the wasted space. Hence, it chooses an order:3 allocation, for which 15 idr_layer structs will fit and only 1388 bytes are wasted per the 32KiB order:3 chunk. Although this order:3 allocation seems like a good space/speed trade-off, it does not resonate well with how it used by the CMA. The combination of the randomized starting point in the port space (which has close to zero spatial locality) and the close proximity in time of the 4224 invocations of the rds-ping's, creates a memory hog for order:3 allocations. These costly allocations may need reclaims and/or compaction. At worst, they may fail and produce a stack trace such as (from uek4): [] __inc_zone_page_state+0x35/0x40 [] page_add_file_rmap+0x57/0x60 [] remove_migration_pte+0x3f/0x3c0 [ksplice_6cn872bt_vmlinux_new] [] rmap_walk+0xd8/0x340 [] remove_migration_ptes+0x40/0x50 [] migrate_pages+0x3ec/0x890 [] compact_zone+0x32d/0x9a0 [] compact_zone_order+0x6d/0x90 [] try_to_compact_pages+0x102/0x270 [] __alloc_pages_direct_compact+0x46/0x100 [] __alloc_pages_nodemask+0x74b/0xaa0 [] alloc_pages_current+0x91/0x110 [] new_slab+0x38b/0x480 [] __slab_alloc+0x3b7/0x4a0 [ksplice_s0dk66a8_vmlinux_new] [] kmem_cache_alloc+0x1fb/0x250 [] idr_layer_alloc+0x36/0x90 [] idr_get_empty_slot+0x28c/0x3d0 [] idr_alloc+0x4d/0xf0 [] cma_alloc_port+0x4d/0xa0 [rdma_cm] [] rdma_bind_addr+0x2ae/0x5b0 [rdma_cm] [] rds_ib_laddr_check+0x83/0x2c0 [ksplice_6l2xst5i_rds_rdma_new] [] rds_trans_get_preferred+0x5b/0xa0 [rds] [] rds_bind+0x212/0x280 [rds] [] SYSC_bind+0xe6/0x120 [] SyS_bind+0xe/0x10 [] system_call_fastpath+0x18/0xd4 To avoid these excessive calls to rdma_bind_addr(), we optimize rds_ib_laddr_check() by simply checking if the address in question has been used before. The rds_rdma module keeps track of addresses associated with IB devices, and the function rds_ib_get_device() is used to determine if the address already has been qualified as a valid local address. If not found, we call the legacy rds_ib_laddr_check(), now renamed to rds_ib_laddr_check_cm(). Signed-off-by: Håkon Bugge Signed-off-by: Somasundaram Krishnasamy Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-2-achender@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: ebf71dd4aff4 ("net/rds: Restrict use of RDS/IB to the initial network namespace") Signed-off-by: Sasha Levin commit 67c9ecc9f2575273ed1323e312881fc98ac83d6d Author: Jamal Hadi Salim Date: Fri Apr 10 07:16:27 2026 -0400 net/sched: act_ct: Only release RCU read lock after ct_ft [ Upstream commit f462dca0c8415bf0058d0ffa476354c4476d0f09 ] When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1] Fixes: 138470a9b2cc2 ("net/sched: act_ct: fix lockdep splat in tcf_ct_flow_table_get") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260410111627.46611-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2951656b0de00153f2687f3a093890bce72b6215 Author: Mashiro Chen Date: Wed Apr 8 01:31:01 2026 +0800 net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf [ Upstream commit bf9a38803b2626b01cc769aaf13485d8650f576f ] sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose. Reported-by: syzbot+ecdb8c9878a81eb21e54@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ecdb8c9878a81eb21e54 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260407173101.107352-1-mashiro.chen@mailbox.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ad3cbb4b2a6556bd88825b900be5f73459daa5c Author: Jiri Slaby (SUSE) Date: Thu Aug 8 12:35:47 2024 +0200 6pack: propagage new tty types [ Upstream commit 1241b384efa53f4b7a95fe2b34d69359bb3ae1b5 ] In tty, u8 is now used for data, ssize_t for sizes (with possible negative error codes). Propagate these types to 6pack. Signed-off-by: Jiri Slaby (SUSE) Cc: Greg Kroah-Hartman Cc: Andreas Koensgen Cc: David S. Miller Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: linux-hams@vger.kernel.org Cc: netdev@vger.kernel.org Reviewed-by: Jeremy Kerr Link: https://lore.kernel.org/r/20240808103549.429349-12-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: bf9a38803b26 ("net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf") Signed-off-by: Sasha Levin commit 5877fa143d1f90a98fb2b49d0c041b1028611c50 Author: Florian Westphal Date: Thu Apr 9 13:30:41 2026 +0200 netfilter: nft_fwd_netdev: check ttl/hl before forwarding [ Upstream commit 1dfd95bdf4d18d263aa8fad06bfb9f4d9c992b18 ] Drop packets if their ttl/hl is too small for forwarding. Fixes: d32de98ea70f ("netfilter: nft_fwd_netdev: allow to forward packets via neighbour layer") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 149e6b3fdf935c3bd815f0821ef1fd906cf38489 Author: Florian Westphal Date: Sat Apr 4 12:12:59 2026 +0200 netfilter: xt_socket: enable defrag after all other checks [ Upstream commit 542be3fa5aff54210a02954c38f07e53ea9bdafd ] Originally this did not matter because defrag was enabled once per netns and only disabled again on netns dismantle. When this got changed I should have adjusted checkentry to not leave defrag enabled on error. Fixes: de8c12110a13 ("netfilter: disable defrag once its no longer needed") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit e85b0c0a12e967930044608311471b665baa315c Author: Justin Chen Date: Mon Apr 6 10:57:56 2026 -0700 net: bcmgenet: fix racing timeout handler [ Upstream commit 5393b2b5bee2ac51a0043dc7f4ac3475f053d08d ] The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue. Fixes: 13ea657806cf ("net: bcmgenet: improve TX timeout") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-4-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 47cc6b2b4034ec3082f8ca0b5df6acbcf692a203 Author: Zak Kemble Date: Mon May 19 12:32:55 2025 +0100 net: bcmgenet: switch to use 64bit statistics [ Upstream commit 59aa6e3072aa7e51e9040e8c342d0c0825c5f48f ] Update the driver to use ndo_get_stats64, rtnl_link_stats64 and u64_stats_t counters for statistics. Signed-off-by: Zak Kemble Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250519113257.1031-2-zakkemble@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit 6a84791b63044cdee3ab55eb350e6352b751f584 Author: Doug Berger Date: Thu Mar 6 11:26:39 2025 -0800 net: bcmgenet: support reclaiming unsent Tx packets [ Upstream commit f1bacae8b655163dcbc3c54b9e714ef1a8986d7b ] When disabling the transmitter any outstanding packets can now be reclaimed by bcmgenet_tx_reclaim_all() rather than by the bcmgenet_fini_dma() function. Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250306192643.2383632-12-opendmb@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit 555dceac0409db7739486880fcb3b125dff6b6e0 Author: Doug Berger Date: Thu Mar 6 11:26:34 2025 -0800 net: bcmgenet: move DESC_INDEX flow to ring 0 [ Upstream commit 3b5d4f5a820d362dd46472542b2e961fb1f93515 ] The default transmit and receive packet handling is moved from the DESC_INDEX (i.e. 16) descriptor rings to the Ring 0 queues. This saves a fair amount of special case code by unifying the handling. A default dummy filter is enabled in the Hardware Filter Block to route default receive packets to Ring 0. Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250306192643.2383632-7-opendmb@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit cb6695f781501318ac55cfc83f8b46954ea411c1 Author: Doug Berger Date: Thu Mar 6 11:26:30 2025 -0800 net: bcmgenet: add bcmgenet_has_* helpers [ Upstream commit 07c1a756a50b1180a085ab61819a388bbb906a95 ] Introduce helper functions to indicate whether the driver should make use of a particular feature that it supports. These helpers abstract the implementation of how the feature availability is encoded. Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250306192643.2383632-3-opendmb@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit 24300cef774a18baa042ce46265162996e46915e Author: Florian Fainelli Date: Thu Oct 5 11:17:47 2023 -0700 net: bcmgenet: Remove custom ndo_poll_controller() [ Upstream commit 19537e125cc7cf2da43a606f5bcebbe0c9aea4cc ] The driver gained a .ndo_poll_controller() at a time where the TX cleaning process was always done from NAPI which makes this unnecessary. See commit ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional") for more background. Signed-off-by: Florian Fainelli Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit 3fbd86d107eeb1cbb0f22ac9aa47260aa27cd729 Author: Florian Fainelli Date: Fri Jul 28 11:39:45 2023 -0700 net: bcmgenet: Remove TX ring full logging [ Upstream commit df41fa677d9b4717c930afbe88b06f5cefdacb21 ] There is no need to spam the kernel log with such an indication, remove this message. Signed-off-by: Florian Fainelli Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230728183945.760531-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5393b2b5bee2 ("net: bcmgenet: fix racing timeout handler") Signed-off-by: Sasha Levin commit 85f34ec320d3881badfd4edc5fee5cd5012bb54d Author: Justin Chen Date: Mon Apr 6 10:57:54 2026 -0700 net: bcmgenet: fix off-by-one in bcmgenet_put_txcb [ Upstream commit 57f3f53d2c9c5a9e133596e2f7bc1c50688a6d38 ] The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up. Fixes: 876dbadd53a7 ("net: bcmgenet: Fix unmapping of fragments in bcmgenet_xmit()") Signed-off-by: Justin Chen Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecd5043d882afb40fefc1481556cd7a723454e3b Author: Wang Wensheng Date: Sun Apr 5 19:42:31 2026 +0800 arm64: kexec: Remove duplicate allocation for trans_pgd [ Upstream commit ee020bf6f14094c9ae434bb37e6957a1fdad513c ] trans_pgd would be allocated in trans_pgd_create_copy(), so remove the duplicate allocation before calling trans_pgd_create_copy(). Fixes: 3744b5280e67 ("arm64: kexec: install a copy of the linear-map") Signed-off-by: Wang Wensheng Reviewed-by: Pasha Tatashin Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 5bf28c3c88315b275cf803488b317234cfa015e8 Author: Haoyu Lu Date: Tue Apr 7 11:31:15 2026 +0800 ACPI: AGDI: fix missing newline in error message [ Upstream commit b178330b67abb7293b6de28b2a49d49c83962db5 ] Add the missing trailing newline to the dev_err() message printed when SDEI event registration fails. This keeps the error output as a properly terminated log line. Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen Signed-off-by: Haoyu Lu Reviewed-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 669349b4612c26b3d7aacfa99d7174681bd19223 Author: Weiming Shi Date: Sun Apr 5 00:12:20 2026 +0800 bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() [ Upstream commit 1c22483a2c4bbf747787f328392ca3e68619c4dc ] CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. "0:1:2" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf("%d"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing. Fixes: ddc7c3042614 ("libbpf: implement BPF CO-RE offset relocation algorithm") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Emil Tsalapatis Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260404161221.961828-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f0fc2a9828171205244a28013f02889f50b71c9f Author: Jiayuan Chen Date: Tue Apr 7 20:23:33 2026 +0800 bpf: Drop task_to_inode and inet_conn_established from lsm sleepable hooks [ Upstream commit beaf0e96b1da74549a6cabd040f9667d83b2e97e ] bpf_lsm_task_to_inode() is called under rcu_read_lock() and bpf_lsm_inet_conn_established() is called from softirq context, so neither hook can be used by sleepable LSM programs. Fixes: 423f16108c9d8 ("bpf: Augment the set of sleepable LSM hooks") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/3ab69731-24d1-431a-a351-452aafaaf2a5@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260407122334.344072-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bd6c906e0c4af6d5d0c49c3c4ee090b4913da17d Author: Ethan Tidmore Date: Mon Feb 16 20:30:43 2026 -0600 wifi: brcmfmac: Fix error pointer dereference [ Upstream commit dd8592fc6007a451c3e4b9025de365e39de8178a ] The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() Fixes: cb7cf7be9eba7 ("brcmfmac: make chip related functions host interface independent") Signed-off-by: Ethan Tidmore Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260217023043.73631-1-ethantidmore06@gmail.com [add missing wifi: prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2c88b2d96e1d4d0c7c4589a4593d4cdee6d332d6 Author: Weiming Shi Date: Fri Apr 3 21:29:50 2026 +0800 bpf: fix end-of-list detection in cgroup_storage_get_next_key() [ Upstream commit 5828b9e5b272ecff7cf5d345128d3de7324117f7 ] list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Sun Jian Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260403132951.43533-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5cf64d03b1da9ca3455b6a6d7010f3bebabedc48 Author: Eric Dumazet Date: Wed Apr 1 10:38:08 2026 +0000 macvlan: annotate data-races around port->bc_queue_len_used [ Upstream commit 1ef5789d9906df3771c99b7f413caaf2bf473ca5 ] port->bc_queue_len_used is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While WRITE_ONCE() in macvlan_fill_info() is not yet needed, it is a prereq for future RTNL avoidance. Fixes: d4bff72c8401 ("macvlan: Support for high multicast packet rate") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260401103809.3038139-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cebc6e64cd1f70a4802cd8faa53222d90349df79 Author: Sourabh Jain Date: Thu Mar 12 14:00:49 2026 +0530 powerpc/crash: fix backup region offset update to elfcorehdr [ Upstream commit 789335cacdf37da93bb7c70322dff8c7e82881df ] update_backup_region_phdr() in file_load_64.c iterates over all the program headers in the kdump kernel’s elfcorehdr and updates the p_offset of the program header whose physical address starts at 0. However, the loop logic is incorrect because the program header pointer is not updated during iteration. Since elfcorehdr typically contains PT_NOTE entries first, the PT_LOAD program header with physical address 0 is never reached. As a result, its p_offset is not updated to point to the backup region. Because of this behavior, the capture kernel exports the first 64 KB of the crashed kernel’s memory at offset 0, even though that memory actually lives in the backup region. When a crash happens, purgatory copies the first 64 KB of the crashed kernel’s memory into the backup region so the capture kernel can safely use it. This has not caused problems so far because the first 64 KB is usually identical in both the crashed and capture kernels. However, this is just an assumption and is not guaranteed to always hold true. Fix update_backup_region_phdr() to correctly update the p_offset of the program header with a starting physical address of 0 by correcting the logic used to iterate over the program headers. Fixes: cb350c1f1f86 ("powerpc/kexec_file: Prepare elfcore header for crashing kernel") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-2-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit ab2afba37a2ace4fe9d40713aee416d8f84a3ad7 Author: Chih Kai Hsu Date: Thu Mar 26 15:39:23 2026 +0800 r8152: fix incorrect register write to USB_UPHY_XTAL [ Upstream commit 48afd5124fd6129c46fd12cb06155384b1c4a0c4 ] The old code used ocp_write_byte() to clear the OOBS_POLLING bit (BIT(8)) in the USB_UPHY_XTAL register, but this doesn't correctly clear a bit in the upper byte of the 16-bit register. Fix this by using ocp_write_word() instead. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Chih Kai Hsu Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260326073925.32976-454-nic_swsd@realtek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 47eda7484c2c7b4229e06d3c96dbdfbaf19ee36a Author: Alexey Velichayshiy Date: Mon Mar 23 17:05:53 2026 +0300 wifi: rtw89: phy: fix uninitialized variable access in rtw89_phy_cfo_set_crystal_cap() [ Upstream commit 047cddf88c611e616d49a00311d4722e46286234 ] In the rtw89_phy_cfo_set_crystal_cap() function, for chips other than RTL8852A/RTL8851B, the values read by rtw89_mac_read_xtal_si() are stored into the local variables sc_xi_val and sc_xo_val. If either read fails, these variables remain uninitialized, they are later used to update cfo->crystal_cap and in debug print statements. This can lead to undefined behavior. Fix the issue by initializing sc_xi_val and sc_xo_val to zero, like is implemented in vendor driver. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8379fa611536 ("rtw89: 8852c: add write/read crystal function in CFO tracking") Signed-off-by: Alexey Velichayshiy Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260323140613.1615574-1-a.velichayshiy@ispras.ru Signed-off-by: Sasha Levin commit b089aa6e94d7a08e74d076a0fe274842dc9feccc Author: David Carlier Date: Fri Mar 20 07:26:45 2026 +0000 bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path [ Upstream commit 8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19 ] The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Signed-off-by: David Carlier Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20260320072645.16731-1-devnexen@gmail.com Signed-off-by: Sasha Levin commit 6951703a1b526441f709cf3d273b92783b4a5b4f Author: Thorsten Blum Date: Wed May 29 12:19:01 2024 +0200 bpf, devmap: Remove unnecessary if check in for loop [ Upstream commit 2317dc2c22cc353b699c7d1db47b2fe91f54055c ] The iterator variable dst cannot be NULL and the if check can be removed. Remove it and fix the following Coccinelle/coccicheck warning reported by itnull.cocci: ERROR: iterator variable bound on line 762 cannot be NULL Signed-off-by: Thorsten Blum Signed-off-by: Daniel Borkmann Reviewed-by: Toke Høiland-Jørgensen Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240529101900.103913-2-thorsten.blum@toblux.com Stable-dep-of: 8ed82f807bb0 ("bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path") Signed-off-by: Sasha Levin commit 80c6b35dbd1b18859fc240e440b5b65bd15d0344 Author: Petr Pavlu Date: Fri Mar 13 14:48:02 2026 +0100 module: Fix freeing of charp module parameters when CONFIG_SYSFS=n [ Upstream commit deffe1edba626d474fef38007c03646ca5876a0e ] When setting a charp module parameter, the param_set_charp() function allocates memory to store a copy of the input value. Later, when the module is potentially unloaded, the destroy_params() function is called to free this allocated memory. However, destroy_params() is available only when CONFIG_SYSFS=y, otherwise only a dummy variant is present. In the unlikely case that the kernel is configured with CONFIG_MODULES=y and CONFIG_SYSFS=n, this results in a memory leak of charp values when a module is unloaded. Fix this issue by making destroy_params() always available when CONFIG_MODULES=y. Rename the function to module_destroy_params() to clarify that it is intended for use by the module loader. Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs") Signed-off-by: Petr Pavlu Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit a3dca4b6d5ea15b2269237508d59293b5698df88 Author: Petr Pavlu Date: Tue Aug 19 14:12:09 2025 +0200 params: Replace __modinit with __init_or_module [ Upstream commit 3cb0c3bdea5388519bc1bf575dca6421b133302b ] Remove the custom __modinit macro from kernel/params.c and instead use the common __init_or_module macro from include/linux/module.h. Both provide the same functionality. Signed-off-by: Petr Pavlu Reviewed-by: Aaron Tomlin Reviewed-by: Daniel Gomez Reviewed-by: Sami Tolvanen Signed-off-by: Sami Tolvanen Stable-dep-of: deffe1edba62 ("module: Fix freeing of charp module parameters when CONFIG_SYSFS=n") Signed-off-by: Sasha Levin commit f74020571dc74f7cae46eb26bcabd777d9b7c5a3 Author: Shyam Saini Date: Thu Feb 27 10:49:29 2025 -0800 kernel: globalize lookup_or_create_module_kobject() [ Upstream commit 7c76c813cfc42a7376378a0c4b7250db2eebab81 ] lookup_or_create_module_kobject() is marked as static and __init, to make it global drop static keyword. Since this function can be called from non-init code, use __modinit instead of __init, __modinit marker will make it __init if CONFIG_MODULES is not defined. Suggested-by: Rasmus Villemoes Signed-off-by: Shyam Saini Link: https://lore.kernel.org/r/20250227184930.34163-4-shyamsaini@linux.microsoft.com Signed-off-by: Petr Pavlu Stable-dep-of: deffe1edba62 ("module: Fix freeing of charp module parameters when CONFIG_SYSFS=n") Signed-off-by: Sasha Levin commit 2801afe81153ac574b55d8fb2b9000e2d5497ca8 Author: Shyam Saini Date: Thu Feb 27 10:49:27 2025 -0800 kernel: param: rename locate_module_kobject [ Upstream commit bbc9462f0cb0c8917a4908e856731708f0cee910 ] The locate_module_kobject() function looks up an existing module_kobject for a given module name. If it cannot find the corresponding module_kobject, it creates one for the given name. This commit renames locate_module_kobject() to lookup_or_create_module_kobject() to better describe its operations. This doesn't change anything functionality wise. Suggested-by: Rasmus Villemoes Signed-off-by: Shyam Saini Link: https://lore.kernel.org/r/20250227184930.34163-2-shyamsaini@linux.microsoft.com Signed-off-by: Petr Pavlu Stable-dep-of: deffe1edba62 ("module: Fix freeing of charp module parameters when CONFIG_SYSFS=n") Signed-off-by: Sasha Levin commit b3bcd8579336445c974801c8229b81f73c44ed7c Author: Cai Xinchen Date: Thu Mar 12 06:59:07 2026 +0000 dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n [ Upstream commit 97daf00745f7f9f261b0e91418de6e79d7826c36 ] CONFIG_FSL_DPAA2_ETH and CONFIG_FSL_DPAA2_SWITCH are not associated, but the compilation of FSL_DPAA2_SWITCH depends on the compilation of the dpaa2 folder. The files controlled by CONFIG_FSL_DPAA2_SWITCH in the dpaa2 folder are not controlled by CONFIG_FSL_DPAA2_ETH, except for the files controlled by CONFIG_FSL_DPAA2_SWITCH. Therefore, removing the restriction will not affect the compilation of the files in the directory. Fixes: f48298d3fbfaa ("staging: dpaa2-switch: move the driver out of staging") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-3-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d70e72c8771abc47c5ba80cfa66eac382a9c5f3c Author: Cai Xinchen Date: Thu Mar 12 06:59:06 2026 +0000 dpaa2: add independent dependencies for FSL_DPAA2_SWITCH [ Upstream commit 12589892f41c4c645c80ef9f036f7451a6045624 ] Since the commit 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") included dpaa2-mac.o in the driver, but it didn't select PCS_LYNX, PHYLINK and FSL_XGMAC_MDIO. it will lead to link error, such as undefined reference to `phylink_ethtool_ksettings_set' undefined reference to `lynx_pcs_create_fwnode' And the same reason as the commit d2624e70a2f53 ("dpaa2-eth: select XGMAC_MDIO for MDIO bus support"), enable the FSL_XGMAC_MDIO Kconfig option in order to have MDIO access to internal and external PHYs. Because dpaa2-switch uses fsl_mc_driver APIs, add depends on FSL_MC_BUS && FSL_MC_DPIO as FSL_DPAA2_SWITCH do. FSL_XGMAC_MDIO and FSL_MC_BUS depend on OF, thus the dependence of FSL_MC_BUS can satisfy FSL_XGMAC_MDIO's OF requirement. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-2-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5c8d1f91fc4898d79f29d79c1a6f7c2b3ee66fb0 Author: Feng Yang Date: Wed Mar 4 17:44:28 2026 +0800 bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap [ Upstream commit 972787479ee73006fddb5e59ab5c8e733810ff42 ] The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to calculate the needed headroom: err = skb_cow_head(skb, len + LL_RESERVED_SPACE(skb_dst(skb)->dev)); But skb->_skb_refdst may not be initialized when the skb is set up by bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function in this scenario will trigger null pointer dereference, causing a kernel crash as Yinhao reported: [ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 105.186382] #PF: supervisor read access in kernel mode [ 105.186388] #PF: error_code(0x0000) - not-present page [ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0 [ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520 [ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0 [ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246 [ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00 [ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500 [ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000 [ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98 [ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002 [ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000 [ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0 [ 105.186499] PKRU: 55555554 [ 105.186502] Call Trace: [ 105.186507] [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40 [ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49 [ 105.186536] ? kvm_clock_get_cycles+0x18/0x30 [ 105.186547] ? ktime_get+0x3c/0xa0 [ 105.186554] bpf_test_run+0x195/0x320 [ 105.186563] ? bpf_test_run+0x10f/0x320 [ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0 [ 105.186590] __sys_bpf+0x69c/0xa40 [ 105.186603] __x64_sys_bpf+0x1e/0x30 [ 105.186611] do_syscall_64+0x59/0x110 [ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0 [ 105.186649] RIP: 0033:0x7f166a97455d Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue. Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Closes: https://groups.google.com/g/hust-os-kernel-patches/c/8-a0kPpBW2s Signed-off-by: Yun Lu Signed-off-by: Feng Yang Signed-off-by: Martin KaFai Lau Tested-by: syzbot@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260304094429.168521-2-yangfeng59949@163.com Signed-off-by: Sasha Levin commit 98440ef214c14f0b28c872c01c65bc65c1da9ab1 Author: Vadim Fedorenko Date: Thu Jun 6 07:58:50 2024 -0700 bpf: Add CHECKSUM_COMPLETE to bpf test progs [ Upstream commit a3cfe84cca28f205761a0450016593b0d728165e ] Add special flag to validate that TC BPF program properly updates checksum information in skb. Signed-off-by: Vadim Fedorenko Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Kicinski Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240606145851.229116-1-vadfed@meta.com Stable-dep-of: 972787479ee7 ("bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap") Signed-off-by: Sasha Levin commit e40873820c9d245ce482faa7ad514ebdb3b8d23d Author: Duoming Zhou Date: Mon Feb 23 12:55:22 2026 +0800 wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet [ Upstream commit 039cd522dc70151da13329a5e3ae19b1736f468a ] The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Duoming Zhou Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260223045522.48377-1-duoming@zju.edu.cn Signed-off-by: Sasha Levin commit 1c0474142557237ba11c7948ebe7a51cf8d8533a Author: Zilin Guan Date: Mon Jan 19 09:26:25 2026 +0000 wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt() [ Upstream commit 990a73dec3fdc145fef6c827c29205437d533ece ] In mwifiex_11n_aggregate_pkt(), skb_aggr is allocated via mwifiex_alloc_dma_align_buf(). If mwifiex_is_ralist_valid() returns false, the function currently returns -1 immediately without freeing the previously allocated skb_aggr, causing a memory leak. Since skb_aggr has not yet been queued via skb_queue_tail(), no other references to this memory exist. Therefore, it has to be freed locally before returning the error. Fix this by calling mwifiex_write_data_complete() to free skb_aggr before returning the error status. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Zilin Guan Reviewed-by: Jeff Chen Link: https://patch.msgid.link/20260119092625.1349934-1-zilin@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a94ab88351c812f87a455c9d54e5485861ad7fed Author: Mario Limonciello (AMD) Date: Sat Mar 7 08:10:20 2026 -0600 firmware: dmi: Correct an indexing error in dmi.h [ Upstream commit c064abc68e009d2cc18416e7132d9c25e03125b6 ] The entries later in enum dmi_entry_type don't match the SMBIOS specification¹. The entry for type 33: `64-Bit Memory Error Information` is not present and thus the index for all later entries is incorrect. Add it. Also, add missing entry types 43-46, while at it. ¹ Search for "System Management BIOS (SMBIOS) Reference Specification" [ bp: Drop the flaky SMBIOS spec URL. ] Fixes: 93c890dbe5287 ("firmware: Add DMI entry types to the headers") Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Jean Delvare Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20260307141024.819807-2-superm1@kernel.org Signed-off-by: Sasha Levin commit d74ff195dbb4b22290609d0eefced4b32fcc361e Author: Bart Van Assche Date: Fri Mar 13 10:15:07 2026 -0700 locking: Fix rwlock support in [ Upstream commit 756a0e011cfca0b45a48464aa25b05d9a9c2fb0b ] Architecture support for rwlocks must be available whether or not CONFIG_DEBUG_SPINLOCK has been defined. Move the definitions of the arch_{read,write}_{lock,trylock,unlock}() macros such that these become visbile if CONFIG_DEBUG_SPINLOCK=n. This patch prepares for converting do_raw_{read,write}_trylock() into inline functions. Without this patch that conversion triggers a build failure for UP architectures, e.g. arm-ep93xx. I used the following kernel configuration to build the kernel for that architecture: CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=n CONFIG_ATAGS=y CONFIG_MMU=y CONFIG_ARCH_MULTI_V4T=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ARCH_EP93XX=y Fixes: fb1c8f93d869 ("[PATCH] spinlock consolidation") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260313171510.230998-2-bvanassche@acm.org Signed-off-by: Sasha Levin commit 43127ac6bc0a6e1f3d0e04cc79ac5f3915beacef Author: Thomas Gleixner Date: Tue Feb 24 17:36:59 2026 +0100 hrtimer: Reduce trace noise in hrtimer_start() [ Upstream commit f2e388a019e4cf83a15883a3d1f1384298e9a6aa ] hrtimer_start() when invoked with an already armed timer traces like: -.. [032] d.h2. 5.002263: hrtimer_cancel: hrtimer= .... -.. [032] d.h1. 5.002263: hrtimer_start: hrtimer= .... Which is incorrect as the timer doesn't get canceled. Just the expiry time changes. The internal dequeue operation which is required for that is not really interesting for trace analysis. But it makes it tedious to keep real cancellations and the above case apart. Remove the cancel tracing in hrtimer_start() and add a 'was_armed' indicator to the hrtimer start tracepoint, which clearly indicates what the state of the hrtimer is when hrtimer_start() is invoked: -.. [032] d.h1. 6.200103: hrtimer_start: hrtimer= .... was_armed=0 -.. [032] d.h1. 6.200558: hrtimer_start: hrtimer= .... was_armed=1 Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260224163430.208491877@kernel.org Signed-off-by: Sasha Levin commit 61397c2ab2a73ec3de75a5293f6ff02a6ec0bb1b Author: Peter Zijlstra Date: Tue Feb 24 17:35:37 2026 +0100 hrtimer: Avoid pointless reprogramming in __hrtimer_start_range_ns() [ Upstream commit d19ff16c11db38f3ee179d72751fb9b340174330 ] Much like hrtimer_reprogram(), skip programming if the cpu_base is running the hrtimer interrupt. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Thomas Gleixner Link: https://patch.msgid.link/20260224163429.069535561@kernel.org Stable-dep-of: f2e388a019e4 ("hrtimer: Reduce trace noise in hrtimer_start()") Signed-off-by: Sasha Levin commit 630169bcf922c41a786020dcdcab384322580933 Author: Richard Clark Date: Tue Dec 24 15:57:03 2024 +0800 hrtimers: Update the return type of enqueue_hrtimer() [ Upstream commit da7100d3bf7d6f5c49ef493ea963766898e9b069 ] The return type should be 'bool' instead of 'int' according to the calling context in the kernel, and its internal implementation, i.e. : return timerqueue_add(); which is a bool-return function. [ tglx: Adjust function arguments ] Signed-off-by: Richard Clark Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/Z2ppT7me13dtxm1a@MBC02GN1V4Q05P Stable-dep-of: f2e388a019e4 ("hrtimer: Reduce trace noise in hrtimer_start()") Signed-off-by: Sasha Levin commit 43588f5fc7b36a72f91b40ad14efa02516443d70 Author: Brian Masney Date: Sun Feb 22 18:43:44 2026 -0500 irqchip/irq-pic32-evic: Address warning related to wrong printf() formatter [ Upstream commit 86be659415b0ddefebc3120e309091aa215a9064 ] This driver is currently only build on 32 bit MIPS systems. When building it on x86_64, the following warning occurs: drivers/irqchip/irq-pic32-evic.c: In function ‘pic32_ext_irq_of_init’: ./include/linux/kern_levels.h:5:25: error: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=] Update the printf() formatter in preparation for allowing this driver to be compiled on all architectures. Fixes: aaa8666ada780 ("IRQCHIP: irq-pic32-evic: Add support for PIC32 interrupt controller") Signed-off-by: Brian Masney Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260222-irqchip-pic32-v1-1-37f50d1f14af@redhat.com Signed-off-by: Sasha Levin commit 6d42c6888231c8d5abb0bff2b8c886c484045560 Author: Gui-Dong Han Date: Mon Mar 23 16:58:44 2026 +0800 debugfs: check for NULL pointer in debugfs_create_str() [ Upstream commit 31de83980d3764d784f79ff1bc93c42b324f4013 ] Passing a NULL pointer to debugfs_create_str() leads to a NULL pointer dereference when the debugfs file is read. Following upstream discussions, forbid the creation of debugfs string files with NULL pointers. Add a WARN_ON() to expose offending callers and return early. Fixes: 9af0440ec86e ("debugfs: Implement debugfs_create_str()") Reported-by: yangshiguang Closes: https://lore.kernel.org/lkml/2025122221-gag-malt-75ba@gregkh/ Suggested-by: Greg Kroah-Hartman Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-2-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 32cb68842e96612d1dd3df3ce494df22bfaa8623 Author: Gopi Krishna Menon Date: Fri Mar 27 14:35:24 2026 +0530 thermal/drivers/spear: Fix error condition for reading st,thermal-flags [ Upstream commit da2c4f332a0504d9c284e7626a561d343c8d6f57 ] of_property_read_u32 returns 0 on success. The current check returns -EINVAL if the property is read successfully. Fix the check by removing ! from of_property_read_u32 Fixes: b9c7aff481f1 ("drivers/thermal/spear_thermal.c: add Device Tree probing capability") Signed-off-by: Gopi Krishna Menon Signed-off-by: Daniel Lezcano Suggested-by: Daniel Baluta Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260327090526.59330-1-krishnagopi487@gmail.com Signed-off-by: Sasha Levin commit 6935938b1a7e1e85b8dcc7f1d3a48bc1b9021054 Author: Danilo Krummrich Date: Tue Feb 3 00:48:14 2026 +0100 devres: fix missing node debug info in devm_krealloc() [ Upstream commit f813ec9e84b4d0ca81ec1da94ab07bfb4a29266c ] Fix missing call to set_node_dbginfo() for new devres nodes created by devm_krealloc(). Fixes: f82485722e5d ("devres: provide devm_krealloc()") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260202235210.55176-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 437e036c8862be47c32d81d7f351da31a8171bec Author: Cole Leavitt Date: Wed Feb 25 16:54:06 2026 -0700 pstore/ram: fix resource leak when ioremap() fails [ Upstream commit 2ddb69f686ef7a621645e97fc7329c50edf5d0e5 ] In persistent_ram_iomap(), ioremap() or ioremap_wc() may return NULL on failure. Currently, if this happens, the function returns NULL without releasing the memory region acquired by request_mem_region(). This leads to a resource leak where the memory region remains reserved but unusable. Additionally, the caller persistent_ram_buffer_map() handles NULL correctly by returning -ENOMEM, but without this check, a NULL return combined with request_mem_region() succeeding leaves resources in an inconsistent state. This is the ioremap() counterpart to commit 05363abc7625 ("pstore: ram_core: fix incorrect success return when vmap() fails") which fixed a similar issue in the vmap() path. Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory") Signed-off-by: Cole Leavitt Link: https://patch.msgid.link/20260225235406.11790-1-cole@unwrap.rs Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 65e07964b4b2daf9a54e686cf0fa72d74a9648a8 Author: Deepanshu Kartikey Date: Wed Apr 1 02:52:09 2026 +0900 nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() [ Upstream commit be3e5d10643d3be1cbac9d9939f220a99253f980 ] nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy] Fixes: 7942b919f732 ("nilfs2: ioctl operations") Reported-by: syzbot+98a040252119df0506f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=98a040252119df0506f8 Suggested-by: Ryusuke Konishi Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+466a45fcfb0562f5b9a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=466a45fcfb0562f5b9a0 Cc: Junjie Cao Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 6cd27bcb71bb73f955d104cc3a62be6f83724392 Author: Bart Van Assche Date: Thu Mar 26 14:40:54 2026 -0700 drbd: Balance RCU calls in drbd_adm_dump_devices() [ Upstream commit 2b31e86387e60b3689339f0f0fbb4d3623d9d494 ] Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer. Tested-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Cc: Andreas Gruenbacher Fixes: a55bbd375d18 ("drbd: Backport the "status" command") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260326214054.284593-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 754ff1bea3819a90c6f33cccfc1a299ef7609f07 Author: HyungJung Joo Date: Tue Mar 17 14:48:27 2026 +0900 fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START [ Upstream commit 0621c385fda1376e967f37ccd534c26c3e511d14 ] omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize < OMFS_DIR_START causes an unsigned underflow there, wrapping to a value near 2^32. That drives a ~4 GiB memset() from bh->b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed. Fixes: a3ab7155ea21 ("omfs: add directory routines") Signed-off-by: Hyungjung Joo Link: https://patch.msgid.link/20260317054827.1822061-1-jhj140711@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit aa7cb2401997275116fc6c130453936e34d14732 Author: Ming Lei Date: Wed Mar 11 11:28:37 2026 +0800 blk-cgroup: wait for blkcg cleanup before initializing new disk [ Upstream commit 3dbaacf6ab68f81e3375fe769a2ecdbd3ce386fd ] When a queue is shared across disk rebind (e.g., SCSI unbind/bind), the previous disk's blkcg state is cleaned up asynchronously via disk_release() -> blkcg_exit_disk(). If the new disk's blkcg_init_disk() runs before that cleanup finishes, we may overwrite q->root_blkg while the old one is still alive, and radix_tree_insert() in blkg_create() fails with -EEXIST because the old blkg entries still occupy the same queue id slot in blkcg->blkg_tree. This causes the sd probe to fail with -ENOMEM. Fix it by waiting in blkcg_init_disk() for root_blkg to become NULL, which indicates the previous disk's blkcg cleanup has completed. Fixes: 1059699f87eb ("block: move blkcg initialization/destroy into disk allocation/release handler") Cc: Yi Zhang Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260311032837.2368714-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cbeb6c8daa2ebc8f73c0ced5cfb1e9e52e91dce3 Author: Mingzhe Zou Date: Fri Apr 3 12:21:35 2026 +0800 bcache: fix uninitialized closure object commit 20a8e451ec1c7e99060b1bbaaad03ce88c39ddb8 upstream. In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and crash"), we adopted a simple modification suggestion from AI to fix the use-after-free. But in actual testing, we found an extreme case where the device is stopped before calling bch_write_bdev_super(). At this point, struct closure sb_write has not been initialized yet. For this patch, we ensure that sb_bio has been completed via sb_write_mutex. Signed-off-by: Mingzhe Zou Signed-off-by: Coly Li Link: https://patch.msgid.link/20260403042135.2221247-1-colyli@fnnas.com Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f791837015a0d20f584d0ed368393f119a00018f Author: Amit Kumar Mahapatra Date: Thu Feb 13 11:15:46 2025 +0530 mtd: spi-nor: sst: Fix SST write failure commit 539bd20352832b9244238a055eb169ccf1c41ff6 upstream. 'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`")' introduced a bug where only one byte of data is written, regardless of the number of bytes passed to sst_nor_write_data(), causing a kernel crash during the write operation. Ensure the correct number of bytes are written as passed to sst_nor_write_data(). Call trace: [ 57.400180] ------------[ cut here ]------------ [ 57.404842] While writing 2 byte written 1 bytes [ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74 [ 57.418464] Modules linked in: [ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30 [ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT) [ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.444557] pc : sst_nor_write_data+0x6c/0x74 [ 57.448911] lr : sst_nor_write_data+0x6c/0x74 [ 57.453264] sp : ffff80008232bb40 [ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001 [ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000 [ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000 [ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006 [ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580 [ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4 [ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001 [ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000 [ 57.527916] Call trace: [ 57.530354] sst_nor_write_data+0x6c/0x74 [ 57.534361] sst_nor_write+0xb4/0x18c [ 57.538019] mtd_write_oob_std+0x7c/0x88 [ 57.541941] mtd_write_oob+0x70/0xbc [ 57.545511] mtd_write+0x68/0xa8 [ 57.548733] mtdchar_write+0x10c/0x290 [ 57.552477] vfs_write+0xb4/0x3a8 [ 57.555791] ksys_write+0x74/0x10c [ 57.559189] __arm64_sys_write+0x1c/0x28 [ 57.563109] invoke_syscall+0x54/0x11c [ 57.566856] el0_svc_common.constprop.0+0xc0/0xe0 [ 57.571557] do_el0_svc+0x1c/0x28 [ 57.574868] el0_svc+0x30/0xcc [ 57.577921] el0t_64_sync_handler+0x120/0x12c [ 57.582276] el0t_64_sync+0x190/0x194 [ 57.585933] ---[ end trace 0000000000000000 ]--- Cc: stable@vger.kernel.org Fixes: 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`") Signed-off-by: Amit Kumar Mahapatra Reviewed-by: Pratyush Yadav Reviewed-by: Tudor Ambarus Reviewed-by: Bence Csókás [pratyush@kernel.org: add Cc stable tag] Signed-off-by: Pratyush Yadav Link: https://lore.kernel.org/r/20250213054546.2078121-1-amit.kumar-mahapatra@amd.com Signed-off-by: Greg Kroah-Hartman commit f7bf02dcb7c76229ea8ace11b7d0d0c7b87ee57e Author: Benjamin Cheng Date: Mon Apr 13 09:22:15 2026 -0400 drm/amdgpu/vcn4: Avoid overflow on msg bound check commit 65bce27ea6192320448c30267ffc17ffa094e713 upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885) Signed-off-by: Greg Kroah-Hartman commit 95b0f6df8d7fad2eabf265d2c3d2538ef58e4465 Author: Benjamin Cheng Date: Mon Apr 13 09:22:15 2026 -0400 drm/amdgpu/vcn3: Avoid overflow on msg bound check commit e6e9faba8100628990cccd13f0f044a648c303cf upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10) Signed-off-by: Greg Kroah-Hartman commit f66c7904fb6f0e420a654bc90909e64a25d00896 Author: Dudu Lu Date: Mon Apr 13 21:14:09 2026 +0800 vsock/virtio: fix accept queue count leak on transport mismatch commit 52bcb57a4e8a0865a76c587c2451906342ae1b2d upstream. virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport. Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") Signed-off-by: Dudu Lu Reviewed-by: Bobby Eshleman Reviewed-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260413131409.19022-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit 01ef69785dc3162f588a361ab770b1e312800188 Author: Norbert Szetei Date: Thu Apr 9 18:34:12 2026 +0200 vsock: fix buffer size clamping order commit d114bfdc9b76bf93b881e195b7ec957c14227bab upstream. In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size. Fixes: b9f2b0ffde0c ("vsock: handle buffer_size sockopts in the core") Suggested-by: Stefano Garzarella Signed-off-by: Norbert Szetei Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/180118C5-8BCF-4A63-A305-4EE53A34AB9C@doyensec.com Signed-off-by: Jakub Kicinski Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit 9823c82ca194d7cec0a84542b67a3d33896d474d Author: Viorel Suman (OSS) Date: Wed Mar 11 14:33:09 2026 +0200 pwm: imx-tpm: Count the number of enabled channels in probe commit 3962c24f2d14e8a7f8a23f56b7ce320523947342 upstream. On a soft reset TPM PWM IP may preserve its internal state from previous runtime, therefore on a subsequent OS boot and driver probe "enable_count" value and TPM PWM IP internal channels "enabled" states may get unaligned. In consequence on a suspend/resume cycle the call "if (--tpm->enable_count == 0)" may lead to "enable_count" overflow the system being blocked from entering suspend due to: if (tpm->enable_count > 0) return -EBUSY; Fix the problem by counting the enabled channels in probe function. Signed-off-by: Viorel Suman (OSS) Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Link: https://patch.msgid.link/20260311123309.348904-1-viorel.suman@oss.nxp.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König [ukleinek: backport to linux-6.6.y] Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 8f11d83c9f744c00cc41d461fa30b53b92e3469c Author: Sanjaikumar V S Date: Wed Mar 11 10:30:56 2026 +0000 mtd: spi-nor: sst: Fix write enable before AAI sequence commit a0f64241d3566a49c0a9b33ba7ae458ae22003a9 upstream. When writing to SST flash starting at an odd address, a single byte is first programmed using the byte program (BP) command. After this operation completes, the flash hardware automatically clears the Write Enable Latch (WEL) bit. If an AAI (Auto Address Increment) word program sequence follows, it requires WEL to be set. Without re-enabling writes, the AAI sequence fails. Add spi_nor_write_enable() after the odd-address byte program when more data needs to be written. Use a local boolean for clarity. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Cc: stable@vger.kernel.org Signed-off-by: Sanjaikumar V S Tested-by: Hendrik Donner Reviewed-by: Hendrik Donner Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Greg Kroah-Hartman commit b925a5787b6e1d05731eb2dcc31dcaafc40ec2b6 Author: Bence Csókás Date: Wed Jul 10 11:14:01 2024 +0200 mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()` commit 18bcb4aa54eab75dce41e5c176a1c2bff94f0f79 upstream. Writing to the Flash in `sst_nor_write()` is a 3-step process: first an optional one-byte write to get 2-byte-aligned, then the bulk of the data is written out in vendor-specific 2-byte writes. Finally, if there's a byte left over, another one-byte write. This was implemented 3 times in the body of `sst_nor_write()`. To reduce code duplication, factor out these sub-steps to their own function. Signed-off-by: Csókás, Bence Reviewed-by: Pratyush Yadav [pratyush@kernel.org: fixup whitespace, use %zu instead of %i in WARN()] Signed-off-by: Pratyush Yadav Link: https://lore.kernel.org/r/20240710091401.1282824-1-csokas.bence@prolan.hu Signed-off-by: Greg Kroah-Hartman commit e1863e7480feddb90125d0dd5a1b572972d75908 Author: Siwei Zhang Date: Wed Apr 15 16:53:36 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() commit 78a88d43dab8d23aeef934ed8ce34d40e6b3d613 upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 8d836d71e222 ("Bluetooth: Access sk_sndtimeo indirectly in l2cap_core.c") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2888c9a154123db0254ae4fb9bea570c7e1f2e06 Author: Sven Eckelmann Date: Wed May 6 22:20:52 2026 +0200 batman-adv: bla: put backbone reference on failed claim hash insert commit ba9d20ee9076dac32c371116bacbe72480eb356c upstream. When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object. Cc: stable@kernel.org Fixes: 3db0decf1185 ("batman-adv: Fix non-atomic bla_claim::backbone_gw access") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit afb5436f6028fd68f408f189230fbaa19c910d72 Author: Sven Eckelmann Date: Wed May 6 22:20:51 2026 +0200 batman-adv: bla: only purge non-released claims commit cf6b604011591865ae39ac82de8978c1120d17af upstream. When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b88c865dcf6e9f20bfe66a360d4b62941ef769b8 Author: Sven Eckelmann Date: Wed May 6 22:20:50 2026 +0200 batman-adv: bla: prevent use-after-free when deleting claims commit 4ae1709a314060a196981b344610d023ea841e57 upstream. When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 8c16c68fdbb69778f8d04f650340c3f4d1518f8e Author: Jiexun Wang Date: Sun May 3 12:28:58 2026 +0800 batman-adv: stop caching unowned originator pointers in BAT IV commit f03e8583532941b07761c5429de7d50766fa3110 upstream. BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei [sven: avoid bonding logic for outgoing OGM] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 52e6ec3e972cf27792cc1559874dbee19f286869 Author: Jiexun Wang Date: Mon Apr 27 14:43:33 2026 +0800 batman-adv: reject new tp_meter sessions during teardown commit 3243543592425beec83d453793e9d27caa0d8e66 upstream. Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE. Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 96c9c0ed9a9579a9085765aceaa4556a6666eb82 Author: Lyes Bourennani Date: Wed Apr 22 00:20:22 2026 +0200 batman-adv: fix integer overflow on buff_pos commit 0799e5943611006b346b8813c7daf7dd5aa26bfd upstream. Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read. Cc: stable@vger.kernel.org Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Signed-off-by: Lyes Bourennani Signed-off-by: Alexis Pinson Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 0c7b55974f97b78d1109025eadf084e74cbf330f Author: Ben Morris Date: Thu May 7 17:14:55 2026 -0700 sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL commit abb5f36771cc4c05899b34000829a787572a8817 upstream. The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for. Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg") Cc: stable@vger.kernel.org Signed-off-by: Ben Morris Acked-by: Xin Long Link: https://patch.msgid.link/20260508001455.3137-1-joycathacker@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52ee0b2b85bcb6b27d5b127ab8c0bf30c4243ec5 Author: Alex Deucher Date: Tue Apr 28 10:42:49 2026 -0400 drm/amdgpu/pm: align Hawaii mclk workaround with radeon commit 1987c79b4fe5789dfa14423e78b5c25f6acf3e9d upstream. Align the hawaii mclk workaround with radeon and windows. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 9649528b637f668c5af9f2b83ca4ad8576ae2121) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 89680d757b1b8058dd894140809568b688b72086 Author: Alex Deucher Date: Mon Apr 27 11:38:58 2026 -0400 drm/amdgpu/pm: add missing revision check for CI commit 2a561b361b7681509710f3cfc3d95d54c87ac69f upstream. The ci_populate_all_memory_levels() workaround only applies to revision 0 SKUs. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 1db15ba8f72f400bbad8ae0ce24fafc43429d4bd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d4c56932d29773e278be6a65a5384a36c95b89a4 Author: John B. Moore Date: Mon Apr 27 16:06:28 2026 -0500 drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission commit 78d2e624fa073c14970aa097adcf3ea31c157a66 upstream. sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. Fixes: 2130f89ced2c ("drm/amdgpu: add SDMA v4.0 implementation (v2)") Reviewed-by: Christian König Signed-off-by: John B. Moore Signed-off-by: Alex Deucher (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ca032652ba06c9719d36de20d9004585c525cb2e Author: John B. Moore Date: Tue Apr 28 11:35:12 2026 -0500 drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ commit 7bbfb2559bcec39d1a4e1182d931a2046112c352 upstream. Remove the BUG_ON(flags & AMDGPU_FENCE_FLAG_64BIT) assertion from gfx_v9_0_ring_emit_fence_kiq(). The KIQ hardware supports 64-bit fence writes; the 32-bit writeback address constraint is an upper-layer convention, not a hardware limitation. The check serves no purpose and should not be present. Found by code inspection while investigating related BUG_ON assertions in the GFX and compute ring emission paths. Reviewed-by: Christian König Signed-off-by: John B. Moore Signed-off-by: Alex Deucher (cherry picked from commit 1b1101a46a426bb4328116bb5273c326a2780389) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 40df11255d71b02e20e70579f1b12b687e396e26 Author: Philip Yang Date: Mon Apr 27 09:30:23 2026 -0400 drm/amdgpu: zero-initialize GART table on allocation commit e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741 upstream. GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. Suggested-by: Felix Kuehling Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cc0d93c996950b7d10d9b8d634d9679821d5ca96 Author: Alex Deucher Date: Mon Apr 27 11:40:25 2026 -0400 drm/radeon: add missing revision check for CI commit 17223816498f7b117d138d18eb0eba63604dc74e upstream. The memory level workarounds only apply to revision 0 SKUs. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 127e056e2a82 ("drm/radeon: fix mclk vddc configuration for cards for hawaii") Fixes: 21b8a369046f ("drm/radeon: fix dram timing for certain hawaii boards") Fixes: 90b2fee35cb9 ("drm/radeon: fix dpm mc init for certain hawaii boards") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 4d8dcc14311515077062b5740f39f427075de5c9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fb07a0c9c8419164812e07274947f11b1d92dd61 Author: Alysa Liu Date: Tue Apr 21 10:18:28 2026 -0400 drm/amdkfd: validate SVM ioctl nattr against buffer size commit 045e0ff208f0838a246c10204105126611b267a1 upstream. Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. Reviewed-by: Amir Shetaia Signed-off-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 22922f7dae74409fc4bf0f1142710cb6b8ce8cc2 Author: Ashutosh Desai Date: Mon Apr 20 01:36:37 2026 +0000 drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() commit 3d4c2268bd7243c3780fe32bf24ff876da272acf upstream. drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check(). Fixes: 4c3dbb2c312c ("drm: Add GEM backed framebuffer library") Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Thomas Zimmermann Signed-off-by: Ashutosh Desai Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260420013637.457751-1-ashutoshdesai993@gmail.com Signed-off-by: Greg Kroah-Hartman commit 82c535eff05490c71153af57de9fe85502fcb5d5 Author: Benjamin Cheng Date: Tue Mar 24 16:25:56 2026 -0400 drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg commit b193019860d61e92da395eae2011f2f6716b182f upstream. Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 88411caee8f576d6b5abf6531232fcc0ce756dc5 Author: Benjamin Cheng Date: Wed Mar 25 09:09:27 2026 -0400 drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg commit 0a78f2bac1424deb7c9d5e09c6b8e849d8e8b648 upstream. Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2d66d1f5d8c0434e9a5ad21cc6eaf3a5e32141d5 Author: Benjamin Cheng Date: Mon Mar 30 15:01:27 2026 -0400 drm/amdgpu/vce: Prevent partial address patches commit de2a02cc28d6d5d37db07d00a9a684c754a5fd74 upstream. In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW. Signed-off-by: Benjamin Cheng Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5da6c6430be0acb25b4242bce0323fc514d4e3cf Author: Benjamin Cheng Date: Wed Mar 25 08:39:19 2026 -0400 drm/amdgpu: Add bounds checking to ib_{get,set}_value commit 66085e206431ef88ce36f53c1f53d570790ccc9e upstream. The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0944b20e9dfa2917bd70eb5b301cbb67fe54a718 Author: Johan Hovold Date: Tue Apr 14 15:43:15 2026 +0200 spi: mpc52xx: fix use-after-free on unbind commit 706b3dc2ac7a998c55e14b3fd2e8f934c367e6e0 upstream. The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free. Fixes: 984836621aad ("spi: mpc52xx: Add cancel_work_sync before module remove") Cc: stable@vger.kernel.org Cc: Pei Xiao Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-5-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit edcc5fd3b72647b38dbfa32f79c393ae6d6e8d6f Author: Johan Hovold Date: Tue Apr 21 15:02:10 2026 +0200 spi: orion: fix clock imbalance on registration failure commit 443cde0dc59c5d154156ac9f27a7dadef8ebc0c2 upstream. Make sure that the controller is not runtime suspended before disabling clocks on probe failure. Also restore the autosuspend setting. Fixes: 5c6786945b4e ("spi: spi-orion: add runtime PM support") Cc: stable@vger.kernel.org # 3.17 Cc: Russell King Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421130211.1537628-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 728cb3ee536d89508ddc1f577e5f7dab726b48f4 Author: Johan Hovold Date: Tue Apr 21 14:56:32 2026 +0200 spi: imx: fix runtime pm leak on probe deferral commit a1d50a37d3b1df84f536a982f692371039df4a48 upstream. Make sure to balance the runtime PM usage count before returning on probe failure (e.g. probe deferral) so that the controller can be suspended when a driver is later bound. Fixes: 43b6bf406cd0 ("spi: imx: fix runtime pm support for !CONFIG_PM") Cc: stable@vger.kernel.org # 5.10 Cc: Sascha Hauer Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421125632.1537235-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9c9a080647c90218a3884c1aa732da8c377d27ad Author: Johan Hovold Date: Fri Apr 10 10:17:32 2026 +0200 spi: mtk-nor: fix controller deregistration commit 76336f24934621db286cabb20b483773ee01dcaa upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 881d1ee9fe81 ("spi: add support for mediatek spi-nor controller") Cc: stable@vger.kernel.org # 5.7 Cc: Chuanhong Guo Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b22cb532e9cb0b3ca464713ab4c97a54e76719c3 Author: Haoxiang Li Date: Mon Jan 26 09:44:12 2026 +0800 media: omap3isp: drop the use count of v4l2 pipeline commit 9da49bd9d4224035cff39b40d7395310abb10201 upstream. In isp_video_open(), drop the use count of v4l2 pipeline if vb2_queue_init() fails. Fixes: 8fd390b89cc8 ("media: Split v4l2_pipeline_pm_use into v4l2_pipeline_pm_{get, put}") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a08f282bc5cc038d48bfd5cd0fe1768725d2e2d6 Author: Matthias Fend Date: Tue Mar 24 11:41:36 2026 +0100 media: i2c: ov08d10: fix image vertical start setting commit 5d150fa0f16096d736bd24d13e04495da5116fab upstream. The current settings for the "image vertical start" register appear to be incorrect. While this only results in an incorrect start line for native modes, this faulty setting causes actual problems in binning mode. At least on an i.MX8MP test system, only corrupted frames could be received. To correct this, the recommended settings from the reference register sets are used for all modes. Since this shifts the start by one line, the Bayer pattern also changes, which has also been corrected. Fixes: 7be91e02ed57 ("media: i2c: Add ov08d10 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Matthias Fend Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 17b1a68e6c5cf6b6c5e6bc060725195d648c094d Author: Wenmeng Liu Date: Fri Jan 23 17:19:55 2026 +0800 media: i2c: imx412: Assert reset GPIO during probe commit 8467c5ff5acae28513bc1e0af535e06b41b04344 upstream. Assert the reset GPIO before first power up. This avoids a mismatch where the first power up (when the reset GPIO defaults deasserted) differs from subsequent cycles. Signed-off-by: Wenmeng Liu Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 19f3d92fcf53064ec4e74c61c717c777e6691b56 Author: Sergey Shtylyov Date: Fri Feb 6 17:22:26 2026 +0300 media: dib8000: avoid division by 0 in dib8000_set_dds() commit dde3c37af95cd6fa301c4906f33d627bc9dd874c upstream. In dib8000_set_dds(), 1 << 26 (67108864) divided by e.g. 1 apparently can't fit into 16-bit variable unit_khz_dds_val, being truncated to 0; this will cause division by 0 while calling dprintk() with debugging enabled (via the module parameter). Use s32 instead of s16 to declare the variable, getting rid of the cast to u16 in the *else* branch as well... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 173a64cb3fcf ("[media] dib8000: enhancement") Cc: stable@vger.kernel.org Signed-off-by: Sergey Shtylyov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4f8116e70192c5b134245acc734e7f46321ce40b Author: Abdun Nihaal Date: Thu Mar 12 18:02:56 2026 +0530 media: pci: zoran: fix potential memory leak in zoran_probe() commit 8ea21435fe36fb853706f4935d78bc11beb63fb4 upstream. The memory allocated for codec in videocodec_attach() is not freed in one of the error paths, due to an incorrect goto label. Fix the label to free it on error. Fixes: 8f7cc5c0b0eb ("media: staging: media: zoran: introduce zoran_i2c_init") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2e455847b13552fafa039fff39d7a402da10f3f6 Author: Krishna Chomal Date: Fri Apr 3 13:31:55 2026 +0530 platform/x86: hp-wmi: Ignore backlight and FnLock events commit e8c597368b8500a824c639bfb5ed0044068c6870 upstream. On HP OmniBook 7 the keyboard backlight and FnLock keys are handled directly by the firmware. However, they still trigger WMI events which results in "Unknown key code" warnings in dmesg. Add these key codes to the keymap with KE_IGNORE to silence the warnings since no software action is needed. Tested-by: Artem S. Tashkinov Reported-by: Artem S. Tashkinov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221181 Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260403080155.169653-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 23dee5990d2c27ed79567fd61ccfe6876768531a Author: Wang Jun <1742789905@qq.com> Date: Mon Mar 16 20:24:01 2026 +0800 media: saa7164: add ioremap return checks and cleanups commit d51c60a498e83c9a79884c8e420f97e3885c9583 upstream. Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures. Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Cc: stable@vger.kernel.org Signed-off-by: Wang Jun <1742789905@qq.com> Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3365eb2fa0047e1e7304d56bb5c9d6402d746533 Author: Johan Hovold Date: Wed Apr 8 09:30:55 2026 +0200 regulator: bd9571mwv: fix OF node reference imbalance commit 8498100ee1d00422b8c5b161b3e332278b92a59a upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: e85c5a153fe2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver") Cc: stable@vger.kernel.org # 4.12 Cc: Marek Vasut Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-8-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0b1be3cced101a1dd747b05899a81e8d5baa0d2b Author: Johan Hovold Date: Wed Apr 8 09:30:54 2026 +0200 regulator: act8945a: fix OF node reference imbalance commit 0d15ce31375ccef4162f960b34547a821b7619d2 upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 38c09961048b ("regulator: act8945a: add regulator driver for ACT8945A") Cc: stable@vger.kernel.org # 4.6 Cc: Wenyou Yang Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-7-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 70f179c3cb018856bcde61a01471b83817c437fc Author: Oliver Neukum Date: Wed Feb 11 19:06:21 2026 +0100 media: rc: streamzap: Error handling in probe commit 42844992664f03ef9f930e64f7370fa481e9c267 upstream. If submitting the URB fails, the device will be unusable. Probe() must fail. Fixes: 7a569f524dd36 ("V4L/DVB: IR/streamzap: functional in-kernel decoding") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0ea67a135335e51be50e83ee4cc99560b8b89c25 Author: Oliver Neukum Date: Wed Feb 11 19:09:44 2026 +0100 media: rc: xbox_remote: heed DMA restrictions commit e280d1e5e3f2595bbb43fe6e1bce00c59a43c0ff upstream. The buffer for IO must not be part of the device structure because that violates the DMA coherency rules. Fixes: 02d32bdad3123 ("media: rc: add driver for Xbox DVD Movie Playback Kit") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6389af2a478e86d82d206ecd46da2b0bef189004 Author: Johan Hovold Date: Wed Apr 8 09:30:51 2026 +0200 regulator: max77650: fix OF node reference imbalance commit 2edaf5f7ada0ab5c9ec1f0836bd19779a8d85262 upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: bcc61f1c44fd ("regulator: max77650: add regulator support") Cc: stable@vger.kernel.org # 5.1 Reviewed-by: Bartosz Golaszewski Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-4-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ceb1b5f910e58986ea544ff8c9c2f23ae9a52414 Author: Sakari Ailus Date: Thu Feb 26 15:10:54 2026 +0200 staging: media: atomisp: Disallow all private IOCTLs commit 2b7eb2c5dc72f0fc954ac4aa155f9e285e937f7c upstream. Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy. Reported-by: Soufiane Dani Closes: https://lore.kernel.org/linux-staging/20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com/ Cc: stable@vger.kernel.org Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d1b3811c6b0f67fb7f0acfe09bf8244aa8b12465 Author: Alexander Koskovich Date: Thu Mar 12 17:16:20 2026 +0000 media: i2c: ov8856: free control handler on error in ov8856_init_controls() commit f75e160745663ce9b13362ae6e90bd439c58df69 upstream. The control handler wasn't freed if adding controls failed, add an error exit label and convert the existing error return to use it. Fixes: 879347f0c258 ("media: ov8856: Add support for OV8856 sensor") Cc: stable@vger.kernel.org Signed-off-by: Alexander Koskovich Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6c9bcd5c2e2eed91e59628c88aea7ed22daad0a1 Author: Ricardo Ribalda Date: Mon Mar 9 15:01:54 2026 +0000 media: uvcvideo: Enable VB2_DMABUF for metadata stream commit fbac03467e53d8d72e5099c03df26d9adae11416 upstream. The UVC driver has two video streams, one for the frames and another one for the metadata. Both streams share most of the codebase, but only the data stream declares support for DMABUF transfer mode. I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM and the frames looked correct. This patch announces the support for DMABUF for the metadata stream. This is useful for apps/HALs that only want to support DMABUF. Cc: stable@vger.kernel.org Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2d81c27514f20db4be4ad467a906e863eb96aac5 Author: Paul E. McKenney Date: Wed Jul 24 16:51:52 2024 -0700 exit: Sleep at TASK_IDLE when waiting for application core dump commit b8e753128ed074fcb48e9ceded940752f6b1c19f upstream. Currently, the coredump_task_exit() function sets the task state to TASK_UNINTERRUPTIBLE|TASK_FREEZABLE, which usually works well. But a combination of large memory and slow (and/or highly contended) mass storage can cause application core dumps to take more than two minutes, which can cause check_hung_task(), which is invoked by check_hung_uninterruptible_tasks(), to produce task-blocked splats. There does not seem to be any reasonable benefit to getting these splats. Furthermore, as Oleg Nesterov points out, TASK_UNINTERRUPTIBLE could be misleading because the task sleeping in coredump_task_exit() really is killable, albeit indirectly. See the check of signal->core_state in prepare_signal() and the check of fatal_signal_pending() in dump_interrupted(), which bypass the normal unkillability of TASK_UNINTERRUPTIBLE, resulting in coredump_finish() invoking wake_up_process() on any threads sleeping in coredump_task_exit(). Therefore, change that TASK_UNINTERRUPTIBLE to TASK_IDLE. Reported-by: Anhad Jai Singh Signed-off-by: Paul E. McKenney Acked-by: Oleg Nesterov Cc: Jens Axboe Cc: Christian Brauner Cc: Andrew Morton Cc: "Matthew Wilcox (Oracle)" Cc: Chris Mason Cc: Rik van Riel Cc: Paul Menzel Signed-off-by: Greg Kroah-Hartman commit 74cbeeca4f16823ba58c882e1d8b836c0e39c93d Author: Zhiguo Niu Date: Tue May 12 15:50:10 2026 +0800 f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic [ Upstream commit 39868685c2a94a70762bc6d77dc81d781d05bff5 ] The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org Cc: Daeho Jeong Fixes: bff139b49d9f ("f2fs: handle decompress only post processing in softirq") Signed-off-by: Zhiguo Niu Signed-off-by: Baocong Liu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [ No changes are made to the code logic; F2FS_I_SB(dic->inode) is replaced with dic->sbi in v6.1. ] Signed-off-by: Bin Lan Signed-off-by: Sasha Levin commit 02449fa6235529213f113a16101468808c65d760 Author: Zhiguo Niu Date: Tue May 12 15:50:09 2026 +0800 f2fs: compress: change the first parameter of page_array_{alloc,free} to sbi [ Upstream commit 8e2a9b656474d67c55010f2c003ea2cf889a19ff ] No logic changes, just cleanup and prepare for fixing the UAF issue in f2fs_free_dic. Signed-off-by: Zhiguo Niu Signed-off-by: Baocong Liu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Bin Lan Signed-off-by: Sasha Levin commit c41d6aebecaccde87aba4da4a195fa78ee211cde Author: Huacai Chen Date: Mon May 4 09:00:20 2026 +0800 LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup commit 49f33840dcc907d21313d369e34872880846b61c upstream. When firmware enables 64-bit PCI host bridge support, some root bridges already provide valid 64-bit mem resource windows through ACPI. In this case, the LoongArch-specific mem resource high-bits fixup in acpi_prepare_root_resources() should not be applied unconditionally. Otherwise, the kernel may override the native resource layout derived from firmware, and later BAR assignment can fail to place device BARs into the intended 64-bit address space correctly. Add a per-root-bridge ACPI flag, PCIH, and evaluate it from the current root bridge device scope. When PCIH is set, skip the mem resource high- bits fixup path and let the kernel use the firmware-provided resource description directly. When PCIH is absent or cleared, keep the existing behavior and continue filling the high address bits from the host bridge address. This makes the behavior per-root-bridge configurable and avoids breaking valid 64-bit BAR space allocation on bridges whose 64-bit windows have already been fully described by firmware. Cc: stable@vger.kernel.org Suggested-by: Chao Li Tested-by: Dongyan Qian Signed-off-by: Dongyan Qian Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit bfde8accc3e3260c0ecbb8cc34361739e1e16f31 Author: Wentao Guan Date: Mon May 4 09:00:20 2026 +0800 LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() commit 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e upstream. The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU: lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ... Add a default switch case to fix the panic as below: Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4 Cc: stable@vger.kernel.org Fixes: 95db0c9f526d ("LoongArch: Workaround LS2K/LS7A GPU DMA hang bug") Link: https://gist.github.com/opsiff/ebf2dac51b4013d22462f2124c55f807 Link: https://gist.github.com/opsiff/a62f2a73db0492b3c49bf223a339b133 Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit ecd0ad5737629905e18c5ac953cee9a78dddf51f Author: David Woodhouse Date: Tue Apr 7 21:27:02 2026 +0100 KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value commit a0e6ae45af17e8b27958830595799c702ffbab8d upstream. The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3 extract the revision field from 'reg' (the current IIDR value read back from the emulated distributor) instead of 'val' (the value userspace is trying to write). This means userspace can never actually change the implementation revision — the extracted value is always the current one. Fix the FIELD_GET to use 'val' so that userspace can select a different revision for migration compatibility. Fixes: 49a1a2c70a7f ("KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision") Signed-off-by: David Woodhouse Link: https://patch.msgid.link/20260407210949.2076251-2-dwmw2@infradead.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 42fa077ede5ca4835cfc19fb2d8532475feefb5b Author: Yongpeng Yang Date: Mon Mar 23 20:06:22 2026 +0800 f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks() commit eb2ca3ca983551a80e16a4a25df5a4ce59df8484 upstream. When f2fs_map_blocks()->f2fs_map_blocks_cached() hits the read extent cache, map->m_multidev_dio is not updated, which leads to incorrect multidevice information being reported by trace_f2fs_map_blocks(). This patch updates map->m_multidev_dio in f2fs_map_blocks_cached() when the read extent cache is hit. Cc: stable@kernel.org Fixes: 0094e98bd147 ("f2fs: factor a f2fs_map_blocks_cached helper") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 843b267eb098448554a996359e8cad8dc7ffef55 Author: Yongpeng Yang Date: Mon Mar 23 20:06:24 2026 +0800 f2fs: fix fiemap boundary handling when read extent cache is incomplete commit 95e159ad3e52f7478cfd22e44ec37c9f334f8993 upstream. f2fs_fiemap() calls f2fs_map_blocks() to obtain the block mapping a file, and then merges contiguous mappings into extents. If the mapping is found in the read extent cache, node blocks do not need to be read. However, in the following scenario, a contiguous extent can be split into two extents: $ dd if=/dev/zero of=data.128M bs=1M count=128 $ losetup -f data.128M $ mkfs.f2fs /dev/loop0 -f $ mount -o mode=lfs /dev/loop0 /mnt/f2fs/ $ cd /mnt/f2fs/ $ dd if=/dev/zero of=data.72M bs=1M count=72 && sync $ dd if=/dev/zero of=data.4M bs=1M count=4 && sync $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=2 conv=notrunc && sync $ echo 3 > /proc/sys/vm/drop_caches $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync $ f2fs_io fiemap 0 1024 data.4M Fiemap: offset = 0 len = 1024 logical addr. physical addr. length flags 0 0000000000000000 0000000006400000 0000000000200000 00001000 1 0000000000200000 0000000006600000 0000000000200000 00001001 Although the physical addresses of the ranges 0～2MB and 2M～4MB are contiguous, the mapping for the 2M～4MB range is not present in memory. When the physical addresses for the 0～2MB range are updated, no merge happens because the adjacent mapping is missing from the in-memory cache. As a result, fiemap reports two separate extents instead of a single contiguous one. The root cause is that the read extent cache does not guarantee that all blocks of an extent are present in memory. Therefore, when the extent length returned by f2fs_map_blocks_cached() is smaller than maxblocks, the remaining mappings are retrieved via f2fs_get_dnode_of_data() to ensure correct fiemap extent boundary handling. Cc: stable@kernel.org Fixes: cd8fc5226bef ("f2fs: remove the create argument to f2fs_map_blocks") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 10a2beeca8f649627cab7b52f738f8ae717ac7fb Author: Cen Zhang Date: Wed Mar 18 15:32:53 2026 +0800 f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode() commit 5471834a96fb697874be2ca0b052e74bcf3c23d1 upstream. f2fs_update_inode() reads inode->i_blocks without holding i_lock to serialize it to the on-disk inode, while concurrent truncate or allocation paths may modify i_blocks under i_lock. Since blkcnt_t is u64, this risks torn reads on 32-bit architectures. Following the approach in ext4_inode_blocks_set(), add READ_ONCE() to prevent potential compiler-induced tearing. Fixes: 19f99cee206c ("f2fs: add core inode operations") Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit e792cfb6aeaf65612cdf8e3ac431d65e66283654 Author: Gang Yan Date: Mon Apr 27 21:54:34 2026 +0200 mptcp: fix scheduling with atomic in timestamp sockopt commit b5c52908d52c6c8eb8933264aa6087a0600fd892 upstream. Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-2-7432b7f279fa@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 48657a3d6157afadae800a82d58b47695f4a60f0 Author: Gang Yan Date: Mon Apr 27 21:54:33 2026 +0200 mptcp: sockopt: set timestamp flags on subflow socket, not msk commit 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 upstream. Both mptcp_setsockopt_sol_socket_tstamp() and mptcp_setsockopt_sol_socket_timestamping() iterate over subflows, acquire the subflow socket lock, but then erroneously pass the MPTCP msk socket to sock_set_timestamp() / sock_set_timestamping() instead of the subflow ssk. As a result, the timestamp flags are set on the wrong socket and have no effect on the actual subflows. Pass ssk instead of sk to both helpers. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-1-7432b7f279fa@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 35f7fb836a77dedfb5e1b98ceb68ec79d542da4e Author: Shardul Bankar Date: Fri May 1 21:35:35 2026 +0200 mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure commit a6da02d4c00fdda2417e42ad2b762a9209e6cc49 upstream. When HMAC validation fails on a received ACK + MP_JOIN in subflow_syn_recv_sock(), the subflow is reset with reason MPTCP_RST_EPROHIBIT ("Administratively prohibited"). This is incorrect: HMAC validation failure is an MPTCP protocol-level error, not an administrative policy denial. The mirror site on the client, in subflow_finish_connect(), already uses MPTCP_RST_EMPTCP ("MPTCP-specific error") for the same kind of HMAC failure on the SYN/ACK + MP_JOIN. Use the same reason on the server side for symmetry and accuracy. Suggested-by: Matthieu Baerts (NGI0) Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-2-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit aa986dcee4e220d18e31c29ebad0ae3ecff9283f Author: Shardul Bankar Date: Fri May 1 21:35:34 2026 +0200 mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure commit c4a99a921949cddc590b22bb14eeb23dffcc3ba6 upstream. In subflow_finish_connect(), HMAC validation of the server's HMAC in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was wrong on ACK + MP_JOIN") on failure. The function processes the SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter ("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not incremented anywhere in the tree. The mirror site on the server, subflow_syn_recv_sock(), already uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC at the SYN/ACK validation site so each counter reflects the packet whose HMAC actually failed. Suggested-by: Matthieu Baerts (NGI0) Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-1-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3a231c34c5bc3d3cfc850b877758ec9fdaa8a483 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:43 2026 -0300 RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path commit e38e86995df27f1f854063dab1f0c6a513db3faf upstream. Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free. Cc: stable@vger.kernel.org Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 Link: https://patch.msgid.link/r/10-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 599cfdf44c1701c581cd4a21f1e1e03f8dc3840b Author: Michael Bommarito Date: Tue Apr 14 07:15:55 2026 -0400 RDMA/rxe: Reject unknown opcodes before ICRC processing commit 4c6f86d85d03cdb33addce86aa69aa795ca6c47a upstream. Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and "rdma link add"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs. Cc: stable@vger.kernel.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260414111555.3386793-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 27b6eb1f27fda9bdd5cae028e396758cdf525845 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:42 2026 -0300 RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() commit 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba upstream. Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL. Cc: stable@vger.kernel.org Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 Link: https://patch.msgid.link/r/9-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:44 2026 -0300 RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() commit c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c upstream. Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free(). Cc: stable@vger.kernel.org Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=8 Link: https://patch.msgid.link/r/11-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit a3881b09648a3d433a3d69aebe0820df499b4f97 Author: André Draszik Date: Mon Mar 2 13:32:05 2026 +0000 power: supply: max17042: avoid overflow when determining health commit 9a44949da669708f19d29141e65b3ac774d08f5a upstream. If vmax has the default value of INT_MAX (e.g. because not specified in DT), battery health is reported as over-voltage. This is because adding any value to vmax (the vmax tolerance in this case) causes it to wrap around, making it negative and smaller than the measured battery voltage. Avoid that by using size_add(). Fixes: edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_* properties support") Cc: stable@vger.kernel.org Signed-off-by: André Draszik Link: https://patch.msgid.link/20260302-max77759-fg-v3-6-3c5f01dbda23@linaro.org Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 48cafda2d5d108859ebc6d1c57a00f72b984e131 Author: Lukas Wunner Date: Fri Mar 27 10:56:43 2026 +0100 PCI/AER: Stop ruling out unbound devices as error source commit 1ab4a3c805084d752ec571efc78272295a9f2f74 upstream. When searching for the error source, the AER driver rules out devices whose enable_cnt is zero. This was introduced in 2009 by commit 28eb27cf0839 ("PCI AER: support invalid error source IDs") without providing a rationale. Drivers typically call pci_enable_device() on probe, hence the enable_cnt check essentially filters out unbound devices. At the time of the commit, drivers had to opt in to AER by calling pci_enable_pcie_error_reporting() and so any AER-enabled device could be assumed to be bound to a driver. The check thus made sense because it allowed skipping config space accesses to devices which were known not to be the error source. But since 2022, AER is universally enabled on all devices when they are enumerated, cf. commit f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native"). Errors may very well be reported by unbound devices, e.g. due to link instability. By ruling them out as error source, errors reported by them are neither logged nor cleared. When they do get bound and another error occurs, the earlier error is reported together with the new error, which may confuse users. Stop doing so. Fixes: f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Stefan Roese Cc: stable@vger.kernel.org # v6.0+ Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 492ac19792fa3348414bf3fae4bb8ee43c8266df Author: Shuai Xue Date: Wed Feb 11 20:46:24 2026 +0800 PCI/AER: Clear only error bits in PCIe Device Status commit a8aeea1bf3c80cc87983689e0118770e019bd4f3 upstream. Currently, pcie_clear_device_status() clears the entire PCIe Device Status register (PCI_EXP_DEVSTA) by writing back the value read from the register, which affects not only the error status bits but also other writable bits. According to PCIe r7.0, sec 7.5.3.5, this register contains: - RW1C error status bits (CED, NFED, FED, URD at bits 0-3): These are the four error status bits that need to be cleared. - Read-only bits (AUXPD at bit 4, TRPND at bit 5): Writing to these has no effect. - Emergency Power Reduction Detected (bit 6): A RW1C non-error bit introduced in PCIe r5.0 (2019). This is currently the only writable non-error bit in the Device Status register. Unconditionally clearing this bit can interfere with other software components that rely on this power management indication. - Reserved bits (RsvdZ): These bits are required to be written as zero. Writing 1s to them (as the current implementation may do) violates the specification. To prevent unintended side effects, modify pcie_clear_device_status() to only write 1s to the four error status bits (CED, NFED, FED, URD), leaving the Emergency Power Reduction Detected bit and reserved bits unaffected. Fixes: ec752f5d54d7 ("PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL") Suggested-by: Lukas Wunner Signed-off-by: Shuai Xue Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 2be11faf79e49fb8250a181ff0b4d2b2f084af83 Author: Zisen Ye Date: Sat May 2 18:48:36 2026 +0800 smb/client: fix out-of-bounds read in symlink_data() commit d62b8d236fab503c6fec1d3e9a38bea71feaca20 upstream. Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read. Link: https://lore.kernel.org/linux-cifs/297d8d9b-adf7-42fd-a1c2-5b1f230032bc@chenxiaosong.com/ Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: Stable@vger.kernel.org Signed-off-by: Zisen Ye Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bdb5425b2cad1f8aa8ed2a7590d3df7fdee7e794 Author: Vasily Gorbik Date: Fri Apr 17 14:33:43 2026 +0200 s390/debug: Reject zero-length input in debug_input_flush_fn() commit e14622a7584f9608927c59a7d6ae4a0999dc545e upstream. debug_input_flush_fn() always copies one byte from the userspace buffer with copy_from_user() regardless of the supplied write length. A zero-length write therefore reads one byte beyond the caller's buffer. If the stale byte happens to be '-' or a digit the debug log is silently flushed. With an unmapped buffer the call returns -EFAULT. Reject zero-length writes before copying from userspace. Cc: stable@vger.kernel.org # v5.10+ Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit b6296ff2475fc95ee6ea1b528c4b385302808186 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:48 2026 -0300 RDMA/hns: Fix unlocked call to hns_roce_qp_remove() commit 0c99acbc8b6c6dd526ae475a48ee1897b61072fb upstream. Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use. Cc: stable@vger.kernel.org Fixes: e088a685eae9 ("RDMA/hns: Support rq record doorbell for the user space") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=9 Link: https://patch.msgid.link/r/15-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 8ae6c15fc473c9ad03b0173330cce9a092c76154 Author: Ilya Maximets Date: Fri May 1 01:38:37 2026 +0200 openvswitch: vport: fix self-deadlock on release of tunnel ports commit aa69918bd418e700309fdd08509dba324fb24296 upstream. vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released. Fixes: 6931d21f87bc ("openvswitch: defer tunnel netdev_put to RCU release") Cc: stable@vger.kernel.org Acked-by: Eelco Chaudron Signed-off-by: Ilya Maximets Acked-by: Aaron Conole Link: https://patch.msgid.link/20260430233848.440994-2-i.maximets@ovn.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a696fbbd5240b4ac9b166f7bd4c550882ff543f1 Author: Chaitanya Kulkarni Date: Wed Apr 8 17:56:47 2026 -0700 nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free commit aade8abd8b868b6ffa9697aadaea28ec7f65bee6 upstream. nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- nvmet_add_async_event queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306583] ? __flush_work+0x20b/0x530 [ 5233.306585] __flush_work+0x268/0x530 [ 5233.306588] ? __pfx_wq_barrier_func+0x10/0x10 [ 5233.306594] ? xen_error_entry+0x30/0x60 [ 5233.306600] nvmet_ctrl_free+0x140/0x310 [nvmet] [ 5233.306617] nvmet_cq_put+0x74/0x90 [nvmet] [ 5233.306629] nvmet_tcp_release_queue_work+0x19f/0x360 [nvmet_tcp] [ 5233.306634] process_one_work+0x206/0x6e0 [ 5233.306640] worker_thread+0x184/0x320 [ 5233.306643] ? __pfx_worker_thread+0x10/0x10 [ 5233.306646] kthread+0xf1/0x130 [ 5233.306648] ? __pfx_kthread+0x10/0x10 [ 5233.306651] ret_from_fork+0x355/0x450 [ 5233.306653] ? __pfx_kthread+0x10/0x10 [ 5233.306656] ret_from_fork_asm+0x1a/0x30 [ 5233.306664] There is also no need to flush async_event_work from controller teardown. The admin queue teardown already fails outstanding AER requests before the final controller put :- nvmet_sq_destroy(admin sq) nvmet_async_events_failall(ctrl) The controller has already been removed from the subsystem list before nvmet_ctrl_free() quiesces outstanding work. Replace flush_work() with cancel_work_sync() so a pending async_event_work item is canceled and a running instance is waited on without recursing into the same workqueue. Fixes: 06406d81a2d7 ("nvmet: cancel fatal error and flush async work before free controller") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit a456f2a218d72c9cce2c15a6fb8e5cd44c3c6bec Author: Fedor Pchelkin Date: Wed Apr 8 17:18:14 2026 +0300 nvme-apple: drop invalid put of admin queue reference count commit ba9d308ccd6732dd97ed8080d834a4a89e758e14 upstream. Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the admin queue reference ->put call into nvme_free_ctrl() - a controller device release callback performed for every nvme driver doing nvme_init_ctrl(). nvme-apple sets refcount of the admin queue to 1 at allocation during the probe function and then puts it twice now: nvme_free_ctrl() blk_put_queue(ctrl->admin_q) // #1 ->free_ctrl() apple_nvme_free_ctrl() blk_put_queue(anv->ctrl.admin_q) // #2 Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra queue reference") which intended to drop taking an extra admin queue reference. Looks like at that moment it accidentally fixed a refcount leak, which existed since the driver's introduction. There were two ->get calls at driver's probe function and a single ->put inside apple_nvme_free_ctrl(). However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") the refcount is imbalanced again. Fix it by removing extra ->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to the same device, so use ctrl->dev directly for simplification. Compile tested only. Found by Linux Verification Center (linuxtesting.org). Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Fedor Pchelkin Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 553e32adfa1a96b217651139a3f8c3b92b9984ac Author: Junrui Luo Date: Thu Apr 16 11:39:56 2026 +0800 md/raid10: fix divide-by-zero in setup_geo() with zero far_copies commit 9aa6d860b0930e2f72795665c42c44252a558a0c upstream. setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the "improved" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero. Fixes: 475901aff158 ("MD RAID10: Improve redundancy for 'far' and 'offset' algorithms (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://lore.kernel.org/linux-raid/SYBPR01MB7881A5E2556806CC1D318582AF232@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 38fdf04c602d52c42c67fc1617211492753b7e8b Author: Raphael Zimmer Date: Tue Apr 21 10:27:01 2026 +0200 libceph: Fix slab-out-of-bounds access in auth message processing commit 1c439de70b1c3eb3c6bffa8245c16b9fc318f114 upstream. If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 908a76f0b1038035e6ebb4f2293ce079f92e0a02 Author: Michael Bommarito Date: Sun Apr 19 17:21:55 2026 -0400 isofs: validate block number from NFS file handle in isofs_export_iget commit 24376458138387fb251e782e624c7776e9826796 upstream. isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 ("isofs: Prevent the use of too small fid") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line. Fixes: 0405d4b63d08 ("isofs: Prevent the use of too small fid") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419212155.2169382-3-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9 Author: Michael Bommarito Date: Sun Apr 19 17:21:54 2026 -0400 isofs: validate Rock Ridge CE continuation extent against volume size commit a36d990f591320e9dd379ab30063ebfe91d47e1f upstream. rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. Fixes: f54e18f1b831 ("isofs: Fix infinite looping over CE entries") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419212155.2169382-2-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 4733ff424391403c9b791b0591f18799ca0c24a9 Author: Eric Biggers Date: Thu Feb 5 20:59:21 2026 -0800 dm-verity-fec: correctly reject too-small hash devices commit 4355142245f7e55336dcc005ec03592df4d546f8 upstream. Fix verity_fec_ctr() to reject too-small hash devices by correctly taking hash_start into account. Note that this is necessary because dm-verity doesn't call dm_bufio_set_sector_offset() on the hash device's bufio client (v->bufio). Thus, dm_bufio_get_device_size(v->bufio) returns a size relative to 0 rather than hash_start. An alternative fix would be to call dm_bufio_set_sector_offset() on v->bufio, but then all the code that reads from the hash device would have to be adjusted accordingly. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 378f0551b898a3a0a6c709af6659177afb57f843 Author: Eric Biggers Date: Thu Feb 5 20:59:20 2026 -0800 dm-verity-fec: correctly reject too-small FEC devices commit 2b14e0bb63cc671120e7791658f5c494fc66d072 upstream. Fix verity_fec_ctr() to reject too-small FEC devices by correctly computing the number of parity blocks as 'f->rounds * f->roots'. Previously it incorrectly used 'div64_u64(f->rounds * f->roots, v->fec->roots << SECTOR_SHIFT)' which is a much smaller value. Note that the units of 'rounds' are blocks, not bytes. This matches the units of the value returned by dm_bufio_get_device_size(), which are also blocks. A later commit will give 'rounds' a clearer name. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 526ff9126a0ae087b65726e1faf31114c718020d Author: Mikulas Patocka Date: Thu Apr 9 17:49:58 2026 +0200 dm: fix a buffer overflow in ioctl processing commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson Signed-off-by: Mikulas Patocka Reviewed-by: Bryn M. Reeves Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 462f4bb5101b829ede599e3673f82b7b5dd2dabc Author: Mikulas Patocka Date: Mon Mar 16 15:04:15 2026 +0100 dm: don't report warning when doing deferred remove commit b7cce3e2cca9cd78418f3c3784474b778e7996fe upstream. If dm_hash_remove_all was called from dm_deferred_remove, it would write a warning "remove_all left %d open device(s)" if there are some other devices active. The warning is bogus, so let's disable it in this case. Signed-off-by: Mikulas Patocka Reported-by: Zdenek Kabelac Cc: stable@vger.kernel.org Fixes: 2c140a246dc0 ("dm: allow remove to be deferred") Signed-off-by: Greg Kroah-Hartman commit f06f6aededd792a754cd677c02b3d3016d868c2c Author: Mikulas Patocka Date: Mon Apr 20 19:56:44 2026 +0200 dm-thin: fix metadata refcount underflow commit 09a65adc7d8bbfce06392cb6d375468e2728ead5 upstream. There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared. Signed-off-by: Mikulas Patocka Fixes: 3241b1d3e0aa ("dm: add persistent data library") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ae6d6e31ceb72b7697c28a528e4923c08e3c2ef5 Author: Guangshuo Li Date: Wed Apr 1 18:56:19 2026 +0800 btrfs: fix double free in create_space_info() error path commit 3f487be81292702a59ea9dbc4088b3360a50e837 upstream. When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup. Fixes: a11224a016d6d ("btrfs: fix memory leaks in create_space_info() error paths") CC: stable@vger.kernel.org # 6.19+ Reviewed-by: Qu Wenruo Signed-off-by: Guangshuo Li Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dccbd2818294c5cc684e1d31b6c5b44c9bdd0656 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:07 2026 +0000 ASoC: qcom: q6apm: remove child devices when apm is removed commit 4a0e1bcc98f7281d1605768bd2fe71eacc34f9b7 upstream. looks like q6apm driver does not remove the child driver q6apm-dai and q6apm-bedais when the this driver is removed. Fix this by depopulating them in remove callback. With this change when the dsp is shutdown all the devices associated with q6apm will now be removed. Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit af9cc7c622e596455c5190e6ef53c5b40ea7a90d Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:09 2026 +0000 ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens commit 69acc488aaf39d0ddf6c3cf0e47c1873d39919a2 upstream. As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening. Fixes: be1fae62cf25 ("ASoC: q6apm-lpass-dai: close graph on prepare errors") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-5-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1120adc99c9c36fd07f995960f9b3312cf182f1d Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:10 2026 +0000 ASoC: qcom: q6apm-dai: reset queue ptr on trigger stop commit cab45ab95ce7600fc0ff84585c77fd45b7b0d67c upstream. Reset queue pointer on SNDRV_PCM_TRIGGER_STOP event to be inline with resetting appl_ptr. Without this we will end up with a queue_ptr out of sync and driver could try to send data that is not ready yet. Fix this by resetting the queue_ptr. Fixes: 3d4a4411aa8bb ("ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-6-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 269eeca516918ba2f3331468791df27758f2439e Author: Cássio Gabriel Date: Mon Apr 27 23:38:41 2026 -0300 ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error commit 13d30682e8dee191ac04e93642f0372a723e8b0c upstream. If byt_wm5102_prepare_and_enable_pll1() fails in the SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after clk_prepare_enable(priv->mclk) without disabling the clock again. This leaks an MCLK enable reference on failed power-up attempts. Add the missing clk_disable_unprepare() on the error path, matching the unwind used by the other Intel platform_clock_control() implementations. Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Cezary Rojewski Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260427-bytcr-wm5102-mclk-leak-v1-1-02b96d08e99c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b8396901d66ab6ddb0bc89e698b7983316b1af3 Author: Joseph Salisbury Date: Mon Mar 16 14:05:45 2026 -0400 ASoC: fsl_easrc: fix comment typo commit 804dce6c73fdfa44184ee4e8b09abad7f5da408f upstream. The file contains a spelling error in a source comment (funciton). Typos in comments reduce readability and make text searches less reliable for developers and maintainers. Replace 'funciton' with 'function' in the affected comment. This is a comment-only cleanup and does not change behavior. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: Joseph Salisbury Link: https://patch.msgid.link/20260316180545.144032-1-joseph.salisbury@oracle.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 26625db13741edb4eb2a7b7259d22f5e9ed74f8f Author: Tommaso Soncin Date: Wed Apr 29 18:08:57 2026 +0200 ASoC: amd: yc: Add HP OMEN Gaming Laptop 16-ap0xxx product line in quirk table commit d63c219b7ff39f897da10c160a2edef76320f16c upstream. Add a DMI quirk for the HP OMEN Gaming Laptop 16-ap0xxx line fixing the issue where the internal microphone was not detected. Cc: stable@vger.kernel.org Signed-off-by: Tommaso Soncin Link: https://patch.msgid.link/20260429160858.538986-1-soncintommaso@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit baf93fdddd58c79f746f72464fa2056f77ddb76b Author: Shrikanth Hegde Date: Wed Mar 11 11:47:09 2026 +0530 cpuidle: powerpc: avoid double clear when breaking snooze commit 64ed1e3e728afb57ba9acb59e69de930ead847d9 upstream. snooze_loop is done often in any system which has fair bit of idle time. So it qualifies for even micro-optimizations. When breaking the snooze due to timeout, TIF_POLLING_NRFLAG is cleared twice. Clearing the bit invokes atomics. Avoid double clear and thereby avoid one atomic write. dev->poll_time_limit indicates whether the loop was broken due to timeout. Use that instead of defining a new variable. Fixes: 7ded429152e8 ("cpuidle: powerpc: no memory barrier after break from idle") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Shrikanth Hegde Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260311061709.1230440-1-sshegde@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 9ed9b580a814773482c0a4f1be045636e68cc109 Author: Conor Dooley Date: Tue Feb 24 09:35:25 2026 +0000 clk: microchip: mpfs-ccc: fix out of bounds access during output registration commit 2f7ae8ab6aa73daaf080d5332110357c29df9c36 upstream. UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem. Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support") CC: stable@vger.kernel.org Reviewed-by: Brian Masney Signed-off-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman commit 4ca90deeca1c7dd72c1c380ba8143565516def2d Author: Johan Hovold Date: Tue Apr 14 15:43:19 2026 +0200 spi: topcliff-pch: fix use-after-free on unbind commit 9d72732fe70c11424bc90ed466c7ccfa58b42a9a upstream. Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind Fixes: c37f3c2749b5 ("spi/topcliff_pch: DMA support") Cc: stable@vger.kernel.org # 3.1 Cc: Tomoya MORINAGA Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-9-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4bc5dcbdc2c1dc8bb58cfb80c13ba5c0912e775e Author: Thorsten Blum Date: Sat Mar 7 11:24:21 2026 +0100 thermal/drivers/sprd: Fix raw temperature clamping in sprd_thm_rawdata_to_temp commit b3414148bbc1f9cd56217e58a558c6ac4fd1b4a6 upstream. The raw temperature data was never clamped to SPRD_THM_RAW_DATA_LOW or SPRD_THM_RAW_DATA_HIGH because the return value of clamp() was not used. Fix this by assigning the clamped value to 'rawdata'. Casting SPRD_THM_RAW_DATA_LOW and SPRD_THM_RAW_DATA_HIGH to u32 is also redundant and can be removed. Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Thorsten Blum Signed-off-by: Daniel Lezcano Reviewed-by: Baolin Wang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260307102422.306055-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 69a6e5c6962caecdaa7d4745dee10413fd9ea89a Author: Thorsten Blum Date: Sat Mar 7 11:24:20 2026 +0100 thermal/drivers/sprd: Fix temperature clamping in sprd_thm_temp_to_rawdata commit 83c0f9a5d679a6f8d84fc49b2f62ea434ccab4b6 upstream. The temperature was never clamped to SPRD_THM_TEMP_LOW or SPRD_THM_TEMP_HIGH because the return value of clamp() was not used. Fix this by assigning the clamped value to 'temp'. Casting SPRD_THM_TEMP_LOW and SPRD_THM_TEMP_HIGH to int is also redundant and can be removed. Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Thorsten Blum Signed-off-by: Daniel Lezcano Reviewed-by: Baolin Wang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260307102422.306055-1-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 3dede76d525919bb966f9213e131af685de5ff99 Author: Michael Bommarito Date: Mon Apr 13 17:12:40 2026 -0400 udf: reject descriptors with oversized CRC length commit 55d41b0a20128e86b9e960dd2e3f0a2d69a18df7 upstream. udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260413211240.853662-1-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 1cdf5dbcec988d06f5f720bdf89e91073f77fa10 Author: Mingming Cao Date: Fri Apr 24 09:29:17 2026 -0700 ibmveth: Disable GSO for packets with small MSS commit cc427d24ac6442ffdeafd157a63c7c5b73ed4de4 upstream. Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit ("ibmvnic: Enforce stronger sanity checks on GSO packets") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability). Fixes: 8641dd85799f ("ibmveth: Add support for TSO") Cc: stable@vger.kernel.org Reviewed-by: Brian King Tested-by: Shaik Abdulla Tested-by: Naveed Ahmed Signed-off-by: Mingming Cao Link: https://patch.msgid.link/20260424162917.65725-1-mmc@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ccab81c4430907108345d2c331de24fe39a9bb02 Author: Hamza Mahfooz Date: Tue Apr 28 08:53:39 2026 -0400 hv_sock: fix ARM64 support commit b31681206e3f527970a7c7ed807fbf6a028fc25b upstream. VMBUS ring buffers must be page aligned. Therefore, the current value of 24K presents a challenge on ARM64 kernels (with 64K pages). So, use VMBUS_RING_SIZE() to ensure they are always aligned and large enough to hold all of the relevant data. Cc: stable@vger.kernel.org Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication") Tested-by: Dexuan Cui Reviewed-by: Dexuan Cui Signed-off-by: Hamza Mahfooz Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260428125339.13963-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0330d611257cee5879ec47fa4d7d4730c962e6b7 Author: Xu Yang Date: Sat Nov 15 10:59:05 2025 +0800 extcon: ptn5150: handle pending IRQ events during system resume commit 4652fefcda3c604c83d1ae28ede94544e2142f06 upstream. When the system is suspended and ptn5150 wakeup interrupt is disabled, any changes on ptn5150 will only be record in interrupt status registers and won't fire an IRQ since its trigger type is falling edge. So the HW interrupt line will keep at low state and any further changes won't trigger IRQ anymore. To fix it, this will schedule a work to check whether any IRQ are pending and handle it accordingly. Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Acked-by: MyungJoo Ham Signed-off-by: Xu Yang Signed-off-by: Chanwoo Choi Link: https://lore.kernel.org/lkml/20251115025905.1395347-1-xu.yang_2@nxp.com/ Signed-off-by: Greg Kroah-Hartman commit 6587a31c6fa89f877922df578b232b8a6acc4379 Author: Shyam Prasad N Date: Mon Mar 30 16:19:59 2026 +0530 cifs: change_conf needs to be called for session setup commit c208a2b95811d6e1ebae65d0d2fc13f73707f8e7 upstream. Today we skip calling change_conf for negotiates and session setup requests. This can be a problem for mchan as the immediate next call after session setup could be due to an I/O that is made on the mount point. For single channel, this is not a problem as there will be several calls after setting up session. This change enforces calling change_conf when the total credits contain enough for reservations for echoes and oplocks. We expect this to happen during the last session setup response. This way, echoes and oplocks are not disabled before the first request to the server. So if that first request is an open, it does not need to disable requesting leases. Cc: Reviewed-by: Bharath SM Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cd4470d9eaf98ee020e612bf53002d4d21761f10 Author: Shyam Prasad N Date: Tue Apr 28 21:37:47 2026 +0530 cifs: abort open_cached_dir if we don't request leases commit d68ce834f8cf6cb2e77f3331df65166b35466b53 upstream. It is possible that SMB2_open_init may not set lease context based on the requested oplock level. This can happen when leases have been temporarily or permanently disabled. When this happens, we will have open_cached_dir making an open without lease context and the response will anyway be rejected by open_cached_dir (thereby forcing a close to discard this open). That's unnecessary two round-trips to the server. This change adds a check before making the open request to the server to make sure that SMB2_open_init did add the expected lease context to the open in open_cached_dir. Cc: Reviewed-by: Bharath SM Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 30b58c127f64194edd937a4c947bcc083904c5c9 Author: Myeonghun Pak Date: Fri Apr 24 22:50:51 2026 +0900 hwmon: (corsair-psu) Close HID device on probe errors commit 174606451fbb17db506ebaacdd5e203e57773d5f upstream. corsairpsu_probe() opens the HID device before sending the device init and firmware-info commands. If either command fails, the error path jumps directly to fail_and_stop and skips hid_hw_close(). Use the existing fail_and_close label for those post-open failures so the open count and low-level close callback are balanced before hid_hw_stop(). Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Cc: stable@vger.kernel.org Signed-off-by: Myeonghun Pak Reviewed-by: Wilken Gottwalt Link: https://lore.kernel.org/r/20260424135107.13720-1-mhun512@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6c0da7c0550eac83964bdd6b5b35cbbe7ccefe63 Author: Sanman Pradhan Date: Thu Apr 16 21:59:40 2026 +0000 hwmon: (ltc2992) Fix u32 overflow in power read path commit 2da0c1fd01dbd6b22844e8676585153dfc660cbe upstream. ltc2992_get_power() computes the divisor for mul_u64_u32_div() as r_sense_uohm * 1000. This multiplication overflows u32 when r_sense_uohm exceeds about 4.29 ohms (4294967 micro-ohms), producing a truncated divisor and an incorrect power reading. Cancel the factor of 1000 from both the numerator (VADC_UV_LSB * IADC_NANOV_LSB = 312500000) and the divisor (r_sense_uohm * 1000), giving (VADC_UV_LSB / 1000) * IADC_NANOV_LSB = 312500 as the numerator and plain r_sense_uohm as the divisor. The cancellation is exact because LTC2992_VADC_UV_LSB (25000) is divisible by 1000. This is the read-path counterpart of the write-path fix applied in the preceding patch. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260416215904.101969-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c45afb423b5914610b7e39fae8b9fc772e085fb0 Author: Sanman Pradhan Date: Thu Apr 16 21:59:30 2026 +0000 hwmon: (ltc2992) Clamp threshold writes to hardware range commit d6cc7c99bf1f73eda7d565d224d791d16239bb41 upstream. ltc2992_set_voltage(), ltc2992_set_current(), and ltc2992_set_power() do not validate the user-supplied value before converting it to a register value. This can result in: 1. Negative input values wrapping to large positive register values. For power, the negative long is implicitly cast to u64 in mul_u64_u32_div(), producing an incorrect value. For voltage and current, the negative converted value wraps when passed to ltc2992_write_reg() as a u32. 2. Intermediate arithmetic exceeding the range representable in u64 on 64-bit platforms. In ltc2992_set_voltage(), (u64)val * 1000 can exceed U64_MAX when val is a large positive long. In ltc2992_set_current(), (u64)val * r_sense_uohm can overflow similarly. In ltc2992_set_power(), the computed value may not fit in u64. 3. Register values exceeding the hardware field width. Voltage and current threshold registers are 12-bit (stored left-justified in 16 bits), and power threshold registers are 24-bit. Without clamping, bits above the field width are truncated in ltc2992_write_reg(). Fix by clamping negative values to zero, clamping positive values to the rounded hardware-representable maximum (the value returned by the read path for a full-scale register) to prevent intermediate overflow, and clamping the converted register value to the hardware field width before writing. The existing conversion formula and rounding behavior are preserved. In the power write path, cancel the factor of 1000 from both the numerator (r_sense_uohm * 1000) and the denominator (VADC_UV_LSB * IADC_NANOV_LSB) to also eliminate a u32 overflow of r_sense_uohm * 1000 when r_sense_uohm exceeds about 4.29 ohms. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260416215904.101969-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9918a918c5fa0a5cafafdf7f0cc34f19590e8bf9 Author: Hongling Zeng Date: Sun May 3 12:17:44 2026 +0800 parisc: Fix IRQ leak in LASI driver commit 37b0dc5e279f35036fb638d1e187197b6c05a76d upstream. When request_irq() succeeds but gsc_common_setup() fails later, the IRQ is never released. Fix this by adding proper error handling with goto labels to ensure resources are released in LIFO order. Detected by Smatch: drivers/parisc/lasi.c:216 lasi_init_chip() warn: 'lasi->gsc_irq.irq' from request_irq() not released on lines: 207. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604180957.4QdAIxP6-lkp@intel.com/ Signed-off-by: Hongling Zeng Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1e262db7675e27f42c3f3f47d6011855f4454f24 Author: Nan Li Date: Fri May 1 09:08:44 2026 +0800 net/rds: handle zerocopy send cleanup before the message is queued commit 44b550d88b267320459d518c0743a241ab2108fa upstream. A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path. Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Xiao Liu Signed-off-by: Xiao Liu Signed-off-by: Nan Li Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/d2ea98a6313d5467bac00f7c9fef8c7acddb9258.1777550074.git.tonanli66@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0fcf6731706f73494245a9c0d64f93bebf95bb51 Author: Maoyi Xie Date: Thu Apr 30 18:33:18 2026 +0800 ip6_gre: Use cached t->net in ip6erspan_changelink(). commit 1d324c2f43f70c965f25c58cc3611c779adbe47e upstream. After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape. Fixes: 2d665034f239 ("net: ip6_gre: Fix ip6erspan hlen calculation") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260430103318.3206018-1-maoyi.xie@ntu.edu.sg Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 66d9c2ed081f299cfb201d9e9c4faf920e56e0bf Author: SeungJu Cheon Date: Sun Apr 26 20:12:39 2026 +0900 sound: ua101: fix division by zero at probe commit d1f73f169c1014463b5060e3f60813e13ddc7b87 upstream. Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash. Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org Signed-off-by: SeungJu Cheon Link: https://patch.msgid.link/20260426111239.103296-1-suunj1331@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a44fbb631cba646532f3948636626f81717365a7 Author: Kai Zen Date: Thu Apr 30 18:26:48 2026 +0300 net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo commit 4b9e327991815e128ad3af75c3a04630a63ce3e0 upstream. rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: struct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: /* include/uapi/linux/if_link.h */ struct ifla_vf_broadcast { __u8 broadcast[32]; }; The function then copies dev->broadcast into it using dev->addr_len as the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function. Fixes: 75345f888f70 ("ipoib: show VF broadcast address") Cc: stable@vger.kernel.org Signed-off-by: Kai Zen Link: https://patch.msgid.link/3c506e8f936e52b57620269b55c348af05d413a2.1777557228.git.kai.aizen.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 04bb66be92f48ed13c3faf1139d892df228789bc Author: Miklos Szeredi Date: Fri Apr 10 16:49:47 2026 +0200 fanotify: fix false positive on permission events commit 7746e3bd4cc19b5092e00d32d676e329bfcb6900 upstream. fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group. CC: stable@vger.kernel.org Fixes: abc77577a669 ("fsnotify: Provide framework for dropping SRCU lock in ->handle_event") Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260410144950.156160-1-mszeredi@redhat.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b25578430f5ea203e30adda52564028999812bc6 Author: Johan Hovold Date: Fri Apr 24 12:49:10 2026 +0200 staging: vme_user: fix root device leak on init failure commit 32c91e8ee039777d0b95b914633fc6a42607959c upstream. Make sure to deregister and free the root device in case module initialisation fails. Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver") Cc: stable@vger.kernel.org # 4.9 Cc: Martyn Welch Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260424104910.2619349-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit fb9fb7ef4a52e99cead2865199bb51bcb6148d1d Author: Johan Hovold Date: Fri Apr 10 10:17:55 2026 +0200 spi: zynqmp-gqspi: fix controller deregistration commit 6895fc4faafc9082e15e4e624b23dd5f0c98feb5 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org # 4.2: 64640f6c972e Cc: stable@vger.kernel.org # 4.2 Cc: Ranjit Waghmode Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-26-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0c17c8832562b2aac288e89cefd0f46074f54bcb Author: Siwei Zhang Date: Wed Apr 15 16:51:36 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() commit 2ff1a41a912de8517b4482e946dd951b7d80edbf upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 89bc500e41fc ("Bluetooth: Add state tracking to struct l2cap_chan") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 684a1f9ee2325437ae18ac5371884e4c6a25ae73 Author: Siwei Zhang Date: Wed Apr 15 16:49:59 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() commit 0a120d96166301d7a95be75b52f843837dbd1219 upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 80808e431e1e ("Bluetooth: Add l2cap_chan_ops abstraction") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 7b2d4c04816cdc887f472caaf7fc966cfc107e40 Author: Michael Bommarito Date: Tue Apr 21 13:08:45 2026 -0400 Bluetooth: virtio_bt: validate rx pkt_type header length commit daf23014e5d975e72ea9c02b5160d3fcf070ea47 upstream. virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit fd91fa2678ab603dfb285416c1cf3843d7be1e41 Author: Michael Bommarito Date: Tue Apr 21 13:08:44 2026 -0400 Bluetooth: virtio_bt: clamp rx length before skb_put commit 21bd244b6de5d2fe1063c23acc93fbdd2b20d112 upstream. virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 870560015ce6e0d8f841c6a8aba33c44be52c727 Author: Yilin Zhu Date: Sun Apr 12 13:07:54 2026 +0800 ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() commit bc0fcb9823cd0894934cf968b525c575833d7078 upstream. xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path. Fixes: 0146dca70b87 ("xfrm: add support for UDPv6 encapsulation of ESP") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ruide Cao Signed-off-by: Yilin Zhu Signed-off-by: Ren Wei Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit cb02bc1dc69f889030338aa49251bb6baccec440 Author: Ruijie Li Date: Wed Apr 29 00:41:43 2026 +0800 xfrm: provide message size for XFRM_MSG_MAPPING commit 28465227c80fe417b4013c432be1f3737cb9f9a3 upstream. The compat 64=>32 translation path handles XFRM_MSG_MAPPING, but xfrm_msg_min[] does not provide the native payload size for this message type. Add the missing XFRM_MSG_MAPPING entry so compat translation can size and translate mapping notifications correctly. Fixes: 5461fc0c8d9f ("xfrm/compat: Add 64=>32-bit messages translator") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 7f810e6f2280ecc958fcc851d406f3b93ee3d34d Author: Sourabh Jain Date: Tue Apr 7 18:13:44 2026 +0530 powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o commit b3a97f9484080c6e71db9e803e3cc1bb372a9bc7 upstream. KASAN instrumentation is intended to be disabled for the kexec core code, but the existing Makefile entry misses the object suffix. As a result, the flag is not applied correctly to core_$(BITS).o. So when KASAN is enabled, kexec_copy_flush and copy_segments in kexec/core_64.c are instrumented, which can result in accesses to shadow memory via normal address translation paths. Since these run with the MMU disabled, such accesses may trigger page faults (bad_page_fault) that cannot be handled in the kdump path, ultimately causing a hang and preventing the kdump kernel from booting. The same is true for kexec as well, since the same functions are used there. Update the entry to include the “.o” suffix so that KASAN instrumentation is properly disabled for this object file. Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/ Cc: stable@vger.kernel.org Reviewed-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Acked-by: Mahesh Salgaonkar Reviewed-by: Aboorva Devarajan Tested-by: Aboorva Devarajan Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260407124349.1698552-1-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 7700f3c9d551389e44a4eaced9b1b5eeac7e14d2 Author: Cássio Gabriel Date: Sun May 3 21:55:52 2026 -0300 ALSA: firewire-tascam: Do not drop unread control events commit 0749daa8eb5ab90334aaad3b0671efd7150d43b1 upstream. tscm_hwdep_read_queue() copies as many queued control events as fit in the userspace buffer. When the buffer is smaller than the current contiguous queue segment, length is rounded down to the number of bytes that can be copied. However, after copying that shortened length, the code advances pull_pos to the original tail_pos, marking the whole contiguous segment as consumed. Any events between the copied portion and tail_pos are lost. Limit tail_pos to the position after the entries actually copied before updating pull_pos. When the whole segment fits, this is equivalent to the old tail_pos update; when the buffer is smaller, the remaining events stay queued for the next read. Fixes: a8c0d13267a4 ("ALSA: firewire-tascam: notify events of change of state for userspace applications") Cc: stable@vger.kernel.org Suggested-by: Takashi Sakamoto Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Sakamoto Co-developed-by: Takashi Sakamoto Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260503-alsa-firewire-tascam-read-queue-v2-1-126c6efd7642@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7bd61ed0bf9f4f1f2673d489b3bda1555b48d054 Author: Felix Gu Date: Tue Apr 7 21:21:22 2026 +0800 usb: ulpi: fix memory leak on ulpi_register() error paths commit 0b9fcab1b8608d429e5f239afb197de928d4de7d upstream. Commit 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") removed kfree(ulpi) from ulpi_register_interface() to fix a double-free when device_register() fails. But when ulpi_of_register() or ulpi_read_id() fail before device_register() is called, the ulpi allocation is leaked. Add kfree(ulpi) on both error paths to properly clean up the allocation. Fixes: 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") Cc: stable Signed-off-by: Felix Gu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260407-ulpi-v1-1-f3fafe53f7b2@gmail.com Signed-off-by: Greg Kroah-Hartman commit 10871b7da4be0f98c483a4bded963ee0fdbaae16 Author: Fabio Porcedda Date: Mon Apr 27 11:17:46 2026 +0200 USB: serial: option: add Telit Cinterion LE910Cx compositions commit 100201d349edd226ca3470c894c92dccc67ee7a8 upstream. Add the following Telit Cinterion LE910Cx compositions: 0x1251: RNDIS + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=108 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1251 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=ff Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1253: ECM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=121 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1253 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1254: tty (AT) + tty (AT) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=122 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1254 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1255: tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=123 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1255 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3eb7774638c1fb5379b350d43c855d96dd5e31fd Author: Aaro Koskinen Date: Mon Apr 13 21:49:12 2026 +0300 USB: omap_udc: DMA: Don't enable burst 4 mode commit 3f91484f6c13c434bd573ca6b6779c26adb0ddab upstream. Commit 65111084c63d7 ("USB: more omap_udc updates (dma and omap1710)") added setting for DMA burst 4 mode. But I think this should be undone for two reasons: - It breaks DMA on 15xx boards - transfers just silently stall. - On newer OMAP1 boards, like Nokia 770 (omap1710), there is no measurable performance impact when testing TCP throughput with g_ether with large 15000 byte MTU size. It's also worth noting that when the original change was made, the OMAP_DMA_DATA_BURST_4 handling in arch/arm/plat-omap/dma.c was broken, and actually resulted in the same as the OMAP_DMA_DATA_BURST_DIS i.e. burst disabled. This was fixed not until a couple kernel releases later in an unrelated commit 1a8bfa1eb998a ("[ARM] 3142/1: OMAP 2/5: Update files common to omap1 and omap2"). So based on this it seems there was never really a very good reason to enable this burst mode in omap_udc, so remove it now to allow 15xx DMA to work again (it provides 2x throughput compared to PIO mode). Fixes: 65111084c63d ("[PATCH] USB: more omap_udc updates (dma and omap1710)") Cc: stable Signed-off-by: Aaro Koskinen Link: https://patch.msgid.link/ad06qHLclWHeSGnV@darkstar.musicnaut.iki.fi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b1b16a77450c5c6fa074742e2923ec923547be85 Author: Cássio Gabriel Date: Fri Apr 24 18:50:10 2026 -0300 ALSA: usb-audio: Fix UAC3 cluster descriptor size check commit 26265dd69da32d88a88d21987853cec899d9e21f upstream. The UAC3 cluster descriptor length check in snd_usb_get_audioformat_uac3()was added to make sure that the buffer is large enough for a struct uac3_cluster_header_descriptor before the returned data is cast and used. However, the check uses sizeof(cluster), where cluster is a pointer, not the size of the descriptor header. This makes the validation depend on the architecture pointer size and does not match the intended object size. Check against sizeof(*cluster) instead. Fixes: fb4e2a6e8f28 ("ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260424-alsa-usb-uac3-cluster-size-v1-1-99a5808898a3@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 24a40df79307ca7ca0eec0889361cf6ac146d72a Author: Takashi Iwai Date: Mon Apr 27 17:22:15 2026 +0200 ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() commit 6e7247d8f5fefeceb0bb9cc80a5388a636b219cd upstream. The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole. Fixes: ecfd41166b72 ("ALSA: usb-audio: Validate UAC3 cluster segment descriptors") Cc: Link: https://patch.msgid.link/20260427152224.15276-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 087d97342c100138ea7d75a50977c9c2319f957b Author: Greg Kroah-Hartman Date: Mon Apr 20 18:11:04 2026 +0200 usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl commit b38e53cbfb9d84732e5984fbd73e128d592415c5 upstream. Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening. Cc: Pete Zaitcev Assisted-by: gkh_clanker_t1000 Cc: stable Link: https://patch.msgid.link/2026042011-shredder-savage-48c6@gregkh Signed-off-by: Greg Kroah-Hartman commit 4220d4dd062ea3d3eb056a6cbe0b568e740d20b1 Author: Greg Kroah-Hartman Date: Mon Apr 20 18:11:03 2026 +0200 usb: usblp: fix heap leak in IEEE 1284 device ID via short response commit 7a400c6fe3617e31e690e3f7ca37bb335e0498f3 upstream. usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device. Cc: Pete Zaitcev Assisted-by: gkh_clanker_t1000 Cc: stable Link: https://patch.msgid.link/2026042002-unicorn-greedily-3c63@gregkh Signed-off-by: Greg Kroah-Hartman commit 765709720e6af9a178abc40244a8d1aa39ac4e71 Author: Tristan Madani Date: Fri Apr 17 11:11:44 2026 +0000 wifi: b43: enforce bounds check on firmware key index in b43_rx() commit 1f4f78bf8549e6ac4f04fba4176854f3a6e0c332 upstream. The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index. Suggested-by: Jonas Gorski Acked-by: Michael Büsch Fixes: e4d6b7951812 ("[B43]: add mac80211-based driver for modern BCM43xx devices") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260417111145.2694196-1-tristmd@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 744c19e266b0d2628c5951439195dcef27eadacf Author: Jiri Slaby (SUSE) Date: Tue Dec 9 11:04:59 2025 +0100 wifi: ath5k: do not access array OOB commit d748603f12baff112caa3ab7d39f50100f010dbd upstream. Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal. Signed-off-by: Jiri Slaby (SUSE) Reported-by: Vincent Danjean Link: https://lore.kernel.org/all/aQYUkIaT87ccDCin@eldamar.lan Closes: https://bugs.debian.org/1119093 Fixes: 6d7b97b23e11 ("ath5k: fix tx status reporting issues") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251209100459.2253198-1-jirislaby@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 4f697813162d5f9151726a6d2bee82bffe4b0256 Author: Jeongjun Park Date: Thu Apr 23 02:38:46 2026 +0900 wifi: rsi: fix kthread lifetime race between self-exit and external-stop commit db57a1aa54ff68669781976e4edb045e09e2b65b upstream. RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed. Cc: Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e5d03b.a00a0220.1bd0ca.0064.GAE@google.com/ Fixes: 4c62764d0fc2 ("rsi: improve kernel thread handling to fix kernel panic") Signed-off-by: Jeongjun Park Link: https://patch.msgid.link/20260422173846.37640-1-aha310510@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4242db36de99de734cc1f60e5edd86cda7e598c6 Author: Tristan Madani Date: Fri Apr 17 11:11:45 2026 +0000 wifi: b43legacy: enforce bounds check on firmware key index in RX path commit a035766f970bde2d4298346a31a80685be5c0205 upstream. Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260417111145.2694196-2-tristmd@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2a79b1a492bcfa725383b6580cd93a6862308c85 Author: Leon Yen Date: Thu Oct 9 10:01:58 2025 +0800 wifi: mt76: mt7921: fix a potential clc buffer length underflow commit 5373f8b19e568b5c217832b9bbef165bd2b2df14 upstream. The buf_len is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC. This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure. Cc: stable@vger.kernel.org Fixes: fa6ad88e023d ("wifi: mt76: mt7921: fix country count limitation for CLC") Signed-off-by: Leon Yen Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20251009020158.1923429-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 3d6fb8a7690c23e3213c4b008f64d89a44b98737 Author: Jann Horn Date: Mon May 11 08:55:11 2026 -0700 exit: prevent preemption of oopsing TASK_DEAD task commit c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891 upstream. When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler) Fixes: 7f80a2fd7db9 ("exit: Stop poorly open coding do_task_dead in make_task_dead") Cc: stable@kernel.org Signed-off-by: Jann Horn Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bddf04e3822e4fa38691433dd0750420d49a0dd6 Author: Zilin Guan Date: Mon May 11 17:22:13 2026 +0800 ice: Fix memory leak in ice_set_ringparam() [ Upstream commit fe868b499d16f55bbeea89992edb98043c9de416 ] In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Rajani Kantha <681739313@139.com> Signed-off-by: Sasha Levin commit 7e041d0aad1d4d43d921ace052e04f4e2cacaed3 Author: Cen Zhang Date: Mon May 11 14:35:39 2026 +0800 Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lock [ Upstream commit 94d8e6fe5d0818e9300e514e095a200bd5ff93ae ] btintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESET and Intel exception-info retrieval) without holding hci_req_sync_lock(). This lets it race against hci_dev_do_close() -> btintel_shutdown_combined(), which also runs __hci_cmd_sync() under the same lock. When both paths manipulate hdev->req_status/req_rsp concurrently, the close path may free the response skb first, and the still-running hw_error path hits a slab-use-after-free in kfree_skb(). Wrap the whole recovery sequence in hci_req_sync_lock/unlock so it is serialized with every other synchronous HCI command issuer. Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260 Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin commit 7eb0b25a212928bb97950f8b99682aa60315874f Author: Luiz Augusto von Dentz Date: Mon May 11 14:34:05 2026 +0800 Bluetooth: hci_sync: Remove remaining dependencies of hci_request [ Upstream commit f2d89775358606c7ab6b6b6c4a02fe1e8cd270b1 ] This removes the dependencies of hci_req_init and hci_request_cancel_all from hci_sync.c. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin commit 45cd83c5c470ba49fe261489c8358ad7b9df7c45 Author: Jamal Hadi Salim Date: Thu Apr 30 11:29:55 2026 -0400 net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked commit 458d5615272d3de535748342eb68ca492343048c upstream. When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead. Fixes: 77be155cba4e ("pkt_sched: Add peek emulation for non-work-conserving qdiscs.") Reported-by: Manas Reported-by: Rakshit Awasthi Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260430152957.194015-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 18ae9eacfc95cc715c0606b2c86e8aa8a86cf3e3 Author: Qingfang Deng Date: Wed Apr 15 10:24:50 2026 +0800 flow_dissector: do not dissect PPPoE PFC frames [ Upstream commit d6c19b31a3c1d519fabdcf0aa239e6b6109b9473 ] RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the flow dissector driver has assumed an uncompressed frame until the blamed commit. During the review process of that commit [1], support for PFC is suggested. However, having a compressed (1-byte) protocol field means the subsequent PPP payload is shifted by one byte, causing 4-byte misalignment for the network header and an unaligned access exception on some architectures. The exception can be reproduced by sending a PPPoE PFC frame to an ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE session is active on that interface: $ 0 : 00000000 80c40000 00000000 85144817 $ 4 : 00000008 00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c 0000003d 00000000 $12 : 000000e0 00000039 00000000 00000000 $16 : 85043240 80a75758 81dc9bb8 00006488 $20 : 0000002f 00000007 85144810 80a70000 $24 : 81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000 805ead08 Hi : 00009d51 Lo : 2163358a epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra : 805ead08 __skb_get_hash_net+0x74/0x12c Status: 11000403 KERNEL EXL IE Cause : 40800010 (ExcCode 04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc) Call Trace: [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50 [<805ead08>] __skb_get_hash_net+0x74/0x12c [<805ef330>] get_rps_cpu+0x1b8/0x3fc [<805fca70>] netif_receive_skb_list_internal+0x324/0x364 [<805fd120>] napi_complete_done+0x68/0x2a4 [<8058de5c>] mtk_napi_rx+0x228/0xfec [<805fd398>] __napi_poll+0x3c/0x1c4 [<805fd754>] napi_threaded_poll_loop+0x234/0x29c [<805fd848>] napi_threaded_poll+0x8c/0xb0 [<80053544>] kthread+0x104/0x12c [<80002bd8>] ret_from_kernel_thread+0x14/0x1c Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000 To reduce the attack surface and maintain performance, do not process PPPoE PFC frames. [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home Fixes: 46126db9c861 ("flow_dissector: Add PPPoE dissectors") Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260415022456.141758-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d50981aaaefc3b04490fbc8274d37881a2b1b112 Author: Dong Chenchen Date: Wed May 6 09:20:57 2026 +0800 net: Fix icmp host relookup triggering ip_rt_bug [ Upstream commit c44daa7e3c73229f7ac74985acb8c7fb909c4e0a ] arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is: WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90 The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1 icmp_route_lookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = ip_rt_bug) to skb for DESTUNREACH. For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1). Skip icmp relookup for locally generated packets to fix it. Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Signed-off-by: Dong Chenchen Reviewed-by: David Ahern Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20241127040850.1513135-1-dongchenchen2@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Jiayuan Chen Signed-off-by: Sasha Levin commit e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0 Author: Sean Christopherson Date: Tue May 5 09:08:12 2026 +0200 KVM: x86: Fix shadow paging use-after-free due to unexpected GFN commit 0cb2af2ea66ad8ff195c156ea690f11216285bdf upstream. The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy. Fixes: 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Fixes: 6aa8b732ca01 ("kvm: userspace interface") Reported-by: Alexander Bulekov Reported-by: Fred Griffoul Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20260503201029.106481-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 10242e640b36b91ad03d25f3dc77854bbdff8358 Author: Tejas Bharambe Date: Fri May 8 14:58:29 2026 +0800 ext4: validate p_idx bounds in ext4_ext_correct_indexes [ Upstream commit 2acb5c12ebd860f30e4faf67e6cc8c44ddfe5fe8 ] ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code. Reported-by: syzbot+04c4e65cab786a2e5b7e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=04c4e65cab786a2e5b7e Signed-off-by: Tejas Bharambe Link: https://patch.msgid.link/JH0PR06MB66326016F9B6AD24097D232B897CA@JH0PR06MB6632.apcprd06.prod.outlook.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [ Minor conflict resolved. ] Signed-off-by: Jianqiang kang Signed-off-by: Sasha Levin commit 7434c64ddae88a02e7fb478bc256cc100d48d3e3 Author: Felix Gu Date: Thu May 7 17:32:46 2026 +0800 spi: meson-spicc: Fix double-put in remove path [ Upstream commit 63542bb402b7013171c9f621c28b609eda4dbf1f ] meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put. Fixes: 8311ee2164c5 ("spi: meson-spicc: fix memory leak in meson_spicc_remove") Signed-off-by: Felix Gu Reviewed-by: Johan Hovold Link: https://patch.msgid.link/20260322-rockchip-v1-1-fac3f0c6dad8@gmail.com Signed-off-by: Mark Brown [ In v6.1, commit 68bf3288c7eb ("spi: meson-spicc: switch to use modern name") has not been applied, so the driver still uses the legacy spicc->master field and spi_master_put() API. The line to remove is spi_master_put(spicc->master) rather than spi_controller_put(spicc->host) as in the upstream patch. They are functionally identical. ] Signed-off-by: Wenshan Lan Signed-off-by: Sasha Levin commit da1d0ed31e9802fd99384f43cc63678a5a11cb41 Author: Yussuf Khalil Date: Thu May 7 15:07:49 2026 +0800 drm/amd/display: Do not skip unrelated mode changes in DSC validation [ Upstream commit aed3d041ab061ec8a64f50a3edda0f4db7280025 ] Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5004 Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check") Signed-off-by: Yussuf Khalil Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b) Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin commit 9f4e700e488329fe41b250c22526d6d41983856f Author: Johan Hovold Date: Tue Mar 24 09:23:23 2026 +0100 spi: rockchip: fix controller deregistration commit 53e7a16070feb7d1d4d81a583eaac5e25048b9c3 upstream. Make sure to deregister the controller before freeing underlying resources like DMA channels during driver unbind. Fixes: 64e36824b32b ("spi/rockchip: add driver for Rockchip RK3xxx SoCs integrated SPI") Cc: stable@vger.kernel.org # 3.17 Cc: addy ke Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260324082326.901043-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 76ff6bfc9a809571793f425ba99f6a759108dcf8 Author: Mark Brown Date: Thu Mar 26 14:52:41 2026 +0000 ASoC: SOF: Don't allow pointer operations on unconfigured streams commit c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8 upstream. When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not Fixes: c1a731c71359 ("ASoC: SOF: compress: Add support for computing timestamps") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260326-asoc-compress-tstamp-params-v1-1-3dc735b3d599@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d9f81a1740c0405394136d2862330e7a514e7829 Author: Shivam Kalra Date: Sun Apr 26 19:38:41 2026 +0530 ACPI: video: force native backlight on HP OMEN 16 (8A44) commit 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 upstream. The HP OMEN 16 Gaming Laptop (board name 8A44) has a mux-less hybrid GPU configuration with AMD Rembrandt (Radeon 680M) and NVIDIA GA104 (RTX 3070 Ti). The internal eDP panel is wired to the AMD iGPU. When Nouveau loads without GSP firmware, the ACPI video backlight device (acpi_video0) gets registered alongside the native AMD backlight (amdgpu_bl2). In this state, writes to amdgpu_bl2 update the software brightness value but fail to change the physical panel brightness. Force native backlight to prevent acpi_video0 from registering. Confirmed that booting with acpi_backlight=native resolves the issue. Cc: All applicable Signed-off-by: Shivam Kalra Link: https://patch.msgid.link/20260426-omen-16-backlight-fix-v1-1-62364f268ea6@zohomail.in Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e6159d8b3505b936b90b14169f17c1840a64bdcf Author: Jinjie Ruan Date: Fri Apr 17 12:01:12 2026 +0800 ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug commit 75141a770f4f8225d316f6c7e146723a32e9720e upstream. When concurrently bringing up and down two SMT threads of a physical core, many warning call traces occur as below: The issue timeline is as follows: 1. When the system starts, cpufreq: CPU: 220, policy->related_cpus: 220-221, policy->cpus: 220-221 2. Offline CPU 220 and CPU 221. 3. Online CPU 220 - CPU 221 is now offline, as acpi_get_psd_map() use for_each_online_cpu(), so the cpu_data->shared_cpu_map, policy->cpus, and related_cpus has only CPU 220. cpufreq: CPU: 220, policy->related_cpus: 220, policy->cpus: 220 4. Offline CPU 220 5. Online CPU 221, the below call trace occurs: - Since CPU 220 and CPU 221 share one policy, and policy->related_cpus = 220 after step 3, so CPU 221 is not in policy->related_cpus but per_cpu(cpufreq_cpu_data, cpu221) is not NULL. After reverting commit 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs"), the issue disappeared. The _PSD (P-State Dependency) defines the hardware-level dependency of frequency control across CPU cores. Since this relationship is a physical attribute of the hardware topology, it remains constant regardless of the online or offline status of the CPUs. Using for_each_online_cpu() in acpi_get_psd_map() is problematic. If a CPU is offline, it will be excluded from the shared_cpu_map. Consequently, if that CPU is brought online later, the kernel will fail to recognize it as part of any shared frequency domain. Switch back to for_each_possible_cpu() to ensure that all cores defined in the ACPI tables are correctly mapped into their respective performance domains from the start. This aligns with the logic of policy->related_cpus, which must encompass all potentially available cores in the domain to prevent logic gaps during CPU hotplug operations. To resolve the original issue regarding the "nosmt" or "nosmt=force" boot parameter, as send_pcc_cmd() function already does if (!desc) continue, so reverting that loop back to for_each_possible_cpu() is ok, only need to change the match_cpc_ptr NULL case in acpi_get_psd_map() to continue as Sean suggested. How to reproduce, on arm64 machine with SMT support which use acpi cppc cpufreq driver: bash test.sh 220 & bash test.sh 221 & The test.sh is as below: while true do echo 0 > /sys/devices/system/cpu/cpu${1}/online sleep 0.5 cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus echo 1 > /sys/devices/system/cpu/cpu${1}/online cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus done CPU: 221 PID: 1119 Comm: cpuhp/221 Kdump: loaded Not tainted 6.6.0debug+ #5 Hardware name: To be filled by O.E.M. S920X20/BC83AMDA01-7270Z, BIOS 20.39 09/04/2024 pstate: a1400009 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : cpufreq_online+0x8ac/0xa90 lr : cpuhp_cpufreq_online+0x18/0x30 sp : ffff80008739bce0 x29: ffff80008739bce0 x28: 0000000000000000 x27: ffff28400ca32200 x26: 0000000000000000 x25: 0000000000000003 x24: ffffd483503ff000 x23: ffffd483504051a0 x22: ffffd48350024a00 x21: 00000000000000dd x20: 000000000000001d x19: ffff28400ca32000 x18: 0000000000000000 x17: 0000000000000020 x16: ffffd4834e6a3fc8 x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000000001 x12: 00000000ffffffff x11: 0000000000000040 x10: ffffd48350430728 x9 : ffffd4834f087c78 x8 : 0000000000000001 x7 : ffff2840092bdf00 x6 : ffffd483504264f0 x5 : ffffd48350405000 x4 : ffff283f7f95cc60 x3 : 0000000000000000 x2 : ffff53bc2f94b000 x1 : 00000000000000dd x0 : 0000000000000000 Call trace: cpufreq_online+0x8ac/0xa90 cpuhp_cpufreq_online+0x18/0x30 cpuhp_invoke_callback+0x128/0x580 cpuhp_thread_fun+0x110/0x1b0 smpboot_thread_fn+0x140/0x190 kthread+0xec/0x100 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Cc: All applicable Fixes: 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs") Co-developed-by: Sean Kelley Signed-off-by: Sean Kelley Signed-off-by: Jinjie Ruan [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260417040112.3727756-1-ruanjinjie@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4d95ca4acfb5787a73249fdf39a30c70af21d2de Author: Guangshuo Li Date: Mon Apr 13 21:53:43 2026 +0800 ACPI: scan: Use acpi_dev_put() in object add error paths commit 9c0acc169ac71535477caedea8315f7041c5f07c upstream. After acpi_init_device_object(), the lifetime of struct acpi_device is managed by the driver core through reference counting. Both acpi_add_power_resource() and acpi_add_single_object() call acpi_init_device_object() and then invoke acpi_device_add(). If that fails, their error paths call the release callback directly instead of dropping the device reference through acpi_dev_put(). This bypasses the normal device lifetime rules and frees the object without releasing the reference acquired by device_initialize(), which may lead to a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix both error paths by using acpi_dev_put() and let the release callback handle the final cleanup. Fixes: 781d737c7466 ("ACPI: Drop power resources driver") Fixes: 718fb0de8ff88 ("ACPI: fix NULL bug for HID/UID string") Cc: All applicable Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e3d9865dacd7435b8465848428210d0f0c673311 Author: Rajat Gupta Date: Sun May 3 20:51:10 2026 -0700 fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free commit 8de779dc40d35d39fa07387b6f921eb11df0f511 upstream. dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation. Signed-off-by: Rajat Gupta Acked-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 9c6ded95ac6281e390d167637ccbde6cea2ba1ae Author: Corey Minyard Date: Mon Apr 20 13:02:18 2026 -0500 ipmi:si: Return state to normal if message allocation fails commit 09dd798270ff582d7309f285d4aaf5dbebae01cb upstream. There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 01f8387fa5b796f13cf50014c171f6da7abc46ea Author: Corey Minyard Date: Mon Apr 20 12:50:09 2026 -0500 ipmi: Check event message buffer response for bad data commit 36920f30e78e69df01f9691c470b6f3ba8aebf98 upstream. The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate. Reported-by: Matt Fleming Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 9059dc94421e1d4f8e5844204608b37ebfddb3da Author: Corey Minyard Date: Mon Apr 20 12:39:51 2026 -0500 ipmi: Add limits to event and receive message requests commit c4cca236968683eb0d59abfb12d5c7e4d8514227 upstream. The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs. Reported-by: Matt Fleming Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/ Fixes: <1da177e4c3f4> ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 12f2201a56957ba020392223a7393a5eba080c1b Author: Greg Kroah-Hartman Date: Sat Apr 11 14:06:00 2026 +0200 scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() commit 772a896a56e0e3ef9424a025cec9176f9d8f4552 upstream. target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here. Cc: Martin K. Petersen Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026041159-garter-theft-3be0@gregkh Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9ad26c272405f53834871cc2e46b9b5393a666c3 Author: Kai Ma Date: Wed Apr 22 22:54:18 2026 +0800 netfilter: reject zero shift in nft_bitwise commit fe11e5c40817b84abaa5d83bfb6586d8412bfd07 upstream. Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path. Fixes: 567d746b55bc ("netfilter: bitwise: add support for shifts.") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Kai Ma Signed-off-by: Ren Wei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit b258b849a580285a1692e782ebc902b44c884a71 Author: Andrea Mayer Date: Tue Apr 21 11:47:35 2026 +0200 net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels commit f9c52a6ba9780bd27e0bf4c044fd91c13c778b6e upstream. seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst. Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input") Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Reviewed-by: Simon Horman Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260421094735.20997-1-andrea.mayer@uniroma2.it Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a8d907acc3e5a078c2e5637ff60c30c6d2ddc23a Author: Deepanshu Kartikey Date: Sun Apr 26 05:49:34 2026 +0530 ALSA: caiaq: fix usb_dev refcount leak on probe failure commit 7a5f1cd22d47f8ca4b760b6334378ae42c1bd24b upstream. create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor. However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new(). Fixes: 80bb50e2d459 ("ALSA: caiaq: take a reference on the USB device in create_card()") Reported-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2afd7e71155c7e241560 Tested-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260426001934.70813-1-kartikey406@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 36f9602fb22ede69fcc8b422be0cf8105bf655ad Author: Arjan van de Ven Date: Mon Apr 20 14:57:15 2026 -0700 drm/amdgpu: fix zero-size GDS range init on RDNA4 commit 095a8b0ad3c3b5cdc3850d961adb8a8f735220bb upstream. RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Link: https://lore.kernel.org/all/bug-221376-2300@https.bugzilla.kernel.org%2F/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=221376 Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html Assisted-by: GitHub Copilot:Claude Sonnet 4.6 linux-kernel-oops-x86. Signed-off-by: Arjan van de Ven Cc: Alex Deucher Cc: "Christian König" Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Alex Deucher (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0a9e8053f1f8a8e1bfc1dd61ffe67be6c1180402 Author: Greg Kroah-Hartman Date: Tue Apr 21 15:16:33 2026 +0200 ipv6: rpl: reserve mac_len headroom when recompressed SRH grows commit 9e6bf146b55999a095bb14f73a843942456d1adc upstream. ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Cc: stable Reported-by: Anthropic Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026042133-gout-unvented-1bd9@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8abcff2ad5dea7ced43fa27cdc8a20c891150659 Author: Takashi Iwai Date: Mon Apr 27 16:56:15 2026 +0200 ALSA: caiaq: Don't abort when no input device is available commit b32ae47a2b0a1fb4bd4942242847966d9b178222 upstream. The previous fix to handle the error from setup_card() caused a regression for the models that have no dedicated input device; snd_usb_caiaq_input_init() just returns -EINVAL, and we treat it as a fatal error although it should be ignored. As a regression fix, change the error code to -ENODEV, and ignore this error in the callee, to continue probing. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=221423 Link: https://patch.msgid.link/20260427145642.6637-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 089940d969e13e129b54f104a578cbafd99e308b Author: Takashi Iwai Date: Mon Apr 27 14:37:53 2026 +0200 ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path commit 0a7b5221b5b51cc798fcfc3be00d02eade149d69 upstream. The previous fix for handling the error from setup_card() missed that an internal URB cdev->ep1_in_urb might have been already submitted beforehand. In the normal case, this URB gets killed at the disconnection, but in the error path, we didn't do it, hence there can be a potential leak. Fix it in the error path for setup_card(), too. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: Link: https://patch.msgid.link/20260427123819.890185-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a1f1ce60ac69d6ec5b446116ca01a7e4562a1d31 Author: Douglas Anderson Date: Mon Apr 13 19:59:11 2026 -0700 driver core: Add kernel-doc for DEV_FLAG_COUNT enum value commit 5b484311507b5d403c1f7a45f6aa3778549e268b upstream. Even though nobody should use this value (except when declaring the "flags" bitmap), kernel-doc still gets upset that it's not documented. It reports: WARNING: ../include/linux/device.h:519 Enum value 'DEV_FLAG_COUNT' not described in enum 'struct_device_flags' Add the description of DEV_FLAG_COUNT. Fixes: a2225b6e834a ("driver core: Don't let a device probe until it's ready") Reported-by: Randy Dunlap Closes: https://lore.kernel.org/f318cd43-81fd-48b9-abf7-92af85f12f91@infradead.org Signed-off-by: Douglas Anderson Tested-by: Randy Dunlap Reviewed-by: Randy Dunlap Link: https://patch.msgid.link/20260413195910.1.I23aca74fe2d3636a47df196a80920fecb2643220@changeid Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit d4c6a6d08e70bb1083c7c405fc7faacbf19aebc0 Author: Yucheng Lu Date: Wed Apr 22 21:45:04 2026 +0800 crypto: authencesn - reject short ahash digests during instance creation commit 5db6ef9847717329f12c5ea8aba7e9f588a980c0 upstream. authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuhang Zheng Reviewed-by: Eric Biggers Signed-off-by: Yucheng Lu Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit dfe8dafa4c4ae4cd740f13f155a52f553f4db960 Author: Andrea Mayer Date: Sat Apr 18 18:28:38 2026 +0200 seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode commit ade67d5f588832c7ba131aadd4215a94ce0a15c8 upstream. When SEG6_IPTUN_MODE_L2ENCAP_RED (L2ENCAP_RED) was introduced, the condition in seg6_build_state() that excludes L2 encap modes from setting LWTUNNEL_STATE_OUTPUT_REDIRECT was not updated to account for the new mode. As a consequence, L2ENCAP_RED routes incorrectly trigger seg6_output() on the output path, where the packet is silently dropped because skb_mac_header_was_set() fails on L3 packets. Extend the check to also exclude L2ENCAP_RED, consistent with L2ENCAP. Fixes: 13f0296be8ec ("seg6: add support for SRv6 H.L2Encaps.Red behavior") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260418162838.31979-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2c2c14b7dfccad8c5a28802849e40c21252e4c28 Author: Yang Xiuwei Date: Mon Mar 30 09:49:52 2026 +0800 scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails commit 1e111c4b3a726df1254670a5cc4868cedb946d37 upstream. If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup. Fixes: 265dfe8ebbab ("scsi: sd: Free scsi_disk device via put_device()") Cc: stable@vger.kernel.org Reviewed-by: John Garry Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260330014952.152776-1-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d8cce4773c2b23d819baf5abedc62f7b430e8745 Author: Keenan Dong Date: Wed Apr 8 16:46:00 2026 +0800 rtmutex: Use waiter::task instead of current in remove_waiter() commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 upstream. remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ] Fixes: 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Keenan Dong Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e73cd5aed6b15e55c1c47577bdb473b5e88d6a69 Author: Tobias Gaertner Date: Sun Mar 29 04:17:03 2026 -0700 ntfs3: fix integer overflow in run_unpack() volume boundary check commit 984a415f019536ea2d24de9010744e5302a9a948 upstream. The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()"). Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Signed-off-by: Tobias Gaertner Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 425de2aba0d061b3e715d51a3b1992c112ed5b99 Author: Tobias Gaertner Date: Sun Mar 29 04:17:02 2026 -0700 ntfs3: add buffer boundary checks to run_unpack() commit b62567bca47408e6739dee75f02a2113548af875 upstream. run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Signed-off-by: Tobias Gaertner Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit f46d49fa6ef532bc5e5c8b47a4ba7a76407f1126 Author: Steven Rostedt Date: Mon Apr 20 14:24:26 2026 -0400 ktest: Fix the month in the name of the failure directory commit 768059ede35f197575a38b10797b52402d9d4d2f upstream. The Perl localtime() function returns the month starting at 0 not 1. This caused the date produced to create the directory for saving files of a failed run to have the month off by one. machine-test-useconfig-fail-20260314073628 The above happened in April, not March. The correct name should have been: machine-test-useconfig-fail-20260414073628 This was somewhat confusing. Cc: stable@vger.kernel.org Cc: John 'Warthog9' Hawley Link: https://patch.msgid.link/20260420142426.33ad0293@fedora Fixes: 7faafbd69639b ("ktest: Add open and close console and start stop monitor") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ccb1d7edfbbb56981d48bb78c8a74631560ad5fa Author: Chen Zhao Date: Sun Apr 5 18:44:55 2026 +0300 IB/core: Fix zero dmac race in neighbor resolution commit 5e6de34d82b49cab9d8a42063e9cd0f22a4f31e5 upstream. dst_fetch_ha() checks nud_state without holding the neighbor lock, then copies ha under the seqlock. A race in __neigh_update() where nud_state is set to NUD_REACHABLE before ha is written allows dst_fetch_ha() to read a zero MAC address while the seqlock reports no concurrent writer. netevent_callback amplifies this by waking ALL pending addr_req workers when ANY neighbor becomes NUD_VALID. At scale (N peers resolving ARP concurrently), the hit probability scales as N^2, making it near-certain for large RDMA workloads. N(A): neigh_update(A) W(A): addr_resolve(A) | [sleep] | write_lock_bh(&A->lock) | | A->nud_state = NUD_REACHABLE | | // A->ha is still 0 | | [woken by netevent_cb() of | another neighbour] | | dst_fetch_ha(A) | | A->nud_state & NUD_VALID | | read_seqbegin(&A->ha_lock) | | snapshot = A->ha /* 0 */ | | read_seqretry(&A->ha_lock) | | return snapshot | seqlock(&A->ha_lock) | A->ha = mac_A /* too late */ | sequnlock(&A->ha_lock) | write_unlock_bh(&A->lock) The incorrect/zero mac is read and programmed in the device QP while it was not yet updated. This causes silent packet loss and eventual RETRY_EXC_ERR. Fix by holding the neighbor read lock across the nud_state check and ha copy in dst_fetch_ha(), ensuring it synchronizes with __neigh_update() which is updating while holding the write lock. Cc: stable@vger.kernel.org Fixes: 92ebb6a0a13a ("IB/cm: Remove now useless rcu_lock in dst_fetch_ha") Link: https://patch.msgid.link/r/20260405-fix-dmac-race-v1-1-cfa1ec2ce54a@nvidia.com Signed-off-by: Chen Zhao Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ae59b3025609d5a0a39cf5b2b94e2467f6231573 Author: Junrui Luo Date: Sun Mar 1 21:10:58 2026 +0800 dm mirror: fix integer overflow in create_dirty_log() commit 4c788c6f921b22f9b6c3f316c4a071c05683e7de upstream. The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Reviewed-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 6dbeb0f788582e1ab5dfc3f41994eac0ec88c2b5 Author: Thorsten Blum Date: Sat Mar 14 20:36:29 2026 +0100 crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path commit bab1adf3b87e4bfac92c4f5963c63db434d561c1 upstream. Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak. Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c0f3002c02a3a83250e25582ffbe8df7eb78a8bd Author: Thorsten Blum Date: Sat Mar 7 16:31:10 2026 +0100 crypto: atmel-tdes - fix DMA sync direction commit c8a9a647532f5c2a04180352693215e24e9dba03 upstream. Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7cd17993adb8a5d14a7e84d751316a5fdf0c251f Author: Haoxiang Li Date: Mon Mar 30 11:34:02 2026 +0800 crypto: ccree - fix a memory leak in cc_mac_digest() commit 02c64052fad03699b9c6d1df2f9b444d17e4ac50 upstream. Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak. Fixes: 63893811b0fc ("crypto: ccree - add ahash support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6d8d6dcaf85d529f9258ceb09aa38b943fe516d8 Author: Thomas Fourier Date: Mon Mar 30 17:19:32 2026 +0200 crypto: hisilicon - Fix dma_unmap_single() direction commit 1ee57ab93b75eb59f426aef37b5498a7ffc28278 upstream. The direction used to map the buffer skreq->iv is DMA_TO_DEVICE but it is unmapped with direction DMA_BIDIRECTIONAL in the error path. Change the unmap to match the mapping. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Cc: Signed-off-by: Thomas Fourier Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f1e80f21dbb7e87d8f15ca2dd672d26734da8d3e Author: Thorsten Blum Date: Fri Feb 20 15:03:13 2026 +0100 crypto: atmel-ecc - Release client on allocation failure commit 095d50008d55d13f8fcf1bbeb7c6eba51779bc85 upstream. Call atmel_ecc_i2c_client_free() to release the I2C client reserved by atmel_ecc_i2c_client_alloc() when crypto_alloc_kpp() fails. Otherwise ->tfm_count will be out of sync. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 03e00aafa5f747d07811589e8d5fee638245431b Author: Thorsten Blum Date: Wed Mar 11 03:07:35 2026 +0100 crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup commit 3fcfff4ed35f963380a68741bcd52742baff7f76 upstream. atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak. Fixes: bbe628ed897d ("crypto: atmel-aes - improve performances of data transfer") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit edb513e736acbb14f3e90452e0648b1766268721 Author: Eric Biggers Date: Wed Feb 18 13:34:49 2026 -0800 crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit commit f8f08d7cc43237e91e3aedf7b67d015d24c38fcc upstream. Since the 'enc_after' argument to neon_aes_mac_update() and ce_aes_mac_update() has type 'int', it needs to be accessed using the corresponding 32-bit register, not the 64-bit register. The upper half of the corresponding 64-bit register may contain garbage. Fixes: 4860620da7e5 ("crypto: arm64/aes - add NEON/Crypto Extensions CBCMAC/CMAC/XCBC driver") Cc: stable@vger.kernel.org Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260218213501.136844-4-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 3df5b9110ac08f67ccfe382fc172bfee95688eec Author: Johan Hovold Date: Fri Mar 27 11:45:20 2026 +0100 can: ucan: fix devres lifetime commit fed4626501c871890da287bec62a96e52da1af89 upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind. Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Cc: stable@vger.kernel.org # 4.19 Cc: Jakob Unterwurzacher Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260327104520.1310158-1-johan@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b6ae482f88654db407c8c17619d4b62959b903ef Author: Shuvam Pandey Date: Thu Apr 9 00:32:30 2026 +0545 Bluetooth: hci_event: fix potential UAF in SSP passkey handlers commit 85fa3512048793076eef658f66489112dcc91993 upstream. hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path. Fixes: 92a25256f142 ("Bluetooth: mgmt: Implement support for passkey notification") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1867154a583909eb575fba367858098791760ea2 Author: Yiyang Chen Date: Mon Mar 30 03:00:40 2026 +0800 taskstats: set version in TGID exit notifications commit 16c4f0211aaa1ec1422b11b59f64f1abe9009fc0 upstream. delay accounting started populating taskstats records with a valid version field via fill_pid() and fill_tgid(). Later, commit ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") changed the TGID exit path to send the cached signal->stats aggregate directly instead of building the outgoing record through fill_tgid(). Unlike fill_tgid(), fill_tgid_exit() only accumulates accounting data and never initializes stats->version. As a result, TGID exit notifications can reach userspace with version == 0 even though PID exit notifications and TASKSTATS_CMD_GET replies carry a valid taskstats version. This is easy to reproduce with `tools/accounting/getdelays.c`. I have a small follow-up patch for that tool which: 1. increases the receive buffer/message size so the pid+tgid combined exit notification is not dropped/truncated 2. prints `stats->version`. With that patch, the reproducer is: Terminal 1: ./getdelays -d -v -l -m 0 Terminal 2: taskset -c 0 python3 -c 'import threading,time; t=threading.Thread(target=time.sleep,args=(0.1,)); t.start(); t.join()' That produces both PID and TGID exit notifications for the same process. The PID exit record reports a valid taskstats version, while the TGID exit record reports `version 0`. This patch (of 2): Set stats->version = TASKSTATS_VERSION after copying the cached TGID aggregate into the outgoing netlink payload so all taskstats records are self-describing again. Link: https://lkml.kernel.org/r/ba83d934e59edd431b693607de573eb9ca059309.1774810498.git.cyyzero16@gmail.com Fixes: ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") Signed-off-by: Yiyang Chen Cc: Balbir Singh Cc: Dr. Thomas Orgis Cc: Fan Yu Cc: Wang Yaxin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 14e9bb6eba8f59dcc637702e4744ae5e30660d76 Author: Zhenzhong Wu Date: Wed Apr 22 10:45:53 2026 +0800 tcp: call sk_data_ready() after listener migration commit 3864c6ba1e041bc75342353a70fa2a2c6f909923 upstream. When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly. Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.") Cc: stable@vger.kernel.org Suggested-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Signed-off-by: Zhenzhong Wu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422024554.130346-2-jt26wzz@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3ad9ccea1b25435f6179b57aa891960beb7ce8f9 Author: Chia-Ming Chang Date: Tue Feb 24 17:34:42 2026 +0800 inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails commit 6a320935fa4293e9e599ec9f85dc9eb3be7029f8 upstream. When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path. Fixes: 1cce1eea0aff ("inotify: Convert to using per-namespace limits") Cc: stable@vger.kernel.org Signed-off-by: Chia-Ming Chang Signed-off-by: robbieko Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260224093442.3076294-1-chiamingc@synology.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 28d3ff7109c66e99dc1b7cddacb5c760849620ef Author: Junrui Luo Date: Sat Apr 4 15:44:35 2026 +0800 md/raid5: validate payload size before accessing journal metadata commit b0cc3ae97e893bf54bbce447f4e9fd2e0b88bff9 upstream. r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing. Fixes: b4c625c67362 ("md/r5cache: r5cache recovery: part 1") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://lore.kernel.org/linux-raid/SYBPR01MB78815E78D829BB86CD7C8015AF5FA@SYBPR01MB7881.ausprd01.prod.outlook.com/ Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit a9055300e07d9d6800264d3c2560e1d0144689ca Author: Chia-Ming Chang Date: Thu Apr 2 14:14:06 2026 +0800 md/raid5: fix soft lockup in retry_aligned_read() commit 7f9f7c697474268d9ef9479df3ddfe7cdcfbbffc upstream. When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). Fixes: 773ca82fa1ee ("raid5: make release_stripe lockless") Cc: stable@vger.kernel.org Signed-off-by: FengWei Shih Signed-off-by: Chia-Ming Chang Link: https://lore.kernel.org/linux-raid/20260402061406.455755-1-chiamingc@synology.com/ Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit b706d00206a9e82362a9633efbd8b5775650169b Author: Sohei Koyama Date: Mon Apr 6 16:48:30 2026 +0900 ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() commit 77d059519382bd66283e6a4e83ee186e87e7708f upstream. The commit c8e008b60492 ("ext4: ignore xattrs past end") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse(). Fixes: c8e008b60492 ("ext4: ignore xattrs past end") Signed-off-by: Sohei Koyama Reviewed-by: Andreas Dilger Reviewed-by: Ritesh Harjani (IBM) Cc: stable@vger.kernel.org Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260406074830.8480-1-skoyama@ddn.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3c7f635c60a3512b7912602df804ca7cd1cd3659 Author: Jens Axboe Date: Sat May 2 01:51:56 2026 +0300 io_uring/poll: fix multishot recv missing EOF on wakeup race [ Upstream commit a68ed2df72131447d131531a08fe4dfcf4fa4653 ] When a socket send and shutdown() happen back-to-back, both fire wake-ups before the receiver's task_work has a chance to run. The first wake gets poll ownership (poll_refs=1), and the second bumps it to 2. When io_poll_check_events() runs, it calls io_poll_issue() which does a recv that reads the data and returns IOU_RETRY. The loop then drains all accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only the first event was consumed. Since the shutdown is a persistent state change, no further wakeups will happen, and the multishot recv can hang forever. Check specifically for HUP in the poll loop, and ensure that another loop is done to check for status if more than a single poll activation is pending. This ensures we don't lose the shutdown event. Backport notes for linux-6.1.y: - In 6.1.y the do-while masks v in the while-condition itself, so v can carry IO_POLL_RETRY_FLAG/IO_POLL_CANCEL_FLAG bits when we reach the multishot branch. The HUP check therefore compares `(v & IO_POLL_REF_MASK) != 1` rather than the upstream `v != 1`. - io_poll_issue takes `bool *locked` here (renamed to `ts` in 6.6+). - 6.1.y has no IOU_REQUEUE return path; only IOU_STOP_MULTISHOT. CVE: CVE-2026-23473 Cc: stable@vger.kernel.org # 6.1.y Fixes: dbc2564cfe0f ("io_uring: let fast poll support multishot") Reported-by: Francis Brosseau Link: https://github.com/axboe/liburing/issues/1549 Signed-off-by: Jens Axboe [backport for linux-6.1.y, verified 2026-05-01] Signed-off-by: Sasha Levin commit 2bf706fe7831b319f23a85b9728f961cfed40c3e Author: James Kim Date: Fri May 1 19:41:36 2026 -0400 mtd: docg3: fix use-after-free in docg3_release() [ Upstream commit ca19808bc6fac7e29420d8508df569b346b3e339 ] In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable. Fixes: c8ae3f744ddc ("lib/bch: Rework a little bit the exported function names") Cc: stable@vger.kernel.org Signed-off-by: James Kim Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit ff227ee399d0bff66f4c3a1109925db7a974d24a Author: Uwe Kleine-König Date: Fri May 1 19:41:35 2026 -0400 mtd: docg3: Convert to platform remove callback returning void [ Upstream commit eb0cec77d534413a800ec20944a2b1e37cfecdcf ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Signed-off-by: Miquel Raynal Acked-by: Tudor Ambarus Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-5-u.kleine-koenig@pengutronix.de Stable-dep-of: ca19808bc6fa ("mtd: docg3: fix use-after-free in docg3_release()") Signed-off-by: Sasha Levin commit dbf5e2cd93c44298e9a952654e9be8ccf2cccbca Author: Yosry Ahmed Date: Tue Mar 3 00:34:09 2026 +0000 KVM: nSVM: Add missing consistency check for nCR3 validity commit b71138fcc362c67ebe66747bb22cb4e6b4d6a651 upstream. From the APM Volume #2, 15.25.4 (24593—Rev. 3.42—March 2024): When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditions are considered illegal state combinations, in addition to those mentioned in “Canonicalization and Consistency Checks”: • Any MBZ bit of nCR3 is set. • Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. Add the consistency check for nCR3 being a legal GPA with no MBZ bits set. Note, the G_PAT.PA check is being handled separately[*]. Link: https://lore.kernel.org/kvm/20260205214326.1029278-3-jmattson@google.com [*] Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-16-yosry@kernel.org [sean: capture everything in CC(), massage changelog formatting] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5f680c0c93a5995b8ea3a6de3d45407361acd1bf Author: Yosry Ahmed Date: Tue Mar 3 00:34:10 2026 +0000 KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS commit 96bd3e76a171a8e21a6387e54e4c420a81968492 upstream. According to the APM Volume #2, 15.5, Canonicalization and Consistency Checks (24593—Rev. 3.42—March 2024), the following condition (among others) results in a #VMEXIT with VMEXIT_INVALID (aka SVM_EXIT_ERR): EFER.LME, CR0.PG, CR4.PAE, CS.L, and CS.D are all non-zero. In the list of consistency checks done when EFER.LME and CR0.PG are set, add a check that CS.L and CS.D are not both set, after the existing check that CR4.PAE is set. This is functionally a nop because the nested VMRUN results in SVM_EXIT_ERR in HW, which is forwarded to L1, but KVM makes all consistency checks before a VMRUN is actually attempted. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-17-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 801f23f52e65bb2673f7ded88c42f58ca157585c Author: Yosry Ahmed Date: Tue Mar 3 00:34:06 2026 +0000 KVM: nSVM: Clear tracking of L1->L2 NMI and soft IRQ on nested #VMEXIT commit 8998e1d012f3f45d0456f16706682cef04c3c436 upstream. KVM clears tracking of L1->L2 injected NMIs (i.e. nmi_l1_to_l2) and soft IRQs (i.e. soft_int_injected) on a synthesized #VMEXIT(INVALID) due to failed VMRUN. However, they are not explicitly cleared in other synthesized #VMEXITs. soft_int_injected is always cleared after the first VMRUN of L2 when completing interrupts, as any re-injection is then tracked by KVM (instead of purely in vmcb02). nmi_l1_to_l2 is not cleared after the first VMRUN if NMI injection failed, as KVM still needs to keep track that the NMI originated from L1 to avoid blocking NMIs for L1. It is only cleared when the NMI injection succeeds. KVM could synthesize a #VMEXIT to L1 before successfully injecting the NMI into L2 (e.g. due to a #NPF on L2's NMI handler in L1's NPTs). In this case, nmi_l1_to_l2 will remain true, and KVM may not correctly mask NMIs and intercept IRET when injecting an NMI into L1. Clear both nmi_l1_to_l2 and soft_int_injected in nested_svm_vmexit(), i.e. for all #VMEXITs except those that occur due to failed consistency checks, as those happen before nmi_l1_to_l2 or soft_int_injected are set. Fixes: 159fc6fa3b7d ("KVM: nSVM: Transparently handle L1 -> L2 NMI re-injection") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-13-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 8109791fa6b737ab4d2b03ef35f614d3e8539006 Author: Yosry Ahmed Date: Tue Mar 3 00:34:04 2026 +0000 KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID) commit f85a6ce06e4a0d49652f57967a649ab09e06287c upstream. According to the APM, GIF is set to 0 on any #VMEXIT, including an #VMEXIT(INVALID) due to failed consistency checks. Clear GIF on consistency check failures. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-11-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 6176a1675b3fc3f0f00b09947cb24fecdbccaea1 Author: Yosry Ahmed Date: Tue Mar 3 00:33:59 2026 +0000 KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN commit 01ddcdc55e097ca38c28ae656711b8e6d1df71f8 upstream. nested_svm_vmrun() currently only injects a #GP if kvm_vcpu_map() fails with -EINVAL. But it could also fail with -EFAULT if creating a host mapping failed. Inject a #GP in all cases, no reason to treat failure modes differently. Fixes: 8c5fbf1a7231 ("KVM/nSVM: Use the new mapping API for mapping guest memory") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-6-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 04fff615ae2961669ffee7b92b99b80872be1871 Author: Yosry Ahmed Date: Tue Feb 3 20:10:10 2026 +0000 KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT commit 5c247d08bc81bbad4c662dcf5654137a2f8483ec upstream. KVM currently uses the value of CR2 from vmcb02 to update vmcb12 on nested #VMEXIT. This value is incorrect in some cases, causing L1 to run L2 with a corrupted CR2. This could lead to segfaults or data corruption if L2 is in the middle of handling a #PF and reads a corrupted CR2. Use the correct value in vcpu->arch.cr2 instead. The value in vcpu->arch.cr2 is sync'd to vmcb02 shortly before a VMRUN of L2, and sync'd back to vcpu->arch.cr2 shortly after. The value are only out-of-sync in two cases: after save+restore, and after a #PF is injected into L2. In either case, if a #VMEXIT to L1 is synthesized before L2 runs, using the value in vmcb02 would be incorrect. After save+restore, the value of CR2 is restored by KVM_SET_SREGS into vcpu->arch.cr2. It is not reflect in vmcb02 until a VMRUN of L2. Before that, it holds whatever was in vmcb02 before restore, which would be zero on a new vCPU that never ran nested. If a #VMEXIT to L1 is synthesized before L2 ever runs, using vcpu->arch.cr2 to update vmcb12 is the right thing to do. The #PF injection case is more nuanced. Although the APM is a bit unclear about when CR2 is written during a #PF, the SDM is more clear: Processors update CR2 whenever a page fault is detected. If a second page fault occurs while an earlier page fault is being delivered, the faulting linear address of the second fault will overwrite the contents of CR2 (replacing the previous address). These updates to CR2 occur even if the page fault results in a double fault or occurs during the delivery of a double fault. KVM injecting the exception surely counts as the #PF being "detected". More importantly, when an exception is injected into L2 at the time of a synthesized #VMEXIT, KVM updates exit_int_info in vmcb12 accordingly, such that an L1 hypervisor can re-inject the exception. If CR2 is not written at that point, the L1 hypervisor have no way of correctly re-injecting the #PF. Hence, if a #VMEXIT to L1 is synthesized after the #PF is injected into L2 but before it actually runs, using vcpu->arch.cr2 to update vmcb12 is also the right thing to do. Note that KVM does _not_ update vcpu->arch.cr2 when a #PF is pending for L2, only when it is injected. The distinction is important, because only injected (but not intercepted) exceptions are propagated to L1 through exit_int_info. It would be incorrect to update CR2 in vmcb12 for a pending #PF, as L1 would perceive an updated CR2 value with no #PF. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260203201010.1871056-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 29bc5b3f7f8fadaab66fff908679f13ba05f366d Author: Yosry Ahmed Date: Tue Feb 24 22:50:17 2026 +0000 KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode commit 24f7d36b824b65cf1a2db3db478059187b2a37b0 upstream. On nested VMRUN, KVM ensures AVIC is inhibited by requesting KVM_REQ_APICV_UPDATE, triggering a check of inhibit reasons, finding APICV_INHIBIT_REASON_NESTED, and disabling AVIC. However, when KVM_SET_NESTED_STATE is performed on a vCPU not in guest mode with AVIC enabled, KVM_REQ_APICV_UPDATE is not requested, and AVIC is not inhibited. Request KVM_REQ_APICV_UPDATE in the KVM_SET_NESTED_STATE path if AVIC is active, similar to the nested VMRUN path. Fixes: f44509f849fe ("KVM: x86: SVM: allow AVIC to co-exist with a nested guest running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260224225017.3303870-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 2688a1a5a1075de32191483975676624e3b49c0d Author: Sean Christopherson Date: Wed Feb 18 15:09:51 2026 -0800 KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts commit d5bde6113aed8315a2bfe708730b721be9c2f48b upstream. When reacting to an intercept update, explicitly mark vmcb01's intercepts dirty, as KVM always initially operates on vmcb01, and nested_svm_vmexit() isn't guaranteed to mark VMCB_INTERCEPTS as dirty. I.e. if L2 is active, KVM will modify the intercepts for L1, but might not mark them as dirty before the next VMRUN of L1. Fixes: 116a0a23676e ("KVM: SVM: Add clean-bit for intercetps, tsc-offset and pause filter count") Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260218230958.2877682-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 491139c17f8ad5773303068411f6ac5eed438b51 Author: Kevin Cheng Date: Sat Feb 28 03:33:26 2026 +0000 KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 commit d99df02ff427f461102230f9c5b90a6c64ee8e23 upstream. INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. Fixes: ff092385e828 ("KVM: SVM: Implement INVLPGA") Cc: stable@vger.kernel.org Signed-off-by: Kevin Cheng Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260228033328.2285047-3-chengkev@google.com [sean: tag for stable@] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e39a77a9b1e17d2d831c304eafac4c41a784a0be Author: Yosry Ahmed Date: Wed Feb 25 00:59:44 2026 +0000 KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 commit 03bee264f8ebfd39e0254c98e112d033a7aa9055 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c9aac1b0344812002448f836c8e748624ef81021 Author: Yosry Ahmed Date: Wed Feb 25 00:59:43 2026 +0000 KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2 commit 778d8c1b2a6ffe622ddcd3bb35b620e6e41f4da0 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. NextRIP is also written by the CPU (in some cases) after VMRUN, but is not sync'd to the cached vmcb12. As a result, it is corrupted after save/restore (replaced by the original value written by L1 on nested VMRUN). This could cause problems for both KVM (e.g. when injecting a soft IRQ) or L1 (e.g. when using NextRIP to advance RIP after emulating an instruction). Fix this by sync'ing NextRIP to the cache after VMRUN of L2, but only after completing interrupts (not in nested_sync_control_from_vmcb02()), as KVM may update NextRIP (e.g. when re-injecting a soft IRQ). Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 084cd60fb6c808f453033651e6601df320af3cf1 Author: Yosry Ahmed Date: Tue Feb 10 01:08:06 2026 +0000 KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state commit e63fb1379f4b9300a44739964e69549bebbcdca4 upstream. When restoring a vCPU in guest mode, any state restored before KVM_SET_NESTED_STATE (e.g. KVM_SET_SREGS) will mark the corresponding dirty bits in vmcb01, as it is the active VMCB before switching to vmcb02 in svm_set_nested_state(). Hence, mark all fields in vmcb02 dirty in svm_set_nested_state() to capture any previously restored fields. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260210010806.3204289-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit bce0d2f57f967b856ee52cdef342f50bf66bd2f6 Author: Denis M. Karpov Date: Thu Apr 9 13:33:45 2026 +0300 userfaultfd: allow registration of ranges below mmap_min_addr commit 161ce69c2c89781784b945d8e281ff2da9dede9c upstream. The current implementation of validate_range() in fs/userfaultfd.c performs a hard check against mmap_min_addr. This is redundant because UFFDIO_REGISTER operates on memory ranges that must already be backed by a VMA. Enforcing mmap_min_addr or capability checks again in userfaultfd is unnecessary and prevents applications like binary compilers from using UFFD for valid memory regions mapped by application. Remove the redundant check for mmap_min_addr. We started using UFFD instead of the classic mprotect approach in the binary translator to track application writes. During development, we encountered this bug. The translator cannot control where the translated application chooses to map its memory and if the app requires a low-address area, UFFD fails, whereas mprotect would work just fine. I believe this is a genuine logic bug rather than an improvement, and I would appreciate including the fix in stable. Link: https://lore.kernel.org/20260409103345.15044-1-komlomal@gmail.com Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Denis M. Karpov Reviewed-by: Lorenzo Stoakes Acked-by: Harry Yoo (Oracle) Reviewed-by: Pedro Falcato Reviewed-by: Liam R. Howlett Reviewed-by: Mike Rapoport (Microsoft) Cc: Alexander Viro Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Jann Horn Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d076d33530d8bbc0a993d05ebe3df43ca4f610d3 Author: Johan Hovold Date: Tue Apr 7 14:27:17 2026 +0200 rtc: ntxec: fix OF node reference imbalance commit 30c4d2f26bb3538c328035cea2e6265c8320539e upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 435af89786c6 ("rtc: New driver for RTC in Netronix embedded controller") Cc: stable@vger.kernel.org # 5.13 Cc: Jonathan Neuschäfer Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260407122717.2676774-1-johan@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 4f047c307384177a2be012cc5e313f8ea13f2d14 Author: Jacqueline Wong Date: Wed Apr 15 16:00:05 2026 +0000 tpm: tpm_tis: add error logging for data transfer commit 0471921e2d1043dcc6de5cffb49dd37709521abe upstream. Add logging to more easily determine reason for transmit failure Cc: stable@vger.kernel.org # v6.6+ Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong Signed-off-by: Jordan Hand Link: https://lore.kernel.org/r/20260415160006.2275325-2-jacqwong@google.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit a73eff5b03dd40ad4346de86764d64f37289ac5c Author: Shawn Lin Date: Wed Apr 8 15:18:49 2026 +0800 mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration commit 6546a49bbe656981d99a389195560999058c89c4 upstream. According to the ASIC design recommendations, the clock must be disabled before operating the DLL to prevent glitches that could affect the internal digital logic. In extreme cases, failing to do so may cause the controller to malfunction completely. Adds a step to disable the clock before DLL configuration and re-enables it at the end. Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 897085cfe344839c7a30d5705fd19f1ad107f03a Author: Bin Liu Date: Wed Mar 25 08:49:47 2026 -0500 mmc: block: use single block write in retry commit c7c6d4f5103864f73ee3a78bfd6da241f84197dd upstream. Due to errata i2493[0], multi-block write would still fail in retries. With i2493, the MMC interface has the potential of write failures when issuing multi-block writes operating in HS200 mode with excessive IO supply noise. While the errata provides guidance in hardware design and layout to minimize the IO supply noise, in theory the write failure cannot be resolved in hardware. The software solution to ensure the data integrity is to add minimum 5us delay between block writes. Single-block write is the practical way to introduce the delay. This patch reuses recovery_mode flag, and switches to single-block write in retry when multi-block write fails. It covers both CQE and non-CQE cases. [0] https://www.ti.com/lit/pdf/sprz582 Cc: stable@vger.kernel.org Suggested-by: Jens Axboe Signed-off-by: Bin Liu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 94937d474a8946b1d845ab87551fc1288d113fd9 Author: Ryan Roberts Date: Tue Mar 3 15:08:38 2026 +0000 randomize_kstack: Maintain kstack_offset per task commit 37beb42560165869838e7d91724f3e629db64129 upstream. kstack_offset was previously maintained per-cpu, but this caused a couple of issues. So let's instead make it per-task. Issue 1: add_random_kstack_offset() and choose_random_kstack_offset() expected and required to be called with interrupts and preemption disabled so that it could manipulate per-cpu state. But arm64, loongarch and risc-v are calling them with interrupts and preemption enabled. I don't _think_ this causes any functional issues, but it's certainly unexpected and could lead to manipulating the wrong cpu's state, which could cause a minor performance degradation due to bouncing the cache lines. By maintaining the state per-task those functions can safely be called in preemptible context. Issue 2: add_random_kstack_offset() is called before executing the syscall and expands the stack using a previously chosen random offset. choose_random_kstack_offset() is called after executing the syscall and chooses and stores a new random offset for the next syscall. With per-cpu storage for this offset, an attacker could force cpu migration during the execution of the syscall and prevent the offset from being updated for the original cpu such that it is predictable for the next syscall on that cpu. By maintaining the state per-task, this problem goes away because the per-task random offset is updated after the syscall regardless of which cpu it is executing on. Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall") Closes: https://lore.kernel.org/all/dd8c37bc-795f-4c7a-9086-69e584d8ab24@arm.com/ Cc: stable@vger.kernel.org Acked-by: Mark Rutland Signed-off-by: Ryan Roberts Link: https://patch.msgid.link/20260303150840.3789438-2-ryan.roberts@arm.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 581dd3e3a25139ff71bac2599675af2568173259 Author: Krzysztof Kozlowski Date: Fri Feb 20 18:49:39 2026 +0100 power: supply: axp288_charger: Do not cancel work before initializing it commit 658342fd75b582cbb06544d513171c3d645faead upstream. Driver registered devm handler to cancel_work_sync() before even the work was initialized, thus leading to possible warning from kernel/workqueue.c on (!work->func) check, if the error path was hit before the initialization happened. Use devm_work_autocancel() on each work item independently, which handles the initialization and handler to cancel work. Fixes: 165c2357744e ("power: supply: axp288_charger: Properly stop work on probe-error / remove") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260220174938.672883-5-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 4a41d25163123c2a73817fafd290dbce0a260a65 Author: Huacai Chen Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Show CPU vulnerabilites correctly commit 37e57e8ad96cdec4a57b55fd10bef50f7370a954 upstream. Most LoongArch processors are vulnerable to Spectre-V1 Proof-of-Concept (PoC). And the generic mechanism, __user pointer sanitization, can be used as a mitigation. This means to use array_index_nospec() to prevent out of boundry access in syscall and other critical paths. Implement the arch-specific cpu_show_spectre_v1() to show CPU Spectre-V1 vulnerabilites correctly. Cc: stable@vger.kernel.org Link: https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/ Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit ba339d81ebdea58deb54b2ac2bf50d69ff9454e9 Author: Arnd Bergmann Date: Fri Mar 22 14:22:48 2024 +0100 tpm: avoid -Wunused-but-set-variable commit 6f1d4d2ecfcd1b577dc87350ea965fe81f272e83 upstream. Outside of the EFI tpm code, the TPM_MEMREMAP()/TPM_MEMUNMAP functions are defined as trivial macros, leading to the mapping_size variable ending up unused: In file included from drivers/char/tpm/tpm-sysfs.c:16: In file included from drivers/char/tpm/tpm.h:28: include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable] 167 | int mapping_size; Turn the stubs into inline functions to avoid this warning. Cc: stable@vger.kernel.org # v5.3+ Fixes: c46f3405692d ("tpm: Reserve the TPM final events table") Signed-off-by: Arnd Bergmann Reviewed-by: Thorsten Blum Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 03cb79df7354e6e3f1d1f55879a1f69cb87f7dea Author: Nathan Chancellor Date: Wed Mar 25 18:19:15 2026 -0700 extract-cert: Wrap key_pass with '#ifdef USE_PKCS11_ENGINE' commit 4f96b7c68a9904e01049ef610d701b382dca9574 upstream. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in certs/extract-cert.c: certs/extract-cert.c:46:20: error: variable 'key_pass' set but not used [-Werror,-Wunused-but-set-global] 46 | static const char *key_pass; | ^ After commit 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3"), key_pass is only used with the OpenSSL engine API, not the new provider API. Wrap key_pass's declaration and assignment with '#ifdef USE_PKCS11_ENGINE' so that it is only included with its use to clear up the warning. While this is a little uglier than just marking key_pass with the unused attribute, this will make it easier to clean up all code associated with the use of the engine API if it were ever removed in the future. While in the area, use a tab for the key_pass assignment line to match the rest of the file. Cc: stable@vger.kernel.org Fixes: 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3") Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Link: https://patch.msgid.link/20260325-certs-extract-cert-key_pass-unused-but-set-global-v1-1-ecf94326d532@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit f101271fcf55d7eacfefd610b51ec65f46ba8118 Author: Raphael Zimmer Date: Wed Mar 18 18:09:03 2026 +0100 libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() commit 5199c125d25aeae8615c4fc31652cc0fe624338e upstream. If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 93df2af4f491de33827550b9d420f01808c0706b Author: Ruide Cao Date: Tue Apr 21 12:16:31 2026 +0800 ipv4: icmp: validate reply type before using icmp_pointers commit 67bf002a2d7387a6312138210d0bd06e3cf4879b upstream. Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged. Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/0dace90c01a5978e829ca741ef684dbd7304ce62.1776628519.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2c0d71ef12f46c57d37bc571f3f2797db7eb50cc Author: hkbinbin Date: Wed Apr 1 12:19:07 2026 +0000 RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv commit 7244491dab347f648e661da96dc0febadd9daec3 upstream. rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. Cc: stable@vger.kernel.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260401121907.1468366-1-hkbinbinbin@gmail.com Signed-off-by: hkbinbin Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 17ae1759434fe467c889478b7b5d13689dbb3b06 Author: Luca Ceresoli Date: Thu Apr 2 18:42:20 2026 +0200 drm/arcpgu: fix device node leak commit ad3ac32a3893a2bbcad545efc005a8e4e7ecf10c upstream. This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but never puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: stable@vger.kernel.org Reviewed-by: Louis Chauvet Link: https://patch.msgid.link/20260402-drm-arcgpu-fix-device-node-leak-v2-1-d773cf754ae5@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 087e402dfd9da2ed202581e1de43745e3a3d0489 Author: Marek Vasut Date: Thu Apr 16 01:09:45 2026 +0200 net: ks8851: Avoid excess softirq scheduling commit 22230e68b2cf1ab6b027be8cf1198164a949c4fa upstream. The code injects a packet into netif_rx() repeatedly, which will add it to its internal NAPI and schedule a softirq, and process it. It is more efficient to queue multiple packets and process them all at the local_bh_enable() time. Reviewed-by: Sebastian Andrzej Siewior Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260415231020.455298-2-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1962027a6d223f90df8b372929f9d1a8d321ad6a Author: Marek Vasut Date: Thu Apr 16 01:09:44 2026 +0200 net: ks8851: Reinstate disabling of BHs around IRQ handler commit 5c9fcac3c872224316714d0d8914d9af16c76a6d upstream. If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28 Reviewed-by: Sebastian Andrzej Siewior Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260415231020.455298-1-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5eedbfd82c2884e0010fdfb3c9446a6ebcadb691 Author: Ruijie Li Date: Wed Apr 22 23:40:18 2026 +0800 net/smc: avoid early lgr access in smc_clc_wait_msg commit 5a8db80f721deee8e916c2cfdee78decda02ce4f upstream. A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available. Fixes: 0cfdd8f92cac ("smc: connection and link group creation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Ren Wei Reviewed-by: Dust Li Link: https://patch.msgid.link/08c68a5c817acf198cce63d22517e232e8d60718.1776850759.git.ruijieli51@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ec55a86f7fba7d9111df94b9c11a4755ed492995 Author: Ao Zhou Date: Wed Apr 22 22:52:07 2026 +0800 net: rds: fix MR cleanup on copy error commit 8141a2dc70080eda1aedc0389ed2db2b292af5bd upstream. __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path. Fixes: 0d4597c8c5ab ("net/rds: Track user mapped pages through special API") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ao Zhou Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/79c8ef73ec8e5844d71038983940cc2943099baf.1776764247.git.draw51280@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e73da2162115ce168e0e267932a435fdb8c070f2 Author: Yiyang Chen Date: Mon Mar 30 03:00:41 2026 +0800 tools/accounting: handle truncated taskstats netlink messages commit cc82b3dcc6a8fa259fbda12ab00d6fc00908a49e upstream. procacct and getdelays use a fixed receive buffer for taskstats generic netlink messages. A multi-threaded process exit can emit a single PID+TGID notification large enough to exceed that buffer on newer kernels. Switch to recvmsg() so MSG_TRUNC is detected explicitly, increase the message buffer size, and report truncated datagrams clearly instead of misparsing them as fatal netlink errors. Also print the taskstats version in debug output to make version mismatches easier to diagnose while inspecting taskstats traffic. Link: https://lkml.kernel.org/r/520308bb4cbbaf8dc2c7296b5f60f11e12fb30a5.1774810498.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen Cc: Balbir Singh Cc: Dr. Thomas Orgis Cc: Fan Yu Cc: Wang Yaxin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 891e22a9b94bdca1b29c038c1186cfde7442bec6 Author: Jonathan Santos Date: Mon Feb 23 08:59:26 2026 -0300 iio: adc: ad7768-1: fix one-shot mode data acquisition commit 8be19e233744961db6069da9c9ab63eb085a0447 upstream. According to the datasheet, one-shot mode requires a SYNC_IN pulse to trigger a new sample conversion. In the current implementation, No sync pulse was sent after switching to one-shot mode and reinit_completion() was called before mode switching, creating a race condition where spurious interrupts during mode change could trigger completion prematurely. Fix by sending a sync pulse after configuring one-shot mode and reinit_completion() to ensure it only waits for the actual conversion completion. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Santos Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b939749eff7a8471e91e866568950347a9939034 Author: Cássio Gabriel Date: Thu Apr 16 10:24:40 2026 -0300 ALSA: 6fire: Fix input volume change detection commit dc88eef8f55e85e92d016cdf7e291f5560efd79b upstream. usb6fire_control_input_vol_put() stores the analog capture volume as a signed offset in rt->input_vol[] (-15..+15), but it compares the cached value against the user-visible mixer value (0..30) before subtracting 15. This mixes two domains in the change detection path. Since the runtime is zero-initialized, the visible default is 15; writing 0 right after probe is ignored, while writing 15 is reported as a change even though the cached value remains 0. Normalize the user value before comparing it with the cached offset. Fixes: 06bb4e743501 ("ALSA: snd-usb-6fire: add analog input volume control") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260416-alsa-6fire-input-volume-change-detection-v1-1-ec78299168df@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b956e48371f2ff72b76be9a829800ecec963bd45 Author: Takashi Iwai Date: Tue Apr 14 12:59:00 2026 +0200 ALSA: caiaq: Handle probe errors properly commit 28abd224db4a49560b452115bca3672a20e45b2f upstream. The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks. Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20260413034941.1131465-2-berkcgoksel@gmail.com Link: https://patch.msgid.link/20260414105916.364073-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3753f58ab5f7dc6aa7ad7872daa399c8a506b88d Author: Cássio Gabriel Date: Fri Apr 17 10:41:33 2026 -0300 ALSA: caiaq: Fix control_put() result and cache rollback commit a3542d1b30f92307f545f2def14e8d988dffdff0 upstream. control_put() always returns 1 and updates cdev->control_state[] before sending the USB command. It also ignores transport errors from usb_bulk_msg(), snd_usb_caiaq_send_command(), and snd_usb_caiaq_send_command_bank(). That breaks the ALSA .put() contract and can leave control_get() reporting a cached value the device never accepted. Return 0 for unchanged values, propagate transport failures, and restore the cached byte when the write fails. Fixes: 8e3cd08ed8e59 ("[ALSA] caiaq - add control API and more input features") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260417-caiaq-control-put-v1-1-c37826e92447@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f5cadc02c73d964c148853320b0612139f17d9eb Author: Takashi Iwai Date: Mon Apr 20 08:17:20 2026 +0200 ALSA: core: Fix potential data race at fasync handling commit 8146cd333d235ed32d48bb803fdf743472d7c783 upstream. In snd_fasync_work_fn(), which is the offload work for traversing and processing the pending fasync list, the call of kill_fasync() is done outside the snd_fasync_lock for avoiding deadlocks. The problem is that its the references of fasync->on, fasync->signal and fasync->poll are done there also outside the lock. Since these may be modified by snd_kill_fasync() call concurrently from other process, inconsistent values might be passed to kill_fasync(). Although there shouldn't be critical UAF, it's still better to be addressed. This patch moves the kill_fasync() argument evaluations inside the snd_fasync_lock for avoiding the data races above. The handling in fasync->on flag is optimized in the loop to skip directly. Also, for more clarity, snd_fasync_free() takes the lock and unlink the pending entry more directly instead of clearing fasync->on flag. Reported-by: Jake Lamberson Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers") Cc: Link: https://patch.msgid.link/20260420061721.3253644-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 39ccd10522e01ba96b99487758dfa9395364d868 Author: Jens Axboe Date: Tue Apr 21 13:24:33 2026 -0600 io_uring/poll: ensure EPOLL_ONESHOT is propagated for EPOLL_URING_WAKE commit 1967f0b1cafdde37aa9e08e6021c14bcc484b7a5 upstream. Commit: aacf2f9f382c ("io_uring: fix req->apoll_events") fixed an issue where poll->events and req->apoll_events weren't synchronized, but then when the commit referenced in Fixes got added, it didn't ensure the same thing. If we mask in EPOLLONESHOT in the regular EPOLL_URING_WAKE path, then ensure it's done for both. Including a link to the original report below, even though it's mostly nonsense. But it includes a reproducer that does show that IORING_CQE_F_MORE is set in the previous CQE, while no more CQEs will be generated for this request. Just ignore anything that pretends this is security related in any way, it's just the typical AI nonsense. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/io-uring/CAM0zi7yQzF3eKncgHo4iVM5yFLAjsiob_ucqyWKs=hyd_GqiMg@mail.gmail.com/ Reported-by: Azizcan Daştan Fixes: 4464853277d0 ("io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 81bf96b0abbfa4cd47ea32e12596aed3855fb2f3 Author: Longxuan Yu Date: Sun Apr 12 16:38:20 2026 +0800 io_uring/poll: fix signed comparison in io_poll_get_ownership() commit 326941b22806cbf2df1fbfe902b7908b368cce42 upstream. io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath. Fixes: a26a35e9019f ("io_uring: make poll refs more robust") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Zhengchuan Liang Signed-off-by: Longxuan Yu Signed-off-by: Ren Wei Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/3a3508b08bcd7f1bc3beff848ae6e1d73d355043.1775965597.git.ylong030@ucr.edu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b285a41e751a0ae8ea651314b51efd8ef041ee82 Author: David Lechner Date: Sat Mar 14 16:12:24 2026 -0500 iio: adc: ti-ads7950: use iio_push_to_buffers_with_ts_unaligned() commit 7806c060cceb2d6895efbb6cff2f2f17cf1ec5de upstream. Use iio_push_to_buffers_with_ts_unaligned() to avoid unaligned access when writing the timestamp in the rx_buf. The previous implementation would have been fine on architectures that support 4-byte alignment of 64-bit integers but could cause issues on architectures that require 8-byte alignment. Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips") Signed-off-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6cb599b80233f2a30734e28f2943ecca667d9bae Author: Pavel Begunkov Date: Mon Mar 2 13:10:34 2026 +0000 io_uring/timeout: check unused sqe fields commit 484ae637a3e3d909718de7c07afd3bb34b6b8504 upstream. Zero check unused SQE fields addr3 and pad2 for timeout and timeout update requests. They're not needed now, but could be used sometime in the future. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 78bd0c143dea4b7a4c23c13356987ca0eafb442e Author: Dawei Feng Date: Sun Apr 19 17:03:48 2026 +0800 rbd: fix null-ptr-deref when device_add_disk() fails commit d1fef92e414433ca7b89abf85cb0df42b8d475eb upstream. do_rbd_add() publishes the device with device_add() before calling device_add_disk(). If device_add_disk() fails after device_add() succeeds, the error path calls rbd_free_disk() directly and then later falls through to rbd_dev_device_release(), which calls rbd_free_disk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set(). Fix this by following the normal remove ordering: call device_del() before rbd_dev_device_release() when device_add_disk() fails after device_add(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer confines failslab injections to the __add_disk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/add_single_major. On the unpatched kernel, fail-nth=4 reliably triggered the fault: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 PKRU: 55555554 Call Trace: blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ? __pfx_do_rbd_add+0x10/0x10 ? lock_acquire+0x18c/0x300 ? find_held_lock+0x2b/0x80 ? sysfs_file_kobj+0xb6/0x1b0 ? __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ? expand_files+0x51f/0x850 ? __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0fbea15907 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports. [ idryomov: rename err_out_device_del -> err_out_device ] Cc: stable@vger.kernel.org Fixes: 27c97abc30e2 ("rbd: add add_disk() error handling") Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 5a77990b764327fb38abed6ee318b532d22303b9 Author: Simon Liebold Date: Thu Mar 12 14:02:00 2026 +0000 selftests/mqueue: Fix incorrectly named file commit 64fac99037689020ad97e472ae898e96ea3616dc upstream. Commit 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") intended to increase the timeout for mq_perf_tests from the default kselftest limit of 45 seconds to 180 seconds. Unfortunately, the file storing this information was incorrectly named `setting` instead of `settings`, causing the kselftest runner not to pick up the limit and keep using the default 45 seconds limit. Fix this by renaming it to `settings` to ensure that the kselftest runner uses the increased timeout of 180 seconds for this test. Fixes: 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") Cc: # 5.10.y Signed-off-by: Simon Liebold Link: https://lore.kernel.org/r/20260312140200.2224850-1-simonlie@amazon.de Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit b397345cbbcf3f37cd77438d3ddddf45ee847bae Author: Helge Deller Date: Tue Apr 7 23:56:28 2026 +0200 parisc: _llseek syscall is only available for 32-bit userspace commit da3680f564bd787ce974f9931e6e924d908b3b2a upstream. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 818c1d02a4bdb3cd5b9331f0ebd15191d5ce8a7b Author: Robert Beckett Date: Fri Mar 20 19:22:08 2026 +0000 nvme: respect NVME_QUIRK_DISABLE_WRITE_ZEROES when wzsl is set commit 40f0496b617b431f8d2dd94d7f785c1121f8a68a upstream. The NVM Command Set Identify Controller data may report a non-zero Write Zeroes Size Limit (wzsl). When present, nvme_init_non_mdts_limits() unconditionally overrides max_zeroes_sectors from wzsl, even if NVME_QUIRK_DISABLE_WRITE_ZEROES previously set it to zero. This effectively re-enables write zeroes for devices that need it disabled, defeating the quirk. Several Kingston OM* drives rely on this quirk to avoid firmware issues with write zeroes commands. Check for the quirk before applying the wzsl override. Fixes: 5befc7c26e5a ("nvme: implement non-mdts command limits") Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit cd87d44dc2365953b818ee2f4cbe2e5c5733de1d Author: Robert Beckett Date: Fri Mar 20 19:22:09 2026 +0000 nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4 commit a8eebf9699d69987cc49cec4e4fdb4111ab32423 upstream. The Kingston OM3SGP42048K2-A00 (PCI ID 2646:502f) firmware has a race condition when processing concurrent write zeroes and DSM (discard) commands, causing spurious "LBA Out of Range" errors and IOMMU page faults at address 0x0. The issue is reliably triggered by running two concurrent mkfs commands on different partitions of the same drive, which generates interleaved write zeroes and discard operations. Disable write zeroes for this device, matching the pattern used for other Kingston OM* drives that have similar firmware issues. Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit ae356d5eb1331d678985799f893e436314834a87 Author: Josh Hunt Date: Mon Mar 2 19:56:19 2026 -0500 md/raid10: fix deadlock with check operation and nowait requests commit 7d96f3120a7fb7210d21b520c5b6f495da6ba436 upstream. When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") Cc: stable@vger.kernel.org Signed-off-by: Josh Hunt Link: https://lore.kernel.org/linux-raid/20260303005619.1352958-1-johunt@akamai.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 80a23c6d1aba35be8746d74ac14e6ba5ae46da21 Author: Gao Xiang Date: Tue Apr 21 15:59:52 2026 +0800 erofs: fix the out-of-bounds nameoff handling for trailing dirents commit d18a3b5d337fa412a38e776e6b4b857a58836575 upstream. Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations") Fixes: 33bac912840f ("staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()") Reported-by: Yuhao Jiang Reported-by: Junrui Luo Closes: https://lore.kernel.org/r/A0FD7E0F-7558-49B0-8BC8-EB1ECDB2479A@outlook.com Cc: stable@vger.kernel.org Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Greg Kroah-Hartman commit 679c69324952350978b9306db5bfd52a7b281c60 Author: Cássio Gabriel Date: Tue Mar 24 16:59:41 2026 -0300 ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes commit bbc6c0dda54fc0ad8f8aed0b796c23e186e1a188 upstream. snd_seq_oss_write() currently returns the raw load_patch() callback result for SEQ_FULLSIZE events. That callback is documented as returning 0 on success and -errno on failure, but snd_seq_oss_write() is the file write path and should report the number of user bytes consumed on success. Some in-tree backends also return backend-specific positive values, which can still be shorter than the original write size. Return the full byte count for successful SEQ_FULLSIZE writes. Preserve negative errors and convert any nonnegative completion to the original count. Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260324-alsa-seq-oss-fullsize-write-return-v1-1-66d448510538@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dfc00979ff00d9dfdfa1df32144a272ee2728102 Author: Harin Lee Date: Mon Apr 6 16:49:13 2026 +0900 ALSA: ctxfi: Add fallback to default RSR for S/PDIF commit 7d61662197ecdc458e33e475b6ada7f6da61d364 upstream. spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR. Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260406074913.217374-1-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e921a776869bb7c474db40d0f913bb1e8ab08a8c Author: Cássio Gabriel Date: Mon Mar 30 01:00:34 2026 -0300 ALSA: aoa: i2sbus: fix OF node lifetime handling commit 4ec93f070eda6b765b62efcaed9241c3b3b0b6ad upstream. i2sbus_add_dev() keeps the matched "sound" child pointer after for_each_child_of_node() has dropped the iterator reference. Take an extra reference before saving that node and drop it after the layout-id/device-id lookup is complete. The function also stores np in dev->sound.ofdev.dev.of_node without taking a reference for the embedded soundbus device. Since i2sbus overrides the embedded platform device release callback, balance that reference explicitly in the local error path and in i2sbus_release_dev(). Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260330-aoa-i2sbus-ofnode-lifetime-v1-1-51c309f4ff06@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a69a0c5156b6f0092b9fcf44517f5831a962de2d Author: Vasiliy Kovalev Date: Sat Apr 4 18:20:11 2026 +0300 ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() commit 25947cc5b2374cd5bf627fe3141496444260d04f upstream. ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20260404152011.2590197-1-kovalev@altlinux.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 4ae0bd51bf7079e9c2a06b5de0ae04ba70d10167 Author: Manivannan Sadhasivam Date: Thu Apr 9 23:04:16 2026 +0530 net: qrtr: ns: Fix use-after-free in driver remove() commit 7809fea20c9404bfcfa6112ec08d1fe1d3520beb upstream. In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback. Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-5-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7e8ec90bca496ba8ba227ce6cfb498c2d44c7a0e Author: Chen Ni Date: Wed Feb 4 10:48:59 2026 +0800 media: i2c: imx219: Check return value of devm_gpiod_get_optional() in imx219_probe() commit 943b1f27a3eead21b22e2531a5432ea5910b60eb upstream. The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org Signed-off-by: Chen Ni Reviewed-by: Dave Stevenson Reviewed-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit da50cf7fea42476d98a9b41d2613c9ed2a043089 Author: Josh Law Date: Sun Mar 8 20:20:28 2026 +0000 lib/ts_kmp: fix integer overflow in pattern length calculation commit 8cdf30813ea8ce881cecc08664144416dbdb3e16 upstream. The ts_kmp algorithm stores its prefix_tbl[] table and pattern in a single allocation sized from the pattern length. If the prefix_tbl[] size calculation wraps, the resulting allocation can be too small and subsequent pattern copies can overflow it. Fix this by rejecting zero-length patterns and by using overflow helpers before calculating the combined allocation size. This fixes a potential heap overflow. The pattern length calculation can wrap during a size_t addition, leading to an undersized allocation. Because the textsearch library is reachable from userspace via Netfilter's xt_string module, this is a security risk that should be backported to LTS kernels. Link: https://lkml.kernel.org/r/20260308202028.2889285-2-objecting@objecting.org Signed-off-by: Josh Law Reviewed-by: Andrew Morton Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e054411bd54bd37e6877e06e743c3fb86610ba24 Author: Rong Zhang Date: Wed Mar 4 03:47:56 2026 +0800 Revert "ALSA: usb: Increase volume range that triggers a warning" commit 41d78cb724f4b40b7548af420ccfe524b14023bb upstream. UAC uses 2 bytes to store volume values, so the maximum volume range is 0xFFFF (65535, val = -32768/32767/1). The reverted commit bumpped the range of triggering the warning to > 65535, effectively making the range check a no-op. It didn't fix anything but covered any potential problems and deviated from the original intention of the range check. This reverts commit 6b971191fcfc9e3c2c0143eea22534f1f48dbb62. Fixes: 6b971191fcfc ("ALSA: usb: Increase volume range that triggers a warning") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Acked-by: Arun Raghavan Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260303194805.266158-2-i@rong.moe Signed-off-by: Greg Kroah-Hartman commit c72f6a7ea638f95c486a5cfd86e567b646027687 Author: Koichiro Den Date: Thu Feb 26 17:41:39 2026 +0900 PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown commit 3446beddba450c8d6f9aca2f028712ac527fead3 upstream. epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-3-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit c2e57695ec9ff9d42f23de70f3805199153d007b Author: Luxiao Xu Date: Sat Apr 11 23:10:10 2026 +0800 net: strparser: fix skb_head leak in strp_abort_strp() commit fe72340daaf1af588be88056faf98965f39e6032 upstream. When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized. Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuan Tan Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/ade3857a9404999ce9a1c27ec523efc896072678.1775482694.git.rakukuip@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e16859f3f4426fa349bc5519d582a93d28f5a15d Author: Zhengchuan Liang Date: Sat Apr 11 23:10:26 2026 +0800 net: caif: clear client service pointer on teardown commit f7cf8ece8cee3c1ee361991470cdb1eb65ab02e8 upstream. `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless. Fixes: 43e369210108 ("caif: Move refcount from service layer to sock and dev.") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Link: https://patch.msgid.link/9f3d37847c0037568aae698ca23cd47c6691acb0.1775897577.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a470f7cabc4df72d9bd132f5719a8717292bb440 Author: Ziqing Chen Date: Tue Apr 14 21:24:37 2026 +0800 ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() commit e0da8a8cac74f4b9f577979d131f0d2b88a84487 upstream. snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone. Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls") Cc: stable@vger.kernel.org Signed-off-by: Ziqing Chen Link: https://patch.msgid.link/20260414132437.261304-1-chenziqing@xiaomi.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 516467052fdfc6a13eadc70d43420ae57436bf3c Author: Ming Qian Date: Fri Mar 6 14:59:50 2026 +0800 media: amphion: Fix race between m2m job_abort and device_run commit 8cd35ceadcfc8c5da2eb7f7ce24525ce9d4ee62e upstream. Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 76641449b28979ebd6c02e9598367e119e385236 Author: Herbert Xu Date: Thu Apr 16 17:00:50 2026 +0800 crypto: pcrypt - Fix handling of MAY_BACKLOG requests commit 915b692e6cb723aac658c25eb82c58fd81235110 upstream. MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. Reported-by: Yiming Qian Fixes: 5a1436beec57 ("crypto: pcrypt - call the complete function on error") Signed-off-by: Herbert Xu Cc: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 88b2ddb0c4f1dc874d4598e78cc830c64315ed86 Author: Chao Yu Date: Thu Apr 30 13:55:37 2026 +0800 f2fs: fix to detect potential corrupted nid in free_nid_list [ Upstream commit 8fc6056dcf79937c46c97fa4996cda65956437a9 ] As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Robert Garcia Signed-off-by: Sasha Levin commit 75998efcc67232caf173c844bbcbe43e78991f78 Author: Michael Bommarito Date: Wed Apr 8 03:01:02 2026 -0400 um: drivers: call kernel_strrchr() explicitly in cow_user.c commit 91e901c65b4da02a6fd543e3f0049829ae9645b7 upstream. Building ARCH=um on glibc >= 2.43 fails: arch/um/drivers/cow_user.c: error: implicit declaration of function 'strrchr' [-Wimplicit-function-declaration] glibc 2.43's C23 const-preserving strrchr() macro does not survive UML's global -Dstrrchr=kernel_strrchr remap from arch/um/Makefile. Call kernel_strrchr() directly in cow_user.c so the source no longer depends on the -D rewrite. Fixes: 2c51a4bc0233 ("um: fix strrchr() problems") Suggested-by: Johannes Berg Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260408070102.2325572-1-michael.bommarito@gmail.com [remove unnecessary 'extern'] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3b89b4c095804c478d50376285e66700cf3c045f Author: Fedor Pchelkin Date: Fri Feb 20 12:47:30 2026 +0300 wifi: rtw88: check for PCI upstream bridge existence commit eb101d2abdcccb514ca4fccd3b278dd8267374f6 upstream. pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 24f5e38a13b5 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260220094730.49791-1-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 2eb63502ebe0b58a1f2dc2dbe5392d42cbc4ff4b Author: Douglas Anderson Date: Mon Apr 27 10:17:02 2026 -0700 driver core: Don't let a device probe until it's ready [ Upstream commit a2225b6e834a838ae3c93709760edc0a169eb2f2 ] The moment we link a "struct device" into the list of devices for the bus, it's possible probe can happen. This is because another thread can load the driver at any time and that can cause the device to probe. This has been seen in practice with a stack crawl that looks like this [1]: really_probe() __driver_probe_device() driver_probe_device() __driver_attach() bus_for_each_dev() driver_attach() bus_add_driver() driver_register() __platform_driver_register() init_module() [some module] do_one_initcall() do_init_module() load_module() __arm64_sys_finit_module() invoke_syscall() As a result of the above, it was seen that device_links_driver_bound() could be called for the device before "dev->fwnode->dev" was assigned. This prevented __fw_devlink_pickup_dangling_consumers() from being called which meant that other devices waiting on our driver's sub-nodes were stuck deferring forever. It's believed that this problem is showing up suddenly for two reasons: 1. Android has recently (last ~1 year) implemented an optimization to the order it loads modules [2]. When devices opt-in to this faster loading, modules are loaded one-after-the-other very quickly. This is unlike how other distributions do it. The reproduction of this problem has only been seen on devices that opt-in to Android's "parallel module loading". 2. Android devices typically opt-in to fw_devlink, and the most noticeable issue is the NULL "dev->fwnode->dev" in device_links_driver_bound(). fw_devlink is somewhat new code and also not in use by all Linux devices. Even though the specific symptom where "dev->fwnode->dev" wasn't assigned could be fixed by moving that assignment higher in device_add(), other parts of device_add() (like the call to device_pm_add()) are also important to run before probe. Only moving the "dev->fwnode->dev" assignment would likely fix the current symptoms but lead to difficult-to-debug problems in the future. Fix the problem by preventing probe until device_add() has run far enough that the device is ready to probe. If somehow we end up trying to probe before we're allowed, __driver_probe_device() will return -EPROBE_DEFER which will make certain the device is noticed. In the race condition that was seen with Android's faster module loading, we will temporarily add the device to the deferred list and then take it off immediately when device_add() probes the device. Instead of adding another flag to the bitfields already in "struct device", instead add a new "flags" field and use that. This allows us to freely change the bit from different thread without worrying about corrupting nearby bits (and means threads changing other bit won't corrupt us). [1] Captured on a machine running a downstream 6.6 kernel [2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel Cc: stable@vger.kernel.org Fixes: 2023c610dc54 ("Driver core: add new device to bus's list before probing") Reviewed-by: Alan Stern Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Acked-by: Greg Kroah-Hartman Acked-by: Marek Szyprowski Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid Signed-off-by: Danilo Krummrich Signed-off-by: Douglas Anderson Signed-off-by: Sasha Levin commit 91e05ac2336d00d5b99fc774be4bd50039084796 Author: Heming Zhao Date: Thu Apr 2 21:43:27 2026 +0800 ocfs2: split transactions in dio completion to avoid credit exhaustion commit d647c5b2fbf81560818dacade360abc8c00a9665 upstream. During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions. Link: https://lkml.kernel.org/r/20260402134328.27334-2-heming.zhao@suse.com Signed-off-by: Heming Zhao Suggested-by: Jan Kara Suggested-by: Joseph Qi Reviewed-by: Jan Kara Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0903a08f3c55f15f7d951dd12b6b01f8bbab3eb3 Author: Douglas Anderson Date: Tue Mar 17 09:01:20 2026 -0700 device property: Make modifications of fwnode "flags" thread safe commit f72e77c33e4b5657af35125e75bab249256030f3 upstream. In various places in the kernel, we modify the fwnode "flags" member by doing either: fwnode->flags |= SOME_FLAG; fwnode->flags &= ~SOME_FLAG; This type of modification is not thread-safe. If two threads are both mucking with the flags at the same time then one can clobber the other. While flags are often modified while under the "fwnode_link_lock", this is not universally true. Create some accessor functions for setting, clearing, and testing the FWNODE flags and move all users to these accessor functions. New accessor functions use set_bit() and clear_bit(), which are thread-safe. Cc: stable@vger.kernel.org Fixes: c2c724c868c4 ("driver core: Add fw_devlink_parse_fwtree()") Reviewed-by: Andy Shevchenko Acked-by: Mark Brown Reviewed-by: Wolfram Sang Signed-off-by: Douglas Anderson Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/20260317090112.v2.1.I0a4d03104ecd5103df3d76f66c8d21b1d15a2e38@changeid [ Fix fwnode_clear_flag() argument alignment, restore dropped blank line in fwnode_dev_initialized(), and remove unnecessary parentheses around fwnode_test_flag() calls. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Douglas Anderson Signed-off-by: Greg Kroah-Hartman commit af6e82a9dc86d01c30ca781731aca49cda8b714c Author: Douglas Anderson Date: Sat Apr 25 14:49:50 2026 +0800 regset: use kvzalloc() for regset_get_alloc() commit 6b839b3b76cf17296ebd4a893841f32cae08229c upstream. While browsing through ChromeOS crash reports, I found one with an allocation failure that looked like this: chrome: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=urgent,mems_allowed=0 CPU: 7 PID: 3295 Comm: chrome Not tainted 5.15.133-20574-g8044615ac35c #1 (HASH:1162 1) Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT) Call trace: ... warn_alloc+0x104/0x174 __alloc_pages+0x5f0/0x6e4 kmalloc_order+0x44/0x98 kmalloc_order_trace+0x34/0x124 __kmalloc+0x228/0x36c __regset_get+0x68/0xcc regset_get_alloc+0x1c/0x28 elf_core_dump+0x3d8/0xd8c do_coredump+0xeb8/0x1378 get_signal+0x14c/0x804 ... An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not a surprise that this allocation failed on a system that's been running for a while. More digging showed that it was fairly easy to see the order 7 allocation by just sending a SIGQUIT to chrome (or other processes) to generate a core dump. The actual amount being allocated was 279,584 bytes and it was for "core_note_type" NT_ARM_SVE. There was quite a bit of discussion [1] on the mailing lists in response to my v1 patch attempting to switch to vmalloc. The overall conclusion was that we could likely reduce the 279,584 byte allocation by quite a bit and Mark Brown has sent a patch to that effect [2]. However even with the 279,584 byte allocation gone there are still 65,552 byte allocations. These are just barely more than the 65,536 bytes and thus would require an order 5 allocation. An order 5 allocation is still something to avoid unless necessary and nothing needs the memory here to be contiguous. Change the allocation to kvzalloc() which should still be efficient for small allocations but doesn't force the memory subsystem to work hard (and maybe fail) at getting a large contiguous chunk. [1] https://lore.kernel.org/r/20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid [2] https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org Link: https://lkml.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid Signed-off-by: Douglas Anderson Reviewed-by: Catalin Marinas Cc: Al Viro Cc: Christian Brauner Cc: Dave Martin Cc: Eric Biederman Cc: Jan Kara Cc: Kees Cook Cc: Mark Brown Cc: Matthew Wilcox (Oracle) Cc: Oleg Nesterov Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Wen Yang Signed-off-by: Sasha Levin commit 47d74b54180b6b296b489b7895011c9a28979ff1 Author: Youngmin Nam Date: Mon Apr 27 17:22:48 2026 +0800 arm64: set __exception_irq_entry with __irq_entry as a default [ Upstream commit f6794950f0e5ba37e3bbedda4d6ab0aad7395dd3 ] filter_irq_stacks() is supposed to cut entries which are related irq entries from its call stack. And in_irqentry_text() which is called by filter_irq_stacks() uses __irqentry_text_start/end symbol to find irq entries in callstack. But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER", arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq between __irqentry_text_start and __irqentry_text_end as we discussed in below link. https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t This problem can makes unintentional deep call stack entries especially in KASAN enabled situation as below. [ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity [ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c [ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--) [ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c [ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c [ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0 [ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000 [ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd [ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040 [ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000 [ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20 [ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8 [ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800 [ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8 [ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c [ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022 [ 2479.386231]I[0:launcher-loader: 1719] Call trace: [ 2479.386248]I[0:launcher-loader: 1719] __stack_depot_save+0x464/0x46c [ 2479.386273]I[0:launcher-loader: 1719] kasan_save_stack+0x58/0x70 [ 2479.386303]I[0:launcher-loader: 1719] save_stack_info+0x34/0x138 [ 2479.386331]I[0:launcher-loader: 1719] kasan_save_free_info+0x18/0x24 [ 2479.386358]I[0:launcher-loader: 1719] ____kasan_slab_free+0x16c/0x170 [ 2479.386385]I[0:launcher-loader: 1719] __kasan_slab_free+0x10/0x20 [ 2479.386410]I[0:launcher-loader: 1719] kmem_cache_free+0x238/0x53c [ 2479.386435]I[0:launcher-loader: 1719] mempool_free_slab+0x1c/0x28 [ 2479.386460]I[0:launcher-loader: 1719] mempool_free+0x7c/0x1a0 [ 2479.386484]I[0:launcher-loader: 1719] bvec_free+0x34/0x80 [ 2479.386514]I[0:launcher-loader: 1719] bio_free+0x60/0x98 [ 2479.386540]I[0:launcher-loader: 1719] bio_put+0x50/0x21c [ 2479.386567]I[0:launcher-loader: 1719] f2fs_write_end_io+0x4ac/0x4d0 [ 2479.386594]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386622]I[0:launcher-loader: 1719] __dm_io_complete+0x324/0x37c [ 2479.386650]I[0:launcher-loader: 1719] dm_io_dec_pending+0x60/0xa4 [ 2479.386676]I[0:launcher-loader: 1719] clone_endio+0xf8/0x2f0 [ 2479.386700]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386727]I[0:launcher-loader: 1719] blk_update_request+0x258/0x63c [ 2479.386754]I[0:launcher-loader: 1719] scsi_end_request+0x50/0x304 [ 2479.386782]I[0:launcher-loader: 1719] scsi_io_completion+0x88/0x160 [ 2479.386808]I[0:launcher-loader: 1719] scsi_finish_command+0x17c/0x194 [ 2479.386833]I[0:launcher-loader: 1719] scsi_complete+0xcc/0x158 [ 2479.386859]I[0:launcher-loader: 1719] blk_mq_complete_request+0x4c/0x5c [ 2479.386885]I[0:launcher-loader: 1719] scsi_done_internal+0xf4/0x1e0 [ 2479.386910]I[0:launcher-loader: 1719] scsi_done+0x14/0x20 [ 2479.386935]I[0:launcher-loader: 1719] ufshcd_compl_one_cqe+0x578/0x71c [ 2479.386963]I[0:launcher-loader: 1719] ufshcd_mcq_poll_cqe_nolock+0xc8/0x150 [ 2479.386991]I[0:launcher-loader: 1719] ufshcd_intr+0x868/0xc0c [ 2479.387017]I[0:launcher-loader: 1719] __handle_irq_event_percpu+0xd0/0x348 [ 2479.387044]I[0:launcher-loader: 1719] handle_irq_event_percpu+0x24/0x74 [ 2479.387068]I[0:launcher-loader: 1719] handle_irq_event+0x74/0xe0 [ 2479.387091]I[0:launcher-loader: 1719] handle_fasteoi_irq+0x174/0x240 [ 2479.387118]I[0:launcher-loader: 1719] handle_irq_desc+0x7c/0x2c0 [ 2479.387147]I[0:launcher-loader: 1719] generic_handle_domain_irq+0x1c/0x28 [ 2479.387174]I[0:launcher-loader: 1719] gic_handle_irq+0x64/0x158 [ 2479.387204]I[0:launcher-loader: 1719] call_on_irq_stack+0x2c/0x54 [ 2479.387231]I[0:launcher-loader: 1719] do_interrupt_handler+0x70/0xa0 [ 2479.387258]I[0:launcher-loader: 1719] el1_interrupt+0x34/0x68 [ 2479.387283]I[0:launcher-loader: 1719] el1h_64_irq_handler+0x18/0x24 [ 2479.387308]I[0:launcher-loader: 1719] el1h_64_irq+0x68/0x6c [ 2479.387332]I[0:launcher-loader: 1719] blk_attempt_bio_merge+0x8/0x170 [ 2479.387356]I[0:launcher-loader: 1719] blk_mq_attempt_bio_merge+0x78/0x98 [ 2479.387383]I[0:launcher-loader: 1719] blk_mq_submit_bio+0x324/0xa40 [ 2479.387409]I[0:launcher-loader: 1719] __submit_bio+0x104/0x138 [ 2479.387436]I[0:launcher-loader: 1719] submit_bio_noacct_nocheck+0x1d0/0x4a0 [ 2479.387462]I[0:launcher-loader: 1719] submit_bio_noacct+0x618/0x804 [ 2479.387487]I[0:launcher-loader: 1719] submit_bio+0x164/0x180 [ 2479.387511]I[0:launcher-loader: 1719] f2fs_submit_read_bio+0xe4/0x1c4 [ 2479.387537]I[0:launcher-loader: 1719] f2fs_mpage_readpages+0x888/0xa4c [ 2479.387563]I[0:launcher-loader: 1719] f2fs_readahead+0xd4/0x19c [ 2479.387587]I[0:launcher-loader: 1719] read_pages+0xb0/0x4ac [ 2479.387614]I[0:launcher-loader: 1719] page_cache_ra_unbounded+0x238/0x288 [ 2479.387642]I[0:launcher-loader: 1719] do_page_cache_ra+0x60/0x6c [ 2479.387669]I[0:launcher-loader: 1719] page_cache_ra_order+0x318/0x364 [ 2479.387695]I[0:launcher-loader: 1719] ondemand_readahead+0x30c/0x3d8 [ 2479.387722]I[0:launcher-loader: 1719] page_cache_sync_ra+0xb4/0xc8 [ 2479.387749]I[0:launcher-loader: 1719] filemap_read+0x268/0xd24 [ 2479.387777]I[0:launcher-loader: 1719] f2fs_file_read_iter+0x1a0/0x62c [ 2479.387806]I[0:launcher-loader: 1719] vfs_read+0x258/0x34c [ 2479.387831]I[0:launcher-loader: 1719] ksys_pread64+0x8c/0xd0 [ 2479.387857]I[0:launcher-loader: 1719] __arm64_sys_pread64+0x48/0x54 [ 2479.387881]I[0:launcher-loader: 1719] invoke_syscall+0x58/0x158 [ 2479.387909]I[0:launcher-loader: 1719] el0_svc_common+0xf0/0x134 [ 2479.387935]I[0:launcher-loader: 1719] do_el0_svc+0x44/0x114 [ 2479.387961]I[0:launcher-loader: 1719] el0_svc+0x2c/0x80 [ 2479.387985]I[0:launcher-loader: 1719] el0t_64_sync_handler+0x48/0x114 [ 2479.388010]I[0:launcher-loader: 1719] el0t_64_sync+0x190/0x194 [ 2479.388038]I[0:launcher-loader: 1719] Kernel panic - not syncing: kernel: panic_on_warn set ... So let's set __exception_irq_entry with __irq_entry as a default. Applying this patch, we can see gic_hande_irq is included in Systemp.map as below. * Before ffffffc008010000 T __do_softirq ffffffc008010000 T __irqentry_text_end ffffffc008010000 T __irqentry_text_start ffffffc008010000 T __softirqentry_text_start ffffffc008010000 T _stext ffffffc00801066c T __softirqentry_text_end ffffffc008010670 T __entry_text_start * After ffffffc008010000 T __irqentry_text_start ffffffc008010000 T _stext ffffffc008010000 t gic_handle_irq ffffffc00801013c t gic_handle_irq ffffffc008010294 T __irqentry_text_end ffffffc008010298 T __do_softirq ffffffc008010298 T __softirqentry_text_start ffffffc008010904 T __softirqentry_text_end ffffffc008010908 T __entry_text_start Signed-off-by: Youngmin Nam Signed-off-by: SEO HOYOUNG Reviewed-by: Mark Rutland Link: https://lore.kernel.org/r/20230424010436.779733-1-youngmin.nam@samsung.com Signed-off-by: Catalin Marinas Signed-off-by: Leon Chen Signed-off-by: Sasha Levin commit 988ddb77218d3975dd13dee7bb0e1fae098a9fdb Author: Ming Lei Date: Mon Apr 27 16:20:57 2026 +0800 blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none [ Upstream commit 245165658e1c9f95c0fecfe02b9b1ebd30a1198a ] After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock. Reported-by: Guangwu Zhang Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20230616132354.415109-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Leon Chen Signed-off-by: Sasha Levin commit a649161526736f48bcc592e3a412e5bcd7dd9e24 Author: Jianpeng Chang Date: Mon Apr 27 14:53:58 2026 +0800 net: enetc: fix the deadlock of enetc_mdio_lock [ Upstream commit 50bd33f6b3922a6b760aa30d409cae891cec8fb5 ] After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition. Fixes: 6d36ecdbc441 ("net: enetc: take the MDIO lock only once per NAPI poll cycle") Signed-off-by: Jianpeng Chang Acked-by: Wei Fang Link: https://patch.msgid.link/20251015021427.180757-1-jianpeng.chang.cn@windriver.com Signed-off-by: Jakub Kicinski [ adjusted context ] Signed-off-by: Charles Xu Signed-off-by: Sasha Levin commit c833d6c7199c5b5fca9ec95593acd539ec9c171c Author: Jesse.Zhang Date: Mon Apr 27 14:54:35 2026 +0800 drm/amdgpu: Limit BO list entry count to prevent resource exhaustion [ Upstream commit 6270b1a5dab94665d7adce3dc78bc9066ed28bdd ] Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit Reviewed-by: Christian König Suggested-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332) Cc: stable@vger.kernel.org Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin commit 340d4e268b0f406cfb76cebb491541a0c8853744 Author: Tvrtko Ursulin Date: Mon Apr 27 14:54:25 2026 +0800 drm/amdgpu: Use vmemdup_array_user in amdgpu_bo_create_list_entry_array [ Upstream commit c4ac100e9ae252b09986766ad23b1f83ca3a369d ] Replace kvmalloc_array() + copy_from_user() with vmemdup_array_user() on the fast path. This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin Signed-off-by: Alex Deucher Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin commit fcf3b325e1e56c8c1720aaae6183585b5a4a906c Author: Herbert Xu Date: Mon Apr 27 15:47:14 2026 +0800 padata: Remove comment for reorder_work [ Upstream commit 82a0302e7167d0b7c6cde56613db3748f8dd806d ] Remove comment for reorder_work which no longer exists. Reported-by: Stephen Rothwell Fixes: 71203f68c774 ("padata: Fix pd UAF once and for all") Signed-off-by: Herbert Xu Signed-off-by: Bin Lan Signed-off-by: Sasha Levin commit 609e59193fc6d9dd323f1c6ae1fdd721f1c79680 Author: Herbert Xu Date: Mon Apr 27 15:47:13 2026 +0800 padata: Fix pd UAF once and for all [ Upstream commit 71203f68c7749609d7fc8ae6ad054bdedeb24f91 ] There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") Signed-off-by: Herbert Xu [ Adjust context of padata_find_next(). Replace cpumask_next_wrap(cpu, pd->cpumask.pcpu) with cpumask_next_wrap(cpu, pd->cpumask.pcpu, -1, false) in padata_reorder() in v6.1 according to dc5bb9b769c9 ("cpumask: deprecate cpumask_next_wrap()") and f954a2d37637 ("padata: switch padata_find_next() to using cpumask_next_wrap()") . ] Signed-off-by: Bin Lan Signed-off-by: Sasha Levin commit 6113ac110e024d5781dff94c430ce63399173349 Author: Thomas Zimmermann Date: Tue Feb 17 16:56:12 2026 +0100 firmware: google: framebuffer: Do not mark framebuffer as busy commit f3850d399de3b6142b02315227ef9e772ed0c302 upstream. Remove the flag IORESOURCE_BUSY flag from coreboot's framebuffer resource. It prevents simpledrm from successfully requesting the range for its own use; resulting in errors such as [ 2.775430] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x80000000-0x80407fff flags 0x80000200] As with other uses of simple-framebuffer, the simple-framebuffer device should only declare it's I/O resources, but not actively use them. Signed-off-by: Thomas Zimmermann Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Cc: Samuel Holland Cc: Greg Kroah-Hartman Cc: Tzung-Bi Shih Cc: Brian Norris Cc: Julius Werner Cc: chrome-platform@lists.linux.dev Cc: # v4.18+ Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit ce57fa439bd1b5d664f334a0c3e3f0e42abb0153 Author: Tyllis Xu Date: Sat Mar 14 11:58:05 2026 -0500 ibmasm: fix heap over-read in ibmasm_send_i2o_message() commit 9aad71144fa3682cca3837a06c8623016790e7ec upstream. The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165805.548293-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman commit d50e2019c9d7c433f56d9dff65703eb904aa1fb1 Author: Tyllis Xu Date: Sat Mar 14 11:53:54 2026 -0500 ibmasm: fix OOB reads in command_file_write due to missing size checks commit 0eb09f737428e482a32a2e31e5e223f2b35a71d3 upstream. The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165355.548119-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman commit f7e5b4eefd7be3e09f8bd5fee63ed478fd7446ab Author: Tyllis Xu Date: Sun Mar 8 00:21:08 2026 -0600 misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() commit 4b6e6ead556734bdc14024c5f837132b1e7a4b84 upstream. ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient. Reported-by: Yuhao Jiang Fixes: 278d72ae8803 ("[PATCH] ibmasm driver: redesign handling of remote control events") Cc: stable@vger.kernel.org Cc: ychen@northwestern.edu Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260308062108.258940-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 45a45184b9c0b0b26ead06e370cda2073616a7cc Author: Greg Kroah-Hartman Date: Mon Apr 20 21:16:09 2026 +0200 drm/nouveau: fix u32 overflow in pushbuf reloc bounds check commit 2fc87d37be1b730a149b035f9375fdb8cc5333a5 upstream. nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. Cc: Lyude Paul Cc: Danilo Krummrich Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Reported-by: Anthropic Cc: stable Assisted-by: gkh_clanker_t1000 Fixes: a1606a9596e5 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16") Signed-off-by: Greg Kroah-Hartman [ Add Fixes: tag. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 37974fc6e4160f99a2cac8bcfa06e99f1a2de74e Author: Takashi Iwai Date: Fri Apr 10 16:32:19 2026 +0200 ALSA: usb-audio: Evaluate packsize caps at the right place commit 52521e8398839105ef8eb22b3f0993f9b0d11a57 upstream. We introduced the upper bound checks of the packet sizes by the ep->maxframesize for avoiding the URB submission errors. However, the check was applied at an incorrect place in the function snd_usb_endpoint_set_params() where ep->maxframesize isn't defined yet; the value is defined at a bit later position. So this ended up with a failure at the first run while the second run works. For fixing it, move the check at the correct place, right after the calculation of ep->maxframesize in the same function. Fixes: 7fe8dec3f628 ("ALSA: usb-audio: Cap the packet size pre-calculations") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221292 Cc: Link: https://patch.msgid.link/20260410143220.1676344-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fb934e713d89c508f89696a9b0dd8df5ac6d2f21 Author: Michal Pecio Date: Thu Apr 2 16:13:42 2026 +0300 usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable() commit 25e531b422dc2ac90cdae3b6e74b5cdeb081440d upstream. xHCI hardware maintains its endpoint state between add_endpoint() and drop_endpoint() calls followed by successful check_bandwidth(). So does the driver. Core may call endpoint_disable() during xHCI endpoint life, so don't clear host_ep->hcpriv then, because this breaks endpoint_reset(). If a driver calls usb_set_interface(), submits URBs which make host sequence state non-zero and calls usb_clear_halt(), the device clears its sequence state but xhci_endpoint_reset() bails out. The next URB malfunctions: USB2 loses one packet, USB3 gets Transaction Error or may not complete at all on some (buggy?) HCs from ASMedia and AMD. This is triggered by uvcvideo on bulk video devices. The code was copied from ehci_endpoint_disable() but it isn't needed here - hcpriv should only be NULL on emulated root hub endpoints. It might prevent resetting and inadvertently enabling a disabled and dropped endpoint, but core shouldn't try to reset dropped endpoints. Document xhci requirements regarding hcpriv. They are currently met. Fixes: 18b74067ac78 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260402131342.2628648-26-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5deb4b558e8fb0c543c29e0aeec0f5d2262021d3 Author: Cássio Gabriel Date: Tue Apr 21 22:07:41 2026 -0300 ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch commit a9224f26b754b5034719248891ff3c2ea0d11144 upstream. snd_microii_spdif_switch_put() returns 0 when the requested vendor register value differs from the cached one. This comparison was inverted by the resume-support conversion, so real SPDIF switch toggles are ignored while no-op writes still issue SET_CUR and report success. Return early only when the requested value matches the cached one. Fixes: 288673beae6c ("ALSA: usb-audio: Add resume support for MicroII SPDIF ctls") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260421-microii-spdif-switch-fix-v1-1-5c50dc28b88f@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a1ffe486bfb9732b978398a7be654abf5eea14f8 Author: Cássio Gabriel Date: Tue Apr 21 21:53:52 2026 -0300 ALSA: usb-audio: Avoid false E-MU sample-rate notifications commit fca9c850042a7ab4828ce3a9caa8bc40ea09856a upstream. snd_emuusb_set_samplerate() unconditionally notifies the E-MU SampleRate Extension Unit control after issuing SET_CUR. If snd_usb_mixer_set_ctl_value() fails, the control value has not changed, yet snd_usb_mixer_notify_id() still invalidates the cache and emits a value-change event to userspace. Notify the control only after a successful write. Fixes: 7d2b451e65d2 ("ALSA: usb-audio - Added functionality for E-mu 0404USB/0202USB/TrackerPre") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260421-alsa-emuusb-samplerate-notify-v1-1-8b63bbc1d7f1@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f14bd323eec4b4f0ef662520ec852e593ece1d4c Author: Cássio Gabriel Date: Wed Apr 15 12:04:53 2026 -0300 ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES commit 3c318f97dcc50b2e0556a1813bd6958678e881fd upstream. parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far. Fixes: 4fa0e81b8350 ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()") Cc: stable@vger.kernel.org Reported-by: syzbot+d56178c27a4710960820@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d56178c27a4710960820 Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260415-usb-audio-uac2-rate-cap-v1-1-5ecbafc120d8@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9a397aa9b5e53ca63d4d6aefb542832eca389618 Author: Anderson Nascimento Date: Wed Apr 22 17:14:35 2026 +0100 rxrpc: Fix missing validation of ticket length in non-XDR key preparsing commit ac33733b10b484d666f97688561670afd5861383 upstream. In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic. Fixes: 8a7a3eb4ddbe ("KEYS: RxRPC: Use key preparsing") Fixes: 84924aac08a4 ("rxrpc: Fix checker warning") Reported-by: Anderson Nascimento Signed-off-by: Anderson Nascimento Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-7-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0f1f2f9894893dc8a28af1b9e9dbc0abf453eb52 Author: Sean Christopherson Date: Fri Mar 13 10:57:31 2026 -0700 crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed commit 4f685dbfa87c546e51d9dc6cab379d20f275e114 upstream. When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 25d9b3446001185484209cf57951f3368462b631 Author: Sean Christopherson Date: Fri Mar 13 10:48:53 2026 -0700 crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed commit e76239fed3cffd6d304d8ca3ce23984fd24f57d3 upstream. When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 372116eece159adff631b1508344c8b85ebf9559 Author: Sean Christopherson Date: Fri Mar 13 10:43:16 2026 -0700 crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed commit abe4a6d6f606113251868c2c4a06ba904bb41eed upstream. When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ac7345f68cda6989016d85d63f7b244c064aa8f6 Author: Berk Cem Goksel Date: Mon Apr 13 06:49:41 2026 +0300 ALSA: caiaq: take a reference on the USB device in create_card() commit 80bb50e2d459213cccff3111d5ef98ed4238c0d5 upstream. The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call. Fixes: b04dcbb7f7b1 ("ALSA: caiaq: Use snd_card_free_when_closed() at disconnection") Cc: stable@vger.kernel.org Cc: Andrey Konovalov Signed-off-by: Berk Cem Goksel Link: https://patch.msgid.link/20260413034941.1131465-3-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d95e3159dc18298dc7a836e681eb69204c542df0 Author: Cryolitia PukNgae Date: Thu Apr 2 13:36:57 2026 +0800 ALSA: usb-audio: apply quirk for MOONDROP JU Jiu commit 4513d3e0bbc0585b86ccf2631902593ff97e88f5 upstream. It(ID 31b2:0111 JU Jiu) reports a MIN value -12800 for volume control, but will mute when setting it less than -10880. Thanks to my girlfriend Kagura for reporting this issue. Cc: Kagura Cc: stable@vger.kernel.org Signed-off-by: Cryolitia PukNgae Link: https://patch.msgid.link/20260402-syy-v1-1-068d3bc30ddc@linux.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 57bc678f36ac03281e877c6b84877b43f964143f Author: George Saad Date: Mon Mar 23 11:21:23 2026 +0000 f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io() commit 39d4ee19c1e7d753dd655aebee632271b171f43a upstream. In f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bring the F2FS_WB_CP_DATA counter to zero, unblocking f2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmount CPU. The unmount path then proceeds to call f2fs_destroy_page_array_cache(sbi), which destroys sbi->page_array_slab via kmem_cache_destroy(), and eventually kfree(sbi). Meanwhile, the bio completion callback is still executing: when it reaches page_array_free(sbi, ...), it dereferences sbi->page_array_slab — a destroyed slab cache — to call kmem_cache_free(), causing a use-after-free. This is the same class of bug as CVE-2026-23234 (which fixed the equivalent race in f2fs_write_end_io() in data.c), but in the compressed writeback completion path that was not covered by that fix. Fix this by moving dec_page_count() to after page_array_free(), so that all sbi accesses complete before the counter decrement that can unblock unmount. For non-last folios (where atomic_dec_return on cic->pending_pages is nonzero), dec_page_count is called immediately before returning — page_array_free is not reached on this path, so there is no post-decrement sbi access. For the last folio, page_array_free runs while the F2FS_WB_CP_DATA counter is still nonzero (this folio has not yet decremented it), keeping sbi alive, and dec_page_count runs as the final operation. Fixes: 4c8ff7095bef ("f2fs: support data compression") Cc: stable@vger.kernel.org Signed-off-by: George Saad Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 41e53a773db6342ac9a689ee5ba635c31744c9f0 Author: Tristan Madani Date: Fri Apr 17 19:54:57 2026 +0000 ksmbd: use check_add_overflow() to prevent u16 DACL size overflow commit 299f962c0b02d048fb45d248b4da493d03f3175d upstream. set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char *)pndace + *size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value. Use check_add_overflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing check_mul_overflow() usage elsewhere in smbacl.c. Cc: stable@vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Tristan Madani Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ddbbc8b2a09dd2cfed90871313e3691ae1db08a2 Author: Tristan Madani Date: Fri Apr 17 19:33:17 2026 +0000 ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment commit 30010c952077a1c89ecdd71fc4d574c75a8f5617 upstream. smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in get_file_all_info() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compound requests"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers. Cc: stable@vger.kernel.org Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Tristan Madani Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1dd757379997b71a328a4b591ffaf481acd0ead1 Author: Michael Bommarito Date: Sun Apr 19 19:35:19 2026 -0400 smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path commit a58c5af19ff0d6f44f6e9fe31e33a2c92223f77e upstream. smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds. Fixes: f5778c398713 ("SMB3: Allow SMB3 FSCTL queries to be sent to server from tools") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8bd4cad3f458d11650d51c2d24b03fb1770ae6cc Author: Michael Bommarito Date: Mon Apr 20 09:50:58 2026 -0400 smb: client: require a full NFS mode SID before reading mode bits commit 2757ad3e4b6f9e0fed4c7739594e702abc5cab21 upstream. parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl. Fixes: e2f8fbfb8d09 ("cifs: get mode bits from special sid on stat") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f2af9059a64a2d1c7dac6cd307f99bf7730e5a08 Author: DaeMyung Kang Date: Fri Apr 17 06:17:35 2026 +0900 smb: server: fix max_connections off-by-one in tcp accept path commit ce23158bfe584bd90d1918f279fdf9de57802012 upstream. The global max_connections check in ksmbd's TCP accept path counts the newly accepted connection with atomic_inc_return(), but then rejects the connection when the result is greater than or equal to server_conf.max_connections. That makes the effective limit one smaller than configured. For example: - max_connections=1 rejects the first connection - max_connections=2 allows only one connection The per-IP limit in the same function uses <= correctly because it counts only pre-existing connections. The global limit instead checks the post-increment total, so it should reject only when that total exceeds the configured maximum. Fix this by changing the comparison from >= to >, so exactly max_connections simultaneous connections are allowed and the next one is rejected. This matches the documented meaning of max_connections in fs/smb/server/ksmbd_netlink.h as the "Number of maximum simultaneous connections". Fixes: 0d0d4680db22 ("ksmbd: add max connections parameter") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 60734c8bc3b4aa0672e251f08dda81977e4b5387 Author: Michael Bommarito Date: Tue Apr 14 18:54:38 2026 -0400 smb: server: fix active_num_conn leak on transport allocation failure commit 6551300dc452ac16a855a83dbd1e74899542d3b3 upstream. Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with "Limit the maximum number of connections". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept. Fixes: 0d0d4680db22 ("ksmbd: add max connections parameter") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b8bc92d5830ff3dd63ceba0f2c209b42a7f2a364 Author: Darrick J. Wong Date: Mon Feb 23 15:06:50 2026 -0800 fuse: quiet down complaints in fuse_conn_limit_write commit 129a45f9755a89f573c6a513a6b9e3d234ce89b0 upstream. gcc 15 complains about an uninitialized variable val that is passed by reference into fuse_conn_limit_write: control.c: In function ‘fuse_conn_congestion_threshold_write’: include/asm-generic/rwonce.h:55:37: warning: ‘val’ may be used uninitialized [-Wmaybe-uninitialized] 55 | *(volatile typeof(x) *)&(x) = (val); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ include/asm-generic/rwonce.h:61:9: note: in expansion of macro ‘__WRITE_ONCE’ 61 | __WRITE_ONCE(x, val); \ | ^~~~~~~~~~~~ control.c:178:9: note: in expansion of macro ‘WRITE_ONCE’ 178 | WRITE_ONCE(fc->congestion_threshold, val); | ^~~~~~~~~~ control.c:166:18: note: ‘val’ was declared here 166 | unsigned val; | ^~~ Unfortunately there's enough macro spew involved in kstrtoul_from_user that I think gcc gives up on its analysis and sprays the above warning. AFAICT it's not actually a bug, but we could just zero-initialize the variable to enable using -Wmaybe-uninitialized to find real problems. Previously we would use some weird uninitialized_var annotation to quiet down the warnings, so clearly this code has been like this for quite some time. Cc: stable@vger.kernel.org # v5.9 Fixes: 3f649ab728cda8 ("treewide: Remove uninitialized_var() usage") Signed-off-by: Darrick J. Wong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 038e61812fa52ef62bad2cfc96bf37dc0db47c1e Author: Samuel Page Date: Mon Apr 20 11:01:37 2026 +0200 fuse: reject oversized dirents in page cache commit 51a8de6c50bf947c8f534cd73da4c8f0a13e7bed upstream. fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable@vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page Reported-by: Qi Tang Reported-by: Zijun Hu Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 1393a467a9607e62123806de7d4c3a3e54e396a9 Author: Greg Kroah-Hartman Date: Thu Apr 9 16:37:15 2026 +0200 fs/ntfs3: validate rec->used in journal-replay file record check commit 0ca0485e4b2e837ebb6cbd4f2451aba665a03e4b upstream. check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement. Cc: Konstantin Komarov Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 0afdfd4941c1b60a1f5c361760daa970edca60cd Author: Wang Jie Date: Tue Apr 14 07:45:29 2026 -0400 rxrpc: only handle RESPONSE during service challenge [ Upstream commit c43ffdcfdbb5567b1f143556df8a04b4eeea041c ] Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Jie Wang Signed-off-by: Yang Yang Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-21-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ adapted to spin_lock_bh usage, 3-arg verify_response(), and direct rxrpc_call_is_secure() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7bf5e0c485600caa3577a91d5f5e18076e3c427b Author: David Howells Date: Mon Apr 13 20:29:44 2026 -0400 rxrpc: Fix anonymous key handling [ Upstream commit 6a59d84b4fc2f27f7b40e348506cc686712e260b ] In rxrpc_new_client_call_for_sendmsg(), a key with no payload is meant to be substituted for a NULL key pointer, but the variable this is done with is subsequently not used. Fix this by using "key" rather than "rx->key" when filling in the connection parameters. Note that this only affects direct use of AF_RXRPC; the kAFS filesystem doesn't use sendmsg() directly and so bypasses the issue. Further, AF_RXRPC passes a NULL key in if no key is set, so using an anonymous key in that manner works. Since this hasn't been noticed to this point, it might be better just to remove the "key" variable and the code that sets it - and, arguably, rxrpc_init_client_call_security() would be a better place to handle it. Fixes: 19ffa01c9c45 ("rxrpc: Use structs to hold connection params and protocol info") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c7a9e967cc9615a1dabc5e0e6fdbe88a172d5a5b Author: Mark Rutland Date: Thu Jun 15 11:26:28 2023 +0100 arm64: mm: fix VA-range sanity check commit ab9b4008092c86dc12497af155a0901cc1156999 upstream. Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident. The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } ... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings. When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation") ... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; } At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1. Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space") ... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map. Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END") ... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } Correct the condition to check against the start of the TTBR1 address space, which is currently PAGE_OFFSET. This simplifies the logic, and more clearly matches the "outside kernel range" message in the warning. Signed-off-by: Mark Rutland Cc: Russell King Cc: Steve Capper Cc: Will Deacon Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Alva Lan Signed-off-by: Greg Kroah-Hartman commit cdde0b55a4154598a2ba8de9889937ee0ff1c796 Author: Nathan Chancellor Date: Mon Apr 20 17:36:46 2026 -0700 scripts/dtc: Remove unused dts_version in dtc-lexer.l This patch is for stable only. Commit 5a09df20872c ("scripts/dtc: Update to upstream version v1.7.2-69-g53373d135579") upstream applied it as part of a regular scripts/dtc sync, which may be unsuitable for older versions of stable where the warning it fixes is present. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in dtc-lexer.lex.c (compiled from dtc-lexer.l): scripts/dtc/dtc-lexer.lex.c:641:12: warning: variable 'dts_version' set but not used [-Wunused-but-set-global] 641 | static int dts_version = 1; | ^ Remove it to clear up the warning, as it is truly unused. Fixes: 658f29a51e98 ("of/flattree: Update dtc to current mainline.") Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit aab7b39fcac5f6165f6434bcbb56bb7865d4ad2b Author: Johannes Berg Date: Tue Mar 19 10:10:22 2024 +0200 wifi: iwlwifi: read txq->read_ptr under lock commit c2ace6300600c634553657785dfe5ea0ed688ac2 upstream. If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240319100755.bf4c62196504.I978a7ca56c6bd6f1bf42c15aa923ba03366a840b@changeid Signed-off-by: Johannes Berg [ Change read_ptr definition according to commit 413be839bfca9("wifi: iwlwifi: add a validity check of queue_id in iwl_txq_reclaim"). ] Signed-off-by: Robert Garcia Signed-off-by: Greg Kroah-Hartman commit bd9197b72d772be7bccc3b66c83a3157cfe2f96f Author: Ye Bin Date: Sat Oct 12 00:44:50 2024 +0800 f2fs: fix null-ptr-deref in f2fs_submit_page_bio() commit b7d0a97b28083084ebdd8e5c6bccd12e6ec18faa upstream. There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register "f2fs_fs_type". To address above issue just register "f2fs_fs_type" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized. Fixes: f543805fcd60 ("f2fs: introduce private bioset") Signed-off-by: Ye Bin Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [ Minor context conflict resolved. ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 365ee29e559269cbb2108c4cc05dd8e262b4e84e Author: Takashi Iwai Date: Mon Dec 9 10:56:12 2024 +0100 ALSA: control: Avoid WARN() for symlink errors commit b2e538a9827dd04ab5273bf4be8eb2edb84357b0 upstream. Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too. Fixes: a135dfb5de15 ("ALSA: led control - add sysfs kcontrol LED marking layer") Reported-by: syzbot+4e7919b09c67ffd198ae@syzkaller.appspotmail.com Closes: https://lore.kernel.org/675664c7.050a0220.a30f1.018c.GAE@google.com Link: https://patch.msgid.link/20241209095614.4273-1-tiwai@suse.de Signed-off-by: Takashi Iwai [ Use card->ctl_dev.kobj to keep struct consistent. ] Signed-off-by: Robert Garcia Signed-off-by: Greg Kroah-Hartman commit d06eb2620d3bf16056b8b7ea3744dbb5e30512f4 Author: André Draszik Date: Thu Apr 23 15:28:21 2026 +0800 scsi: ufs: core: Fix use-after free in init error and remove paths [ Upstream commit f8fb2403ddebb5eea0033d90d9daae4c88749ada ] devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup Fixes: cb77cb5abe1f ("blk-crypto: rename blk_keyslot_manager to blk_crypto_profile") Fixes: d76d9d7d1009 ("scsi: ufs: use devm_blk_ksm_init()") Cc: stable@vger.kernel.org Signed-off-by: André Draszik Link: https://lore.kernel.org/r/20250124-ufshcd-fix-v4-1-c5d0144aae59@linaro.org Reviewed-by: Bean Huo Reviewed-by: Manivannan Sadhasivam Acked-by: Eric Biggers Signed-off-by: Martin K. Petersen [ Delete modifications about ufshcd_parse_operating_points() for it's added from commit 72208ebe181e3("scsi: ufs: core: Add support for parsing OPP") and that in ufshcd_pltfrm_remove() for it's added from commit 897df60c16d54("scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()"). ] Signed-off-by: Robert Garcia Signed-off-by: Greg Kroah-Hartman commit c6cebcb4e0b3140ec2ace45c020a9049527385d1 Author: David Howells Date: Wed Apr 22 22:24:31 2026 +0000 rxrpc: Fix recvmsg() unconditional requeue [ Upstream commit 2c28769a51deb6022d7fbd499987e237a01dd63a ] If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also. Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg") Reported-by: Faith Reported-by: Pumpkin Chang Signed-off-by: David Howells Acked-by: Marc Dionne Signed-off-by: Jakub Kicinski Cc: stable@vger.kernel.org [Adapted to 6.1: use write_lock_bh/write_unlock_bh, trace_rxrpc_call directly for see-call tracing, and 6.1 trace enum naming convention.] Signed-off-by: Jay Wang Signed-off-by: Greg Kroah-Hartman commit 110769a9aa51135ac7ce479a47dfb41924f37664 Author: Srinivas Kandagatla Date: Mon Apr 20 13:17:43 2026 -0400 ASoC: qcom: q6apm: move component registration to unmanaged version [ Upstream commit 6ec1235fc941dac6c011b30ee01d9220ff87e0cd ] q6apm component registers dais dynamically from ASoC toplology, which are allocated using device managed version apis. Allocating both component and dynamic dais using managed version could lead to incorrect free ordering, dai will be freed while component still holding references to it. Fix this issue by moving component to unmanged version so that the dai pointers are only freeded after the component is removed. ================================================================== BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426 Tainted: [W]=WARN Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024 Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] Call trace: show_stack+0x28/0x7c (C) dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Allocated by task 77: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194 __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Freed by task 3426: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 01d2fae48de6d1200ac9c4318ea497f2f6fab661 Author: Dawei Li Date: Mon Apr 20 13:17:42 2026 -0400 soc: qcom: apr: make remove callback of apr driver void returned [ Upstream commit 33ae3d0955943ac5bacfcb6911cf7cb74822bf8c ] Since commit fc7a6209d571 ("bus: Make remove callback return void") forces bus_type::remove be void-returned, it doesn't make much sense for any bus based driver implementing remove callbalk to return non-void to its caller. As such, change the remove function for apr bus based drivers to return void. Signed-off-by: Dawei Li Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/TYCP286MB23232B7968D34DB8323B0F16CAFB9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM Stable-dep-of: 6ec1235fc941 ("ASoC: qcom: q6apm: move component registration to unmanaged version") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b2eb405bbced3a6e772545e1b74dbde37cee1f8f Author: Koichiro Den Date: Mon Apr 20 13:29:14 2026 -0400 PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup [ Upstream commit d799984233a50abd2667a7d17a9a710a3f10ebe2 ] Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-4-den@valinux.co.jp [ replaced disable_delayed_work_sync() with cancel_delayed_work_sync() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c45268cdc71810b712acdea0d9dc0d644e23a952 Author: Tamir Duberstein Date: Mon Apr 20 12:38:51 2026 -0400 scripts: generate_rust_analyzer.py: define scripts [ Upstream commit 36c619f6bd793493294becb10a02fea370b67a91 ] Add IDE support for host-side scripts written in Rust. This support has been missing since these scripts were initially added in commit 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it. Change the existing instance of extension stripping to `pathlib.Path.stem` to maintain code consistency. Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`") Cc: stable@vger.kernel.org Reviewed-by: Daniel Almeida Reviewed-by: Fiona Behrens Reviewed-by: Trevor Gross Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org Signed-off-by: Tamir Duberstein [ changed `[std]` dep to `["std"]` and kept untyped `is_root_crate()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27bb79b7717b2fbb111a1c13548b2786ee712dca Author: Ming Lei Date: Mon Apr 20 20:01:10 2026 +0800 ublk: fix deadlock when reading partition table [ Upstream commit c258f5c4502c9667bccf5d76fa731ab9c96687c1 ] When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur: 1. bdev_open() grabs disk->open_mutex 2. The process issues read I/O to ublk backend to read partition table 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdev_release() from the same context 6. blkdev_release() tries to grab disk->open_mutex again 7. Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Link: https://github.com/ublk-org/ublksrv/issues/170 [1] Signed-off-by: Ming Lei Reviewed-by: Caleb Sander Mateos [axboe: rewrite comment in ublk] Signed-off-by: Jens Axboe [ The fix omits the change in __ublk_do_auto_buf_reg() since this function doesn't exist in 6.1. ] Signed-off-by: Ruohan Lan Signed-off-by: Greg Kroah-Hartman commit 188acf8bf46f764375c3c4ce8a6922ce86542350 Author: David Woodhouse Date: Mon Apr 13 11:20:05 2026 -0400 KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs [ Upstream commit 2619da73bb2f10d88f7e1087125c40144fdf0987 ] Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members") broke the userspace API for C++. These structures ending in VLAs are typically a *header*, which can be followed by an arbitrary number of entries. Userspace typically creates a larger structure with some non-zero number of entries, for example in QEMU's kvm_arch_get_supported_msr_feature(): struct { struct kvm_msrs info; struct kvm_msr_entry entries[1]; } msr_data = {}; While that works in C, it fails in C++ with an error like: flexible array member 'kvm_msrs::entries' not at end of 'struct msr_data' Fix this by using __DECLARE_FLEX_ARRAY() for the VLA, which uses [0] for C++ compilation. Fixes: 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Link: https://patch.msgid.link/3abaf6aefd6e5efeff3b860ac38421d9dec908db.camel@infradead.org [sean: tag for stable@] Signed-off-by: Sean Christopherson [ applied `__DECLARE_FLEX_ARRAY(char, name)` change directly instead of inside missing `#ifdef __KERNEL__` else branch ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3a808cd0790b5075aaa2bc3588edf02cd71d352 Author: Yuqi Xu Date: Tue Apr 14 07:52:36 2026 -0400 rxrpc: reject undecryptable rxkad response tickets [ Upstream commit fe4447cd95623b1cfacc15f280aab73a6d7340b2 ] rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-12-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ adapted `rxrpc_abort_conn()` call to existing `goto other_error` error-handling pattern ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1adb500f85780ee7d122b9a21040606b6055eab8 Author: Guocai He Date: Tue Apr 14 10:16:33 2026 +0800 Revert "wifi: cfg80211: stop NAN and P2P in cfg80211_leave" This reverts commit 0c4f1c02d27a880b10b58c63f574f13bed4f711d which is commit e1696c8bd0056bc1a5f7766f58ac333adc203e8a upstream. The reverted patch introduced a deadlock. The locking situation in mainline is totally different, so it is incorrect to directly backport the commit from mainline. Signed-off-by: Guocai He Signed-off-by: Greg Kroah-Hartman commit 280efb85e9759881a9d31d0874baa04583cb6c09 Author: David Howells Date: Mon Apr 13 21:28:47 2026 -0400 rxrpc: Fix call removal to use RCU safe deletion [ Upstream commit 146d4ab94cf129ee06cd467cb5c71368a6b5bad6 ] Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs. Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Linus Torvalds cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ adapted to older API ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1326b12284aac7d3ca93a6c71725acf00c6f8fc2 Author: David Howells Date: Mon Apr 13 20:02:39 2026 -0400 rxrpc: Fix key quota calculation for multitoken keys [ Upstream commit bdbfead6d38979475df0c2f4bad2b19394fe9bdc ] In the rxrpc key preparsing, every token extracted sets the proposed quota value, but for multitoken keys, this will overwrite the previous proposed quota, losing it. Fix this by adding to the proposed quota instead. Fixes: 8a7a3eb4ddbe ("KEYS: RxRPC: Use key preparsing") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ dropped hunk for rxrpc_preparse_xdr_yfs_rxgk() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 22df7d4de9c5cd42edf855a1de25f2106088c4c6 Author: Joseph Qi Date: Mon Apr 13 11:43:45 2026 -0400 ocfs2: fix out-of-bounds write in ocfs2_write_end_inline [ Upstream commit 7bc5da4842bed3252d26e742213741a4d0ac1b14 ] KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it. Link: https://lkml.kernel.org/r/20260403063830.3662739-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Reported-by: syzbot+62c1793956716ea8b28a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=62c1793956716ea8b28a Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 131c0b573e1b467b7d553e9ff38003f1acd8f5f2 Author: Deepanshu Kartikey Date: Mon Apr 13 11:43:44 2026 -0400 ocfs2: validate inline data i_size during inode read [ Upstream commit 1524af3685b35feac76662cc551cbc37bd14775f ] When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data. Link: https://lkml.kernel.org/r/20251212052132.16750-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4 Tested-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251211115231.3560028-1-kartikey406@gmail.com/T/ [v1] Link: https://lore.kernel.org/all/20251212040400.6377-1-kartikey406@gmail.com/T/ [v2] Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Stable-dep-of: 7bc5da4842be ("ocfs2: fix out-of-bounds write in ocfs2_write_end_inline") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a0a499a91e9207903b2b2d3543019e65f2bf6920 Author: Dmitry Antipov Date: Mon Apr 13 11:43:43 2026 -0400 ocfs2: add inline inode consistency check to ocfs2_validate_inode_block() [ Upstream commit a2b1c419ff72ec62ff5831684e30cd1d4f0b09ee ] In 'ocfs2_validate_inode_block()', add an extra check whether an inode with inline data (i.e. self-contained) has no clusters, thus preventing an invalid inode from being passed to 'ocfs2_evict_inode()' and below. Link: https://lkml.kernel.org/r/20251023141650.417129-1-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov Reported-by: syzbot+c16daba279a1161acfb0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c16daba279a1161acfb0 Reviewed-by: Joseph Qi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Stable-dep-of: 7bc5da4842be ("ocfs2: fix out-of-bounds write in ocfs2_write_end_inline") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7d6411bdfdeae32c2124ee0cbcdb851293e92f96 Author: Sebastian Krzyszkowiak Date: Mon Apr 13 10:07:42 2026 -0400 arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V [ Upstream commit 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637 ] The minimal voltage of VDD_SOC sourced from BUCK1 is 0.81V, which is the currently set value. However, BD71837 only guarantees accuracy of ±0.01V, and this still doesn't factor other reasons for actual voltage to slightly drop in, resulting in the possibility of running out of the operational range. Bump the voltage up to 0.85V, which should give enough headroom. Cc: stable@vger.kernel.org Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone") Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Frank Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4972bb792c43ceeeeee5c1609413f56964fd5c4e Author: Sebastian Krzyszkowiak Date: Mon Apr 13 10:07:41 2026 -0400 Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower" [ Upstream commit 4cd46ea0eb4504f7f4fea92cb4601c5c9a3e545e ] This reverts commit c24a9b698fb02cd0723fa8375abab07f94b97b10. It's been found that there's a significant per-unit variance in accepted supply voltages and the current set still makes some units unstable. Revert back to nominal values. Cc: stable@vger.kernel.org Fixes: c24a9b698fb0 ("arm64: dts: imx8mq-librem5: Set the DVS voltages lower") Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Frank Li Stable-dep-of: 511f76bf1dce ("arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 18b62f407b16596b9ffc5fab74a3b98ae743cb1a Author: Sebastian Krzyszkowiak Date: Mon Apr 13 10:07:40 2026 -0400 arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage to 0.81V [ Upstream commit 94b91e3ca6688fafd6a5dd70bd89fe9d3aee88da ] 0.8V is outside of the operating voltage specified for imx8mq, see chapter 3.1.4 "Operating ranges" of the IMX8MDQLQCEC document. Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Stable-dep-of: 511f76bf1dce ("arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1b61813d1ff06b6dc7d2fb2d42826035a881488 Author: Sebastian Krzyszkowiak Date: Mon Apr 13 10:07:39 2026 -0400 arm64: dts: imx8mq-librem5: Set the DVS voltages lower [ Upstream commit c24a9b698fb02cd0723fa8375abab07f94b97b10 ] They're still in the operating range according to i.MX 8M Quad datasheet. There's some headroom added over minimal values to account for voltage drop. Operational ranges (min - typ - max [selected]): - VDD_SOC (BUCK1): 0.81 - 0.9 - 0.99 [0.88] - VDD_ARM (BUCK2): 0.81 - 0.9 - 1.05 [0.84] (1000MHz) 0.90 - 1.0 - 1.05 [0.93] (1500MHz) - VDD_GPU (BUCK3): 0.81 - 0.9 - 1.05 [0.85] (800MHz) 0.90 - 1.0 - 1.05 [ -- ] (1000MHz) - VDD_VPU (BUCK4): 0.81 - 0.9 - 1.05 [ -- ] (550/500/588MHz) 0.90 - 1.0 - 1.05 [0.93] (660/600/800MHz) Idle power consumption doesn't appear to be influenced much, but a simple load test (`cat /dev/urandom | pigz - > /dev/null` combined with running Animatch) seems to show about 0.3W of difference. Care is advised, as there may be differences between each units in how low can they be undervolted - in my experience, reaching that point usually makes the phone fail to boot. In my case, it appears that my Birch phone can go down the most. This is a somewhat conservative set of values that I've seen working well on all my devices; I haven't tried very hard to optimize it, so more experiments are welcome. Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Stable-dep-of: 511f76bf1dce ("arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e531e71b9d21d5e985251440e0d722f71299b7a Author: Vladimir Oltean Date: Tue Apr 21 15:36:35 2026 +0800 net: dsa: clean up FDB, MDB, VLAN entries on unbind [ Upstream commit 7afb5fb42d4950f33af2732b8147c552659f79b7 ] As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implementing shim .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ What happens in the bug report above is that dsa_port_do_vlan_del() fails, then the VLAN entry lingers on, and then we warn on unbind and leak it. This is not a straight revert of the blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), and some extra comments gathered from past years' experience, to justify the logic. Fixes: 0832cd9f1f02 ("net: dsa: warn if port lists aren't empty in dsa_port_teardown") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250414212930.2956310-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski [ Apply the patch to net/dsa/dsa2.c in v6.1 since commit 47d2ce03dcfb ("net: dsa: rename dsa2.c back into dsa.c and create its header") renamed this file to net/dsa/dsa.c starting from v6.2. ] Signed-off-by: Alva Lan Signed-off-by: Sasha Levin commit 9a779d1f480e83720b5384adf165604e7ee226bd Author: Felix Fietkau Date: Tue Apr 21 10:43:52 2026 +0800 wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure [ Upstream commit d5ad6ab61cbd89afdb60881f6274f74328af3ee9 ] ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc. Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260314065455.2462900-1-nbd@nbd.name Fixes: 06be6b149f7e ("mac80211: add ieee80211_tx_prepare_skb() helper function") Signed-off-by: Johannes Berg [ Exclude changes to drivers/net/wireless/mediatek/mt76/scan.c as this file is first introduced by commit 31083e38548f("wifi: mt76: add code for emulating hardware scanning") after linux-6.14.] Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Sasha Levin commit 112bb60cd0e254a369e95aa9941a694ffeca089f Author: Andrew Price Date: Wed Apr 22 18:37:17 2026 +0800 gfs2: Validate i_depth for exhash directories [ Upstream commit 557c024ca7250bb65ae60f16c02074106c2f197b ] A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'. Reported-by: syzbot+4708579bb230a0582a57@syzkaller.appspotmail.com Signed-off-by: Andrew Price Signed-off-by: Andreas Gruenbacher Signed-off-by: Ruohan Lan Signed-off-by: Sasha Levin commit 18ce39b4f4160aaa7edbe591bc4abbb3d3708e97 Author: Andrew Price Date: Wed Apr 22 18:37:16 2026 +0800 gfs2: Improve gfs2_consist_inode() usage [ Upstream commit 10398ef57aa189153406c110f5957145030f08fe ] gfs2_consist_inode() logs an error message with the source file and line number. When we jump before calling it, the line number becomes less useful as it no longer relates to the source of the error. To aid troubleshooting, replace the gotos with the gfs2_consist_inode() calls so that the error messages are more informative. Signed-off-by: Andrew Price Signed-off-by: Andreas Gruenbacher Signed-off-by: Ruohan Lan Signed-off-by: Sasha Levin commit d1bd8b9edc6752d10f84d28ff64f842401ce336d Author: Minhong He Date: Mon Apr 20 13:43:09 2026 +0800 ipv6: add NULL checks for idev in SRv6 paths [ Upstream commit 06413793526251870e20402c39930804f14d59c0 ] __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences. Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)") Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Signed-off-by: Minhong He Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Sasha Levin commit b2969caffe45b5e2c321e6f2d7c2f8f412af6bea Author: Sasha Levin Date: Wed Apr 22 13:19:24 2026 -0400 Revert "net: ixp4xx_eth: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()" This reverts commit a94d5447f6bf827bc29be2520ca636685bbc29e6. Signed-off-by: Sasha Levin commit 9d2f0610c1c0994c19bc6af3ece4eafe1f578b44 Author: Sasha Levin Date: Wed Apr 22 13:19:24 2026 -0400 Revert "net: ethernet: xscale: Check for PTP support properly" This reverts commit 5195b10c34b8993194ad12ad7d8f54d861be084b. Signed-off-by: Sasha Levin commit b261027a1a235d8925e332363f23135a0eff2b35 Author: Koichiro Den Date: Mon Apr 20 10:58:35 2026 -0400 PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown [ Upstream commit 0da63230d3ec1ec5fcc443a2314233e95bfece54 ] epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-2-den@valinux.co.jp [ adjusted context ] Signed-off-by: Sasha Levin commit 67fd62e3efdc9dce01f76d95a745212f4feb38e6 Author: Jeongjun Park Date: Sat Jan 10 23:58:29 2026 +0900 media: hackrf: fix to not free memory after the device is registered in hackrf_probe() commit 3b7da2b4d0fe014eff181ed37e3bf832eb8ed258 upstream. In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open("/path/to/dev"); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly. Cc: Reported-by: syzbot+6ffd76b5405c006a46b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6ffd76b5405c006a46b7 Reported-by: syzbot+f1b20958f93d2d250727@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1b20958f93d2d250727 Fixes: 8bc4a9ed8504 ("[media] hackrf: add support for transmitter") Signed-off-by: Jeongjun Park Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c034d8094fee474eb94142c17643eee2919079b7 Author: Abd-Alrhman Masalkhi Date: Sat Feb 21 13:56:18 2026 +0100 media: vidtv: fix pass-by-value structs causing MSAN warnings commit 5f8e73bde67e931468bc2a1860d78d72f0c6ba41 upstream. vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier. Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96f901260a0b2d29cd1a Tested-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com Suggested-by: Yihan Ding Signed-off-by: Abd-Alrhman Masalkhi Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7902b1df1520a0880bcda7a3704cfacd17905a83 Author: Deepanshu Kartikey Date: Tue Mar 31 09:47:21 2026 +0900 nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map commit 4a4e0328edd9e9755843787d28f16dd4165f8b48 upstream. The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it. Reported-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4b4093b1f24ad789bf37 Tested-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com Fixes: e897be17a441 ("nilfs2: fix lockdep warnings in page operations for btree nodes") Signed-off-by: Deepanshu Kartikey Signed-off-by: Ryusuke Konishi Cc: stable@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 07ceb444c8f627cf863864d4274b5a77769725ed Author: Jeongjun Park Date: Sun Jan 11 00:17:53 2026 +0900 media: as102: fix to not free memory after the device is registered in as102_usb_probe() commit 8bd29dbe03fc5b0f039ab2395ff37b64236d2f0c upstream. In as102_usb driver, the following race condition occurs: ``` CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed. Cc: Reported-by: syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()") Signed-off-by: Jeongjun Park Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9467d360be70e6ee55b0c1cd2a1f1424f57b5b85 Author: Mingzhe Zou Date: Sun Mar 22 21:41:02 2026 +0800 bcache: fix cached_dev.sb_bio use-after-free and crash commit fec114a98b8735ee89c75216c45a78e28be0f128 upstream. In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made. Signed-off-by: Mingzhe Zou Fixes: cafe563591446 ("bcache: A block layer cache") Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Coly Li Link: https://patch.msgid.link/20260322134102.480107-1-colyli@fnnas.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ba88461f7653636c48321ca993006a74724c2f41 Author: Berk Cem Goksel Date: Fri Apr 10 08:13:41 2026 +0300 ALSA: 6fire: fix use-after-free on disconnect commit b9c826916fdce6419b94eb0cd8810fdac18c2386 upstream. In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed. Fixes: a0810c3d6dd2 ("ALSA: 6fire: Release resources at card release") Cc: stable@vger.kernel.org Cc: Andrey Konovalov Signed-off-by: Berk Cem Goksel Link: https://patch.msgid.link/20260410051341.1069716-1-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 38a327221f7f765e7d853b7bafe47e342441ec85 Author: Abhishek Kumar Date: Tue Mar 10 22:14:37 2026 +0530 media: em28xx: fix use-after-free in em28xx_v4l2_open() commit a66485a934c7187ae8e36517d40615fa2e961cff upstream. em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock. Reported-by: syzbot+c025d34b8eaa54c571b8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c025d34b8eaa54c571b8 Fixes: 8139a4d583ab ("[media] em28xx: move v4l2 user counting fields from struct em28xx to struct v4l2") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Kumar Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 80900b5424f3454256153ce386388df43b324f63 Author: Ruslan Valiyev Date: Sun Mar 1 21:07:35 2026 +0000 media: vidtv: fix nfeeds state corruption on start_streaming failure commit a0e5a598fe9a4612b852406b51153b881592aede upstream. syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm "syz.0.17", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+639ebc6ec75e96674741@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=639ebc6ec75e96674741 Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 740ba1ebb223f137ff088ab74d533a13f9167bd8 Author: Breno Leitao Date: Mon Apr 13 03:09:19 2026 -0700 mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") Signed-off-by: Breno Leitao Reviewed-by: Dennis Zhou Reviewed-by: Shakeel Butt Cc: David Hildenbrand Cc: Jens Axboe Cc: Johannes Weiner Cc: Josef Bacik Cc: JP Kobryn Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Martin KaFai Lau Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2277246ea265cdca64ce6fdea4b26cd6ff0ec4db Author: Ritesh Harjani (IBM) Date: Tue Feb 24 18:53:16 2026 +0530 mm/kasan: fix double free for kasan pXds commit 51d8c78be0c27ddb91bc2c0263941d8b30a47d3b upstream. kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint Link: https://lkml.kernel.org/r/2f9135c7866c6e0d06e960993b8a5674a9ebc7ec.1771938394.git.ritesh.list@gmail.com Fixes: 0207df4fa1a8 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by: Ritesh Harjani (IBM) Reported-by: Venkat Rao Bagalkote Reviewed-by: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: "Ritesh Harjani (IBM)" Cc: Vincenzo Frascino Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 52570e73d48f1c73836d37e594667117b4c2a5a8 Author: Sean Christopherson Date: Tue Feb 24 17:20:36 2026 -0800 KVM: x86: Use scratch field in MMIO fragment to hold small write values commit 0b16e69d17d8c35c5c9d5918bf596c75a44655d3 upstream. When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *all* reads are buffered through the mem_read cache. Note! Using the scratch field for reads is not only unnecessary, it's also extremely difficult to handle correctly. As above, KVM buffers all reads through the mem_read cache, and heavily relies on that behavior when re-emulating the instruction after a userspace MMIO read exit. If a read splits a page, the first page is NOT an MMIO page, and the second page IS an MMIO page, then the MMIO fragment needs to point at _just_ the second chunk of the destination, i.e. its position in the mem_read cache. Taking the "obvious" approach of copying the fragment value into the destination when re-emulating the instruction would clobber the first chunk of the destination, i.e. would clobber the data that was read from guest memory. Fixes: f78146b0f923 ("KVM: Fix page-crossing MMIO") Suggested-by: Yashu Zhang Reported-by: Yashu Zhang Closes: https://lore.kernel.org/all/369eaaa2b3c1425c85e8477066391bc7@huawei.com Cc: stable@vger.kernel.org Tested-by: Tom Lendacky Tested-by: Rick Edgecombe Link: https://patch.msgid.link/20260225012049.920665-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e9bf5b384ad790d7bade81c305b3f8e17f9b2b1e Author: Sasha Levin Date: Wed Mar 11 17:58:17 2026 -0400 checkpatch: add support for Assisted-by tag commit d1db4118489fffd2b2f612140b7acbb477880839 upstream. The Assisted-by tag was introduced in Documentation/process/coding-assistants.rst for attributing AI tool contributions to kernel patches. However, checkpatch.pl did not recognize this tag, causing two issues: WARNING: Non-standard signature: Assisted-by: ERROR: Unrecognized email address: 'AGENT_NAME:MODEL_VERSION' Fix this by: 1. Adding Assisted-by to the recognized $signature_tags list 2. Skipping email validation for Assisted-by lines since they use the AGENT_NAME:MODEL_VERSION format instead of an email address 3. Warning when the Assisted-by value doesn't match the expected format Link: https://lkml.kernel.org/r/20260311215818.518930-1-sashal@kernel.org Signed-off-by: Sasha Levin Reported-by: Bart Van Assche Acked-by: Joe Perches Cc: Andy Whitcroft Cc: Dwaipayan Ray Cc: Jonathan Corbet Cc: Lukas Bulwahn Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 625af53a1564e31bb2df9adc3739df46137f46c1 Author: Pengpeng Hou Date: Tue Apr 14 10:26:20 2026 -0400 rxrpc: proc: size address buffers for %pISpc output [ Upstream commit a44ce6aa2efb61fe44f2cfab72bb01544bbca272 ] The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support") Signed-off-by: Pengpeng Hou Signed-off-by: David Howells cc: Marc Dionne cc: Anderson Nascimento cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-22-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ adapted address accessors and variable declarations ] Signed-off-by: Sasha Levin commit 4357dbb1d9c35ca0b4443d71c98a48e6666f7689 Author: Pablo Neira Ayuso Date: Fri Apr 17 16:21:24 2026 +0800 nf_tables: nft_dynset: fix possible stateful expression memleak in error path [ Upstream commit 0548a13b5a145b16e4da0628b5936baf35f51b43 ] If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330 Fixes: 563125a73ac3 ("netfilter: nftables: generalize set extension to support for several expressions") Reported-by: Gurpreet Shergill Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal [ Minor conflict resolved. ] Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Sasha Levin commit 7281d5b698d60fa46d17cd36ee8c5192fea9428d Author: Christian König Date: Fri Apr 17 15:40:10 2026 +0800 drm/amdgpu: remove two invalid BUG_ON()s [ Upstream commit 5d55ed19d4190d2c210ac05ac7a53f800a8c6fe5 ] Those can be triggered trivially by userspace. Signed-off-by: Christian König Reviewed-by: Alex Deucher Acked-by: Timur Kristóf Signed-off-by: Alex Deucher [ Modified to gfx_v11_0.c only. ] Signed-off-by: Robert Garcia Signed-off-by: Sasha Levin commit 074de2f6706ea840bbf06599cdc194086fbae092 Author: Wang Liang Date: Wed Apr 15 17:12:32 2026 +0800 bonding: check xdp prog when set bond mode [ Upstream commit 094ee6017ea09c11d6af187935a949df32803ce0 ] Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Fixes: 9e2ee5c7e7c3 ("net, bonding: Add XDP support to the bonding driver") Signed-off-by: Wang Liang Acked-by: Jussi Maki Reviewed-by: Nikolay Aleksandrov Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250321044852.1086551-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski [ Ignore changes in bond_xdp_set_features(), it was introduced to kernel in commit:cb9e6e584d58 ("bonding: add xdp_features support") since 6.4 ] Signed-off-by: Rajani Kantha <681739313@139.com> Signed-off-by: Sasha Levin commit 168c16359579bb7633586019c08966fb261343be Author: Hangbin Liu Date: Wed Apr 15 17:12:31 2026 +0800 bonding: return detailed error when loading native XDP fails [ Upstream commit 22ccb684c1cae37411450e6e86a379cd3c29cb8f ] Bonding only supports native XDP for specific modes, which can lead to confusion for users regarding why XDP loads successfully at times and fails at others. This patch enhances error handling by returning detailed error messages, providing users with clearer insights into the specific reasons for the failure when loading native XDP. Reviewed-by: Nikolay Aleksandrov Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20241021031211.814-2-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Rajani Kantha <681739313@139.com> Signed-off-by: Sasha Levin commit 519f496be031b57a6fe05d0dd280268078f19f59 Author: Eric Dumazet Date: Thu Apr 16 07:53:43 2026 -0700 net: sched: fix TCF_LAYER_TRANSPORT handling in tcf_get_base_ptr() [Upstream commit 4fe5a00ec70717a7f1002d8913ec6143582b3c8e] syzbot reported that tcf_get_base_ptr() can be called while transport header is not set [1]. Instead of returning a dangling pointer, return NULL. Fix tcf_get_base_ptr() callers to handle this NULL value. [1] WARNING: CPU: 1 PID: 6019 at ./include/linux/skbuff.h:3071 skb_transport_header include/linux/skbuff.h:3071 [inline] WARNING: CPU: 1 PID: 6019 at ./include/linux/skbuff.h:3071 tcf_get_base_ptr include/net/pkt_cls.h:539 [inline] WARNING: CPU: 1 PID: 6019 at ./include/linux/skbuff.h:3071 em_nbyte_match+0x2d8/0x3f0 net/sched/em_nbyte.c:43 Modules linked in: CPU: 1 UID: 0 PID: 6019 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: tcf_em_match net/sched/ematch.c:494 [inline] __tcf_em_tree_match+0x1ac/0x770 net/sched/ematch.c:520 tcf_em_tree_match include/net/pkt_cls.h:512 [inline] basic_classify+0x115/0x2d0 net/sched/cls_basic.c:50 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x4cf/0x1140 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xfd/0x4c0 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x4e/0x260 net/core/dev.c:4118 __dev_xmit_skb net/core/dev.c:4214 [inline] __dev_queue_xmit+0xe83/0x3b50 net/core/dev.c:4729 packet_snd net/packet/af_packet.c:3076 [inline] packet_sendmsg+0x3e33/0x5080 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x830 net/socket.c:2630 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+f3a497f02c389d86ef16@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6920855a.a70a0220.2ea503.0058.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20251121154100.1616228-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Chelsy Ratnawat Signed-off-by: Sasha Levin commit e974a10a52618f7f57a4bce173a0ed96acd4e5dc Author: Eric Dumazet Date: Wed Apr 15 16:28:46 2026 +0800 net: add proper RCU protection to /proc/net/ptype [ Upstream commit f613e8b4afea0cd17c7168e8b00e25bc8d33175d ] Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch. Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules. ptype_seq_show() runs under rcu_read_lock(), and reads pt->dev to get device name without any barrier. At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period. Define ptype_iter_state to carry a dev pointer along seq_net_private: struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch }; We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt->dev changes. We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values) Many thanks to Dong Chenchen for providing a repro. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 1d10f8a1f40b ("net-procfs: show net devices bound packet types") Fixes: c353e8983e0d ("net: introduce per netns packet chains") Reported-by: Yin Fengwei Reported-by: Dong Chenchen Closes: https://lore.kernel.org/netdev/CANn89iKRRKPnWjJmb-_3a=sq+9h6DvTQM4DBZHT5ZRGPMzQaiA@mail.gmail.com/T/#m7b80b9fc9b9267f90e0b7aad557595f686f9c50d Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Tested-by: Yin Fengwei Link: https://patch.msgid.link/20260202205217.2881198-1-edumazet@google.com Signed-off-by: Jakub Kicinski [ Some adjustments have been made. ] Signed-off-by: XiaoHua Wang <561399680@139.com> Signed-off-by: Sasha Levin commit e16985513e89466a236d2a7c202783b4dd0c5a46 Author: Jeongjun Park Date: Fri Apr 17 16:45:16 2026 +0800 ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free [ Upstream commit 9f2c0ac1423d5f267e7f1d1940780fc764b0fee3 ] The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") patched a UAF issue caused by the error timer. However, because the error timer kill added in this patch occurs after the endpoint delete, a race condition to UAF still occurs, albeit rarely. Additionally, since kill-cleanup for urb is also missing, freed memory can be accessed in interrupt context related to urb, which can cause UAF. Therefore, to prevent this, error timer and urb must be killed before freeing the heap memory. Cc: Reported-by: syzbot+f02665daa2abeef4a947@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f02665daa2abeef4a947 Fixes: 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") Signed-off-by: Jeongjun Park Signed-off-by: Takashi Iwai Signed-off-by: Wenshan Lan Signed-off-by: Sasha Levin commit 22dff5033d4d4f880196f0831e05e98d3ad6922b Author: Sasha Levin Date: Mon Apr 20 00:01:51 2026 -0400 Revert "dmaengine: idxd: Fix not releasing workqueue on .release()" This reverts commit fd4cb61bbd0fc3a749a8da6145cbb56d8f6dba35. Signed-off-by: Sasha Levin commit abcd43ff579abd0a654bb4636086e78819dd5f4c Author: Sean Christopherson Date: Thu Mar 12 17:32:58 2026 -0700 KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION commit 8acffeef5ef720c35e513e322ab08e32683f32f2 upstream. Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. if (range->addr > ULONG_MAX || range->size > ULONG_MAX) return -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen. Fixes: 78824fabc72e ("KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()") Cc: stable@vger.kernel.org Reviewed-by: Liam Merwick Tested-by: Liam Merwick Link: https://patch.msgid.link/20260313003302.3136111-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit b328d8e7c437d0f026ba2c13788af6eae77700f1 Author: ZhengYuan Huang Date: Wed Apr 1 17:23:03 2026 +0800 ocfs2: handle invalid dinode in ocfs2_group_extend commit 4a1c0ddc6e7bcf2e9db0eeaab9340dcfe97f448f upstream. [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel. Link: https://lkml.kernel.org/r/20260401092303.3709187-1-gality369@gmail.com Fixes: 10995aa2451a ("ocfs2: Morph the haphazard OCFS2_IS_VALID_DINODE() checks.") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3f5e74b5db9353b01ed50f4de84e75b755f8fbc2 Author: Tejas Bharambe Date: Fri Apr 10 01:38:16 2026 -0700 ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY commit 7de554cabf160e331e4442e2a9ad874ca9875921 upstream. filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()." When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward. Link: https://lkml.kernel.org/r/20260410083816.34951-1-tejas.bharambe@outlook.com Fixes: 614a9e849ca6 ("ocfs2: Remove FILE_IO from masklog.") Signed-off-by: Tejas Bharambe Reported-by: syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a49010a0e8fcdeea075f Suggested-by: Joseph Qi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 93f35419eb84d58820040642cb6e7528fe4aba7a Author: Joseph Qi Date: Fri Mar 6 11:22:11 2026 +0800 ocfs2: fix possible deadlock between unlink and dio_end_io_write commit b02da26a992db0c0e2559acbda0fc48d4a2fd337 upstream. ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock. Link: https://lkml.kernel.org/r/20260306032211.1016452-1-joseph.qi@linux.alibaba.com Reported-by: syzbot+67b90111784a3eac8c04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67b90111784a3eac8c04 Fixes: a86a72a4a4e0 ("ocfs2: take ip_alloc_sem in ocfs2_dio_get_block & ocfs2_dio_end_io_write") Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 93d9e747a9e8a5ca9e3c5e37dcff76b40399139f Author: Ruslan Valiyev Date: Tue Mar 3 11:27:54 2026 +0000 media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections commit f8e1fc918a9fe67103bcda01d20d745f264d00a7 upstream. syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+1f5bcc7c919ec578777a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1f5bcc7c919ec578777a Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 45b06bb5ea96f75ad81d7ef446f832ea6b0026fe Author: Zhihao Cheng Date: Fri Jan 30 11:48:53 2026 +0800 dcache: Limit the minimal number of bucket to two commit f08fe8891c3eeb63b73f9f1f6d97aa629c821579 upstream. There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32. Cc: stable@vger.kernel.org Signed-off-by: Zhihao Cheng Link: https://patch.msgid.link/20260130034853.215819-1-chengzhihao1@huawei.com Reviewed-by: Yang Erkun Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 2b4331c08c0b385598b4d8ccd71e93ab3f4b2578 Author: Harin Lee Date: Mon Apr 6 16:48:57 2026 +0900 ALSA: ctxfi: Limit PTP to a single page commit e9418da50d9e5c496c22fe392e4ad74c038a94eb upstream. Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged. Fixes: 391e69143d0a ("ALSA: ctxfi: Bump playback substreams to 256") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260406074857.216034-1-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7726a9fd838e9bb6133103e68701e1554c984dba Author: SeongJae Park Date: Sun Mar 29 08:30:49 2026 -0700 Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race commit 0beba407d4585a15b0dc09f2064b5b3ddcb0e857 upstream. Patch series "Docs/admin-guide/mm/damon: warn commit_inputs vs other params race". Writing 'Y' to the commit_inputs parameter of DAMON_RECLAIM and DAMON_LRU_SORT, and writing other parameters before the commit_inputs request is completely processed can cause race conditions. While the consequence can be bad, the documentation is not clearly describing that. Add clear warnings. The issue was discovered [1,2] by sashiko. This patch (of 2): DAMON_RECLAIM handles commit_inputs request inside kdamond thread, reading the module parameters. If the user updates the module parameters while the kdamond thread is reading those, races can happen. To avoid this, the commit_inputs parameter shows whether it is still in the progress, assuming users wouldn't update parameters in the middle of the work. Some users might ignore that. Add a warning about the behavior. The issue was discovered in [1] by sashiko. Link: https://lore.kernel.org/20260329153052.46657-2-sj@kernel.org Link: https://lore.kernel.org/20260319161620.189392-3-objecting@objecting.org [1] Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org [3] Fixes: 81a84182c343 ("Docs/admin-guide/mm/damon/reclaim: document 'commit_inputs' parameter") Signed-off-by: SeongJae Park Cc: # 5.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 42af42e8a978d081e5816db29049e87f7da94203 Author: Fabio Porcedda Date: Thu Apr 2 11:57:27 2026 +0200 USB: serial: option: add Telit Cinterion FN990A MBIM composition commit f8cc59ecc22841be5deb07b549c0c6a2657cd5f9 upstream. Add the following Telit Cinterion FN990A MBIM composition: 0x1074: MBIM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (diag) + DPL (Data Packet Logging) + adb T: Bus=01 Lev=01 Prnt=04 Port=06 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1074 Rev=05.04 S: Manufacturer=Telit Wireless Solutions S: Product=FN990 S: SerialNumber=70628d0c C: #Ifs= 8 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3300b049693138852a4c6738b5f1194a1ee91ddd Author: Junrui Luo Date: Mon Mar 23 15:31:56 2026 +0800 staging: sm750fb: fix division by zero in ps_to_hz() commit 75a1621e4f91310673c9acbcbb25c2a7ff821cd3 upstream. ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers. Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881AFBFCE28CCF528B35D0CAF4BA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 11cd1cf6a4c77ef8afb9ac382147e854e5e4804f Author: Tamir Duberstein Date: Tue Jan 27 11:35:43 2026 -0500 scripts: generate_rust_analyzer.py: avoid FD leak commit 9b4744d8eda2824041064a5639ccbb079850914d upstream. Use `pathlib.Path.read_text()` to avoid leaking file descriptors. Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Cc: stable@vger.kernel.org Reviewed-by: Daniel Almeida Reviewed-by: Fiona Behrens Reviewed-by: Trevor Gross Link: https://patch.msgid.link/20260127-rust-analyzer-fd-leak-v2-1-1bb55b9b6822@kernel.org Signed-off-by: Tamir Duberstein Signed-off-by: Greg Kroah-Hartman commit 828ce54b27de93bd9c67991bca5a2c76c76742de Author: Greg Kroah-Hartman Date: Thu Apr 9 15:23:46 2026 +0200 fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO commit a31e4518bec70333a0a98f2946a12b53b45fe5b9 upstream. Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash. Cc: Bernie Thompson Cc: Helge Deller Fixes: 59277b679f8b ("Staging: udlfb: add dynamic modeset support") Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d76638353ae9212883de34ce08d2ca7697bbd658 Author: Xu Yang Date: Mon Mar 16 17:50:42 2026 +0800 usb: port: add delay after usb_hub_set_port_power() commit b84cc80610a8ce036deb987f056ce3196ead7f1e upstream. When a port is disabled, an attached device will be disconnected. This causes a port-status-change event, which will race with hub autosuspend (if the disabled port was the only connected port on its hub), causing an immediate resume and a second autosuspend. Both of these can be avoided by adding a short delay after the call to usb_hub_set_port_power(). Below log shows what is happening: $ echo 1 > usb1-port1/disable [ 37.958239] usb 1-1: USB disconnect, device number 2 [ 37.964101] usb 1-1: unregistering device [ 37.970070] hub 1-0:1.0: hub_suspend [ 37.971305] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 [ 37.974412] usb usb1: bus auto-suspend, wakeup 1 [ 37.988175] usb usb1: suspend raced with wakeup event <--- [ 37.993947] usb usb1: usb auto-resume [ 37.998401] hub 1-0:1.0: hub_resume [ 38.105688] usb usb1-port1: status 0000, change 0000, 12 Mb/s [ 38.112399] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 38.118645] hub 1-0:1.0: hub_suspend [ 38.122963] usb usb1: bus auto-suspend, wakeup 1 [ 38.200368] usb usb1: usb wakeup-resume [ 38.204982] usb usb1: usb auto-resume [ 38.209376] hub 1-0:1.0: hub_resume [ 38.213676] usb usb1-port1: status 0101 change 0001 [ 38.321552] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000 [ 38.327978] usb usb1-port1: status 0101, change 0000, 12 Mb/s [ 38.457429] usb 1-1: new high-speed USB device number 3 using ci_hdrc Then, port change bit will be fixed to the final state and usb_clear_port_feature() can correctly clear it after this period. This will also avoid usb runtime suspend routine to run because usb_autopm_put_interface() not run yet. Fixes: f061f43d7418 ("usb: hub: port: add sysfs entry to switch port power") Cc: stable@kernel.org Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260316095042.1559882-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit d826061aa64cb28089bf4c73e301dd7928662b84 Author: Dave Carey Date: Thu Apr 2 14:29:50 2026 -0400 USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen commit f58752ebcb35e156c85cd1a82d6579c7af3b9023 upstream. The Lenovo Yoga Book 9 14IAH10 (83KJ) has a composite USB device (17EF:6161) that controls both touchscreens via a CDC ACM interface. Interface 0 is a standard CDC ACM control interface, but interface 1 (the data interface) incorrectly declares vendor-specific class (0xFF) instead of USB_CLASS_CDC_DATA. cdc-acm rejects the device at probe with -EINVAL, leaving interface 0 unbound and EP 0x82 never polled. With no consumer polling EP 0x82, the firmware's watchdog fires every ~20 seconds and resets the USB bus, producing a continuous disconnect/ reconnect loop that prevents the touchscreens from ever initialising. Add two new quirk flags: VENDOR_CLASS_DATA_IFACE: Bypasses the bInterfaceClass check in acm_probe() that would otherwise reject the vendor-class data interface with -EINVAL. ALWAYS_POLL_CTRL: Submits the notification URB at probe() rather than waiting for a TTY open. This keeps EP 0x82 polled at all times, permanently suppressing the firmware watchdog. The URB is resubmitted after port_shutdown() and on system resume. SET_CONTROL_LINE_STATE (DTR|RTS) is sent at probe and after port_shutdown() to complete firmware handshake. Note: the firmware performs exactly 4 USB connect/disconnect cycles (~19 s each) on every cold boot before stabilising. This is a fixed firmware property; touch is available ~75-80 s after power-on. Signed-off-by: Dave Carey Cc: stable Tested-by: Dave Carey Acked-by: Oliver Neukum Link: https://patch.msgid.link/20260402182950.389016-1-carvsdriver@gmail.com Signed-off-by: Greg Kroah-Hartman commit 36e1da02ddc36d55864da1a8b59d55fa7c4bd9a8 Author: Daniel Brát Date: Thu Apr 2 19:24:33 2026 +0200 usb: storage: Expand range of matched versions for VL817 quirks entry commit 609865ab3d5d803556f628e221ecd3d06aed9f30 upstream. Expands range of matched bcdDevice values for the VL817 quirk entry. This is based on experience with Axagon EE35-GTR rev1 3.5" HDD enclosure, which reports its bcdDevice as 0x0843, but presumably other vendors using this IC in their products may set it to any other value. Signed-off-by: Daniel Brát Cc: stable Link: https://patch.msgid.link/20260402172433.5227-1-danek.brat@gmail.com Signed-off-by: Greg Kroah-Hartman commit ce744264b06b97069b3722511ab355738311fee0 Author: Nathan Rebello Date: Thu Apr 2 04:52:59 2026 -0400 usbip: validate number_of_packets in usbip_pack_ret_submit() commit 2ab833a16a825373aad2ba7d54b572b277e95b71 upstream. When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early. Fixes: 1325f85fa49f ("staging: usbip: bugfix add number of packets for isochronous frames") Cc: stable Acked-by: Shuah Khan Signed-off-by: Nathan Rebello Link: https://patch.msgid.link/20260402085259.234-1-nathan.c.rebello@gmail.com Signed-off-by: Greg Kroah-Hartman commit cf2148b880fb7c0fcd727202dbc4fd5d6998b9c2 Author: Greg Kroah-Hartman Date: Mon Apr 6 15:46:47 2026 +0200 ksmbd: require 3 sub-authorities before reading sub_auth[2] commit 53370cf9090777774e07fd9a8ebce67c6cc333ab upstream. parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares only min(num_subauth, 2) sub-authorities so a client SID with num_subauth = 2 and sub_auth = {88, 3} will match. If num_subauth = 2 and the ACE is placed at the very end of the security descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen. Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all. Cc: Namjae Jeon Cc: Steve French Cc: Sergey Senozhatsky Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 859f11e1bc81a4d32bb3ceeae54bcd296ac675d3 Author: Greg Kroah-Hartman Date: Mon Apr 6 15:46:46 2026 +0200 ksmbd: validate EaNameLength in smb2_get_ea() commit 66751841212c2cc196577453c37f7774ff363f02 upstream. smb2_get_ea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received. Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a "trusted" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client. Cc: Namjae Jeon Cc: Steve French Cc: Sergey Senozhatsky Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 360aa6e71870a175a6d86af905be2ca171639eb3 Author: Greg Kroah-Hartman Date: Mon Apr 6 17:09:48 2026 +0200 usb: gadget: renesas_usb3: validate endpoint index in standard request handlers commit f880aac8a57ebd92abfa685d45424b2998ac1059 upstream. The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeed_udc: validate endpoint index for ast udc") for the aspeed driver. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040647-sincerity-untidy-b104@gregkh Signed-off-by: Greg Kroah-Hartman commit 7424f0287da73d3d8c5fa5e9d25d26fce762708e Author: Greg Kroah-Hartman Date: Tue Apr 7 10:55:05 2026 +0200 usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() commit c088d5dd2fffb4de1fb8e7f57751c8b82942180a upstream. A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path"). Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040705-fruit-unloved-0701@gregkh Signed-off-by: Greg Kroah-Hartman commit 8b3b7bd3c02f98634baaf36c7fc7ac915f6517ca Author: Greg Kroah-Hartman Date: Tue Apr 7 11:02:54 2026 +0200 usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() commit 8f993d30b95dc9557a8a96ceca11abed674c8acb upstream. The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: ndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM. Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040753-baffle-handheld-624d@gregkh Signed-off-by: Greg Kroah-Hartman commit 59bde9e0930efef1286768cb65fc78d5e5267f93 Author: Greg Kroah-Hartman Date: Thu Apr 9 15:23:14 2026 +0200 fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO commit 8f98b81fe011e1879e6a7b1247e69e06a5e17af2 upstream. Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash. Cc: Helge Deller Assisted-by: gregkh_clanker_t1000 Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 327f8e730e3c65ec97df9d3b07de66aeb3dc932d Author: Greg Kroah-Hartman Date: Thu Apr 9 16:05:54 2026 +0200 ALSA: fireworks: bound device-supplied status before string array lookup commit 07704bbf36f57e4379e4cadf96410dab14621e3b upstream. The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing "unknown" if it's not recognized. Cc: Clemens Ladisch Cc: Takashi Sakamoto Cc: Jaroslav Kysela Cc: Takashi Iwai Fixes: bde8a8f23bbe ("ALSA: fireworks: Add transaction and some commands") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: Takashi Sakamoto Link: https://patch.msgid.link/2026040953-astute-camera-1aa1@gregkh Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 59ece0d4d1db0cf483c4c51a58691f50ff81d3a2 Author: Greg Kroah-Hartman Date: Mon Feb 23 16:53:39 2026 +0100 drm/vc4: platform_get_irq_byname() returns an int commit e597a809a2b97e927060ba182f58eb3e6101bc70 upstream. platform_get_irq_byname() will return a negative value if an error happens, so it should be checked and not just passed directly into devm_request_threaded_irq() hoping all will be ok. Cc: Maxime Ripard Cc: Dave Stevenson Cc: Maíra Canal Cc: Raspberry Pi Kernel Maintenance Cc: Maarten Lankhorst Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022339-cornflake-t-shirt-2471@gregkh Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 20663102c14566e900e1d2f679e30b7f1694f387 Author: Greg Kroah-Hartman Date: Thu Apr 9 17:18:14 2026 +0200 NFC: digital: Bounds check NFC-A cascade depth in SDD response handler commit 46ce8be2ced389bccd84bcc04a12cf2f4d0c22d1 upstream. The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays") fixed similar missing checks against the same field on the NCI path. Cc: Simon Horman Cc: Kees Cook Cc: Thierry Escande Cc: Samuel Ortiz Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026040913-figure-seducing-bd3f@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6053620fdbcd89fa7e755644efdaab78e0daaae7 Author: Greg Kroah-Hartman Date: Sat Apr 11 13:01:35 2026 +0200 net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() commit 600dc40554dc5ad1e6f3af51f700228033f43ea7 upstream. A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") did for the t7xx driver. Cc: Andrew Lunn Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026041134-dreamboat-buddhism-d1ec@gregkh Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver") Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0ab048dbdb1daacf17d52e9252297eb6e1298e49 Author: Greg Kroah-Hartman Date: Mon Apr 6 16:04:10 2026 +0200 HID: core: clamp report_size in s32ton() to avoid undefined shift commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream. s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_event") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does. Cc: stable Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cc411e4823d8bfa23327d9989a0fa4e0ce76aebe Author: Greg Kroah-Hartman Date: Mon Apr 6 16:03:25 2026 +0200 HID: alps: fix NULL pointer dereference in alps_raw_event() commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream. Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at raw event handle"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event. Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device") Cc: stable Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Masaki Ota Cc: linux-input@vger.kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9e911eead187240193516edf55a0e1ab3425aa5b Author: Lin YuChen Date: Sat Mar 21 01:25:02 2026 +0800 staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() commit 8c964b82a4e97ec7f25e17b803ee196009b38a57 upstream. Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-staging/abvwIQh0CHTp4wNJ@stanley.mountain/ Signed-off-by: Lin YuChen Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260320172502.167332-1-starpt.official@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2d262da4bca6fab96e2e709feb95b31b0a9a03a7 Author: Greg Kroah-Hartman Date: Mon Feb 23 18:05:15 2026 +0100 i2c: s3c24xx: check the size of the SMBUS message before using it commit c0128c7157d639a931353ea344fb44aad6d6e17a upstream. The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b ("i2c: tegra: check msg length in SMBUS block read") to the i2c tegra driver. Cc: Krzysztof Kozlowski Cc: Alim Akhtar Cc: Andi Shyti Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/2026022314-rely-scrubbed-4839@gregkh Signed-off-by: Greg Kroah-Hartman commit 3f43f12fde34737fba091b7e3ab391e14ddbb0be Author: Samuel Page Date: Wed Apr 8 15:30:13 2026 +0100 can: raw: fix ro->uniq use-after-free in raw_rcv() commit a535a9217ca3f2fccedaafb2fddb4c48f27d36dc upstream. raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters") Cc: stable@vger.kernel.org # v4.1+ Assisted-by: Bynario AI Signed-off-by: Samuel Page Link: https://patch.msgid.link/26ec626d-cae7-4418-9782-7198864d070c@bynar.io Acked-by: Oliver Hartkopp [mkl: applied manually] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 9b49e2a4b8219a2fc5cebf94f4ec34e509aff8a6 Author: Junxi Qian Date: Wed Apr 8 16:10:06 2026 +0800 nfc: llcp: add missing return after LLCP_CLOSED checks commit 2b5dd4632966c39da6ba74dbc8689b309065e82c upstream. In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through. Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Junxi Qian Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260408081006.3723-1-qjx1298677004@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f4ed5ad883e036eccc6cf7602615d8a76533f1c7 Author: Jouni Högander Date: Mon Apr 13 14:59:00 2026 -0400 drm/i915/psr: Do not use pipe_src as borders for SU area [ Upstream commit 75519f5df2a9b23f7bf305e12dc9a6e3e65c24b7 ] This far using crtc_state->pipe_src as borders for Selective Update area haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_hdisplay and drm_rect_height(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not used. On the other hand using pipe scaling is forcing full frame updates and all the Selective Update area calculations are skipped. Now this improper usage of crtc_state->pipe_src is causing following warnings: <4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height) after WARN_ON_ONCE was added by commit: "drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters" These warnings are seen when DSC and pipe scaling are enabled simultaneously. This is because on full frame update SU area is improperly set as pipe_src which is not aligned with DSC slice height. Fix these by creating local rectangle using crtc_state->hw.adjusted_mode.crtc_hdisplay and crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as borders for SU area. Fixes: d6774b8c3c58 ("drm/i915: Ensure damage clip area is within pipe area") Cc: # v6.0+ Signed-off-by: Jouni Högander Reviewed-by: Mika Kahola Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com (cherry picked from commit da0cdc1c329dd2ff09c41fbbe9fbd9c92c5d2c6e) Signed-off-by: Joonas Lahtinen [ omitted hunks for DSC selective update ET alignment infrastructure ] Signed-off-by: Sasha Levin commit be88a337bf07afb1ee173f1099294d1b7ab3fefe Author: Florian Westphal Date: Tue Mar 10 00:28:29 2026 +0100 netfilter: conntrack: add missing netlink policy validations [ Upstream commit f900e1d77ee0ef87bfb5ab3fe60f0b3d8ad5ba05 ] Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Fixes: a258860e01b8 ("netfilter: ctnetlink: add full support for SCTP to ctnetlink") Reported-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 2bf5f11cea4cf21d09f89cd1984a92eaafd295db Author: Maarten Lankhorst Date: Mon Apr 13 10:05:47 2026 +0200 Revert "drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug" commit 45ebe43ea00d6b9f5b3e0db9c35b8ca2a96b7e70 upstream. This reverts commit 6bee098b91417654703e17eb5c1822c6dfd0c01d. Den 2026-03-25 kl. 22:11, skrev Simona Vetter: > On Wed, Mar 25, 2026 at 10:26:40AM -0700, Guenter Roeck wrote: >> Hi, >> >> On Fri, Mar 13, 2026 at 04:17:27PM +0100, Maarten Lankhorst wrote: >>> When trying to do a rather aggressive test of igt's "xe_module_load >>> --r reload" with a full desktop environment and game running I noticed >>> a few OOPSes when dereferencing freed pointers, related to >>> framebuffers and property blobs after the compositor exits. >>> >>> Solve this by guarding the freeing in drm_file with drm_dev_enter/exit, >>> and immediately put the references from struct drm_file objects during >>> drm_dev_unplug(). >>> >> >> With this patch in v6.18.20, I get the warning backtraces below. >> The backtraces are gone with the patch reverted. > > Yeah, this needs to be reverted, reasoning below. Maarten, can you please > take care of that and feed the revert through the usual channels? I don't > think it's critical enough that we need to fast-track this into drm.git > directly. > > Quoting the patch here again: > >> drivers/gpu/drm/drm_file.c| 5 ++++- >> drivers/gpu/drm/drm_mode_config.c | 9 ++++++--- >> 2 files changed, 10 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c >> index ec820686b3021..f52141f842a1f 100644 >> --- a/drivers/gpu/drm/drm_file.c >> +++ b/drivers/gpu/drm/drm_file.c >> @@ -233,6 +233,7 @@ static void drm_events_release(struct drm_file *file_priv) >> void drm_file_free(struct drm_file *file) >> { >> struct drm_device *dev; >> +int idx; >> >> if (!file) >> return; >> @@ -249,9 +250,11 @@ void drm_file_free(struct drm_file *file) >> >> drm_events_release(file); >> >> -if (drm_core_check_feature(dev, DRIVER_MODESET)) { >> +if (drm_core_check_feature(dev, DRIVER_MODESET) && >> +drm_dev_enter(dev, &idx)) { > > This is misplaced for two reasons: > > - Even if we'd want to guarantee that we hold a drm_dev_enter/exit > reference during framebuffer teardown, we'd need to do this > _consistently over all callsites. Not ad-hoc in just one place that a > testcase hits. This also means kerneldoc updates of the relevant hooks > and at least a bunch of acks from other driver people to document the > consensus. > > - More importantly, this is driver responsibilities in general unless we > have extremely good reasons to the contrary. Which means this must be > placed in xe. > >> drm_fb_release(file); >> drm_property_destroy_user_blobs(dev, file); >> +drm_dev_exit(idx); >> } >> >> if (drm_core_check_feature(dev, DRIVER_SYNCOBJ)) >> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c >> index 84ae8a23a3678..e349418978f79 100644 >> --- a/drivers/gpu/drm/drm_mode_config.c >> +++ b/drivers/gpu/drm/drm_mode_config.c >> @@ -583,10 +583,13 @@ void drm_mode_config_cleanup(struct drm_device *dev) >> */ >> WARN_ON(!list_empty(&dev->mode_config.fb_list)); >> list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) { >> -struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); >> +if (list_empty(&fb->filp_head) || drm_framebuffer_read_refcount(fb) > 1) { >> +struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); > > This is also wrong: > > - Firstly, it's a completely independent bug, we do not smash two bugfixes > into one patch. > > - Secondly, it's again a driver bug: drm_mode_cleanup must be called when > the last drm_device reference disappears (hence the existence of > drmm_mode_config_init), not when the driver gets unbound. The fact that > this shows up in a callchain from a devres cleanup means the intel > driver gets this wrong (like almost everyone else because historically > we didn't know better). > > If we don't follow this rule, then we get races with this code here > running concurrently with drm_file fb cleanups, which just does not > work. Review pointed that out, but then shrugged it off with a confused > explanation: > > https://lore.kernel.org/all/e61e64c796ccfb17ae673331a3df4b877bf42d82.camel@linux.intel.com/ > > Yes this also means a lot of the other drm_device teardown that drivers > do happens way too early. There is a massive can of worms here of a > magnitude that most likely is much, much bigger than what you can > backport to stable kernels. Hotunplug is _hard_. Back to the drawing board, and fixing it in the intel display driver instead. Cc: Thomas Hellström Fixes: 6bee098b9141 ("drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug") Reported-by: Guenter Roeck Tested-by: Guenter Roeck Acked-by: Simona Vetter Signed-off-by: Maarten Lankhorst Link: https://patch.msgid.link/20260326082217.39941-2-dev@lankhorst.se [ Thorsten: adjust to the v6.6.y/v6.6.y backports of 6bee098b9141 ] Signed-off-by: Thorsten Leemhuis Signed-off-by: Sasha Levin commit dfcba8c8674cead6c88a2f269b71aa4efd3d384a Author: Zide Chen Date: Fri Mar 13 10:40:48 2026 -0700 perf/x86/intel/uncore: Skip discovery table for offline dies [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Reported-by: Steve Wahl Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Tested-by: Steve Wahl Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com Signed-off-by: Sasha Levin commit aeb6c6b978345eb8d7346d54bef4b345eb2b94e7 Author: Samasth Norway Ananda Date: Tue Apr 7 14:02:47 2026 -0700 gpio: tegra: fix irq_release_resources calling enable instead of disable [ Upstream commit 1561d96f5f55c1bca9ff047ace5813f4f244eea6 ] tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable() instead of tegra_gpio_disable(). When IRQ resources are released, the GPIO configuration bit (CNF) should be cleared to deconfigure the pin as a GPIO. Leaving it enabled wastes power and can cause unexpected behavior if the pin is later reused for an alternate function via pinctrl. Fixes: 66fecef5bde0 ("gpio: tegra: Convert to gpio_irq_chip") Signed-off-by: Samasth Norway Ananda Link: https://patch.msgid.link/20260407210247.1737938-1-samasth.norway.ananda@oracle.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit a42452db035577e150ffd9adf98c56fef9fb9408 Author: Alice Mikityanska Date: Fri Apr 3 20:49:49 2026 +0300 l2tp: Drop large packets with UDP encap [ Upstream commit ebe560ea5f54134279356703e73b7f867c89db13 ] syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/ Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/ Signed-off-by: Alice Mikityanska Link: https://patch.msgid.link/20260403174949.843941-1-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c3ec44ab4526bbc4b6c9fc845af86488244f4c9b Author: Jiexun Wang Date: Tue Apr 7 16:00:14 2026 +0800 af_unix: read UNIX_DIAG_VFS data under unix_state_lock [ Upstream commit 39897df386376912d561d4946499379effa1e7ef ] Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built. Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260407080015.1744197-1-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d5603591373441fecf9951833d6d873e09320f08 Author: Zhengchuan Liang Date: Sat Apr 4 17:39:47 2026 +0800 netfilter: ip6t_eui64: reject invalid MAC header for all packets [ Upstream commit fdce0b3590f724540795b874b4c8850c90e6b0a8 ] `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit b67d638cbee9975c765feb45c126e96ed11ec802 Author: Ren Wei Date: Fri Apr 3 23:52:52 2026 +0800 netfilter: xt_multiport: validate range encoding in checkentry [ Upstream commit ff64c5bfef12461df8450e0f50bb693b5269c720 ] ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start. Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuhang Zheng Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 57cc509d82b46150a11dcecc8b25eaa177eda34d Author: Xiang Mei Date: Wed Apr 1 14:20:57 2026 -0700 netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator [ Upstream commit 1f3083aec8836213da441270cdb1ab612dd82cf4 ] When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers. Fixes: 29c5d4afba51 ("[NETFILTER]: nfnetlink_log: fix sending of multipart messages") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a616888a3fbc5e8141ba864a464525bcca5ff86d Author: Daniel Golle Date: Sun Apr 5 22:29:19 2026 +0100 selftests: net: bridge_vlan_mcast: wait for h1 before querier check [ Upstream commit efaa71faf212324ecbf6d5339e9717fe53254f58 ] The querier-interval test adds h1 (currently a slave of the VRF created by simple_if_init) to a temporary bridge br1 acting as an outside IGMP querier. The kernel VRF driver (drivers/net/vrf.c) calls cycle_netdev() on every slave add and remove, toggling the interface admin-down then up. Phylink takes the PHY down during the admin-down half of that cycle. Since h1 and swp1 are cable-connected, swp1 also loses its link may need several seconds to re-negotiate. Use setup_wait_dev $h1 0 which waits for h1 to return to UP state, so the test can rely on the link being back up at this point. Fixes: 4d8610ee8bd77 ("selftests: net: bridge: add vlan mcast_querier_interval tests") Signed-off-by: Daniel Golle Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/c830f130860fd2efae08bfb9e5b25fd028e58ce5.1775424423.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72a8de41c3eb4dcf22bf3b674ea38fb2f75d6f32 Author: Greg Kroah-Hartman Date: Mon Apr 6 17:33:03 2026 +0200 xfrm_user: fix info leak in build_mapping() [ Upstream commit 1beb76b2053b68c491b78370794b8ff63c8f8c02 ] struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables. Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") Cc: Steffen Klassert Cc: Herbert Xu Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8769708add9eadeea8041a9761771bb715a87104 Author: Maciej Fijalkowski Date: Thu Apr 2 17:49:51 2026 +0200 xsk: tighten UMEM headroom validation to account for tailroom and min frame [ Upstream commit a315e022a72d95ef5f1d4e58e903cb492b0ad931 ] The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront. Reviewed-by: Björn Töpel Acked-by: Stanislav Fomichev Fixes: 99e3a236dd43 ("xsk: Add missing check on user supplied headroom size") Signed-off-by: Maciej Fijalkowski Link: https://patch.msgid.link/20260402154958.562179-2-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7dd86e7d44b746cc401d2d6da8ca2bbd5918a5c9 Author: Agalakov Daniil Date: Wed Mar 18 15:05:05 2026 +0300 e1000: check return value of e1000_read_eeprom [ Upstream commit d3baa34a470771399c1495bc04b1e26ac15d598e ] [Why] e1000_set_eeprom() performs a read-modify-write operation when the write range is not word-aligned. This requires reading the first and last words of the range from the EEPROM to preserve the unmodified bytes. However, the code does not check the return value of e1000_read_eeprom(). If the read fails, the operation continues using uninitialized data from eeprom_buff. This results in corrupted data being written back to the EEPROM for the boundary words. Add the missing error checks and abort the operation if reading fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Co-developed-by: Iskhakov Daniil Signed-off-by: Iskhakov Daniil Signed-off-by: Agalakov Daniil Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 376d74ea03589914fbe2dedcbebf418396c04fd0 Author: Michal Schmidt Date: Fri Mar 13 09:22:29 2026 +0100 ixgbevf: add missing negotiate_features op to Hyper-V ops table [ Upstream commit 4821d563cd7f251ae728be1a6d04af82a294a5b9 ] Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") added the .negotiate_features callback to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL on Hyper-V VMs. During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(), which unconditionally dereferences hw->mac.ops.negotiate_features(). On Hyper-V this results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events work_for_cpu_fn RIP: 0010:0x0 [...] Call Trace: ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...] Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP gracefully. Fixes: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") Reported-by: Xiaoqiang Xiong Closes: https://issues.redhat.com/browse/RHEL-155455 Assisted-by: Claude:claude-4.6-opus-high Cursor Tested-by: Xiaoqiang Xiong Signed-off-by: Michal Schmidt Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9a385db15c1c7c3a6cea5f3a63756ade5eca09be Author: Pengpeng Hou Date: Thu Apr 2 00:03:15 2026 +0800 tracing/probe: reject non-closed empty immediate strings [ Upstream commit 4346be6577aaa04586167402ae87bbdbe32484a4 ] parse_probe_arg() accepts quoted immediate strings and passes the body after the opening quote to __parse_imm_string(). That helper currently computes strlen(str) and immediately dereferences str[len - 1], which underflows when the body is empty and not closed with double-quotation. Reject empty non-closed immediate strings before checking for the closing quote. Link: https://lore.kernel.org/all/20260401160315.88518-1-pengpeng@iscas.ac.cn/ Fixes: a42e3c4de964 ("tracing/probe: Add immediate string parameter support") Signed-off-by: Pengpeng Hou Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 06fbff5577a0dcab06b48ca028c8c3bf6e195af9 Author: Jon Hunter Date: Wed Apr 1 11:29:40 2026 +0100 dt-bindings: net: Fix Tegra234 MGBE PTP clock [ Upstream commit fb22b1fc5bca3c0aad95388933497ceb30f1fb26 ] The PTP clock for the Tegra234 MGBE device is incorrectly named 'ptp-ref' and should be 'ptp_ref'. This is causing the following warning to be observed on Tegra234 platforms that use this device: ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed Although this constitutes an ABI breakage in the binding for this device, PTP support has clearly never worked and so fix this now so we can correct the device-tree for this device. Note that the MGBE driver still supports the legacy 'ptp-ref' clock name and so older/existing device-trees will still work, but given that this is not the correct name, there is no point to advertise this in the binding. Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE") Signed-off-by: Jon Hunter Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260401102941.17466-3-jonathanh@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e4ab0fd1c91882f2a7846b1817781c8741f7f315 Author: Pengpeng Hou Date: Thu Apr 2 12:21:48 2026 +0800 nfc: s3fwrn5: allocate rx skb before consuming bytes [ Upstream commit 5c14a19d5b1645cce1cb1252833d70b23635b632 ] s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. Fixes: 3f52c2cb7e3a ("nfc: s3fwrn5: Support a UART interface") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260402042148.65236-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc5db4db19766a61ad65d81d1f55b1c1e51ba78d Author: Yiqi Sun Date: Thu Apr 2 15:04:19 2026 +0800 ipv4: icmp: fix null-ptr-deref in icmp_build_probe() [ Upstream commit fde29fd9349327acc50d19a0b5f3d5a6c964dfd8 ] ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface". Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") Signed-off-by: Yiqi Sun Link: https://patch.msgid.link/20260402070419.2291578-1-sunyiqixm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a10570973619cba9dfa6d723177251b846fae587 Author: Eric Dumazet Date: Thu Apr 2 10:35:19 2026 +0000 net: lapbether: handle NETDEV_PRE_TYPE_CHANGE [ Upstream commit b120e4432f9f56c7103133d6a11245e617695adb ] lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation. Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER") Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Martin Schiller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260402103519.1201565-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46c07ad50fa2f4ba7663ee1b72b75ad7ad45cf09 Author: Ruide Cao Date: Thu Apr 2 22:46:20 2026 +0800 net: sched: act_csum: validate nested VLAN headers [ Upstream commit c842743d073bdd683606cb414eb0ca84465dd834 ] tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path. Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a6d57084372161f86660bc4607784420e00efe2c Author: Nicholas Carlini Date: Tue Mar 31 15:25:32 2026 +0200 eventpoll: defer struct eventpoll free to RCU grace period [ Upstream commit 07712db80857d5d09ae08f3df85a708ecfc3b61f ] In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF. Fixes: f2e467a48287 ("eventpoll: Fix semi-unbounded recursion") Signed-off-by: Nicholas Carlini Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a1f93804449d13f97dabd4b996817de4bf1ed67a Author: Paolo Abeni Date: Wed Mar 22 17:57:02 2023 +0100 epoll: use refcount to reduce ep_mutex contention [ Upstream commit 58c9b016e12855286370dfb704c08498edbc857a ] We are observing huge contention on the epmutex during an http connection/rate test: 83.17% 0.25% nginx [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe [...] |--66.96%--__fput |--60.04%--eventpoll_release_file |--58.41%--__mutex_lock.isra.6 |--56.56%--osq_lock The application is multi-threaded, creates a new epoll entry for each incoming connection, and does not delete it before the connection shutdown - that is, before the connection's fd close(). Many different threads compete frequently for the epmutex lock, affecting the overall performance. To reduce the contention this patch introduces explicit reference counting for the eventpoll struct. Each registered event acquires a reference, and references are released at ep_remove() time. The eventpoll struct is released by whoever - among EP file close() and and the monitored file close() drops its last reference. Additionally, this introduces a new 'dying' flag to prevent races between the EP file close() and the monitored file close(). ep_eventpoll_release() marks, under f_lock spinlock, each epitem as dying before removing it, while EP file close() does not touch dying epitems. The above is needed as both close operations could run concurrently and drop the EP reference acquired via the epitem entry. Without the above flag, the monitored file close() could reach the EP struct via the epitem list while the epitem is still listed and then try to put it after its disposal. An alternative could be avoiding touching the references acquired via the epitems at EP file close() time, but that could leave the EP struct alive for potentially unlimited time after EP file close(), with nasty side effects. With all the above in place, we can drop the epmutex usage at disposal time. Overall this produces a significant performance improvement in the mentioned connection/rate scenario: the mutex operations disappear from the topmost offenders in the perf report, and the measured connections/rate grows by ~60%. To make the change more readable this additionally renames ep_free() to ep_clear_and_put(), and moves the actual memory cleanup in a separate ep_free() helper. Link: https://lkml.kernel.org/r/4a57788dcaf28f5eb4f8dfddcc3a8b172a7357bb.1679504153.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Co-developed-by: Eric Dumazet Signed-off-by: Eric Dumazet Tested-by: Xiumei Mu Acked-by: Soheil Hassas Yeganeh Reviewed-by: Davidlohr Bueso Cc: Alexander Viro Cc: Carlos Maiolino Cc: Christian Brauner Cc: Eric Biggers Cc: Jacob Keller Cc: Jens Axboe Signed-off-by: Andrew Morton Stable-dep-of: 07712db80857 ("eventpoll: defer struct eventpoll free to RCU grace period") Signed-off-by: Sasha Levin commit 4fd016be1e4977f90cd704de5bf55c5d6cd5e176 Author: Maíra Canal Date: Mon Mar 30 14:51:46 2026 -0300 drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock [ Upstream commit 338c56050d8e892604da97f67bfa8cc4015a955f ] The mmap callback reads bo->madv without holding madv_lock, racing with concurrent DRM_IOCTL_VC4_GEM_MADVISE calls that modify the field under the same lock. Add the missing locking to prevent the data race. Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-4-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 259e2bba3fd7005c62cbd42365a48b3221b244e3 Author: Maíra Canal Date: Mon Mar 30 14:51:45 2026 -0300 drm/vc4: Fix a memory leak in hang state error path [ Upstream commit 9525d169e5fd481538cf8c663cc5839e54f2e481 ] When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place. Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-3-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 9c092941fc1d00933bcb46ecac1cb930db3abf5d Author: Maíra Canal Date: Mon Mar 30 14:51:44 2026 -0300 drm/vc4: Fix memory leak of BO array in hang state [ Upstream commit f4dfd6847b3e5d24e336bca6057485116d17aea4 ] The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct. Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-2-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 6ad2d5f58f71cb8eac8db31c69a981e1769cb384 Author: Maíra Canal Date: Mon Mar 30 14:51:43 2026 -0300 drm/vc4: Release runtime PM reference after binding V3D [ Upstream commit aaefbdde9abdc43699e110679c0e10972a5e1c59 ] The vc4_v3d_bind() function acquires a runtime PM reference via pm_runtime_resume_and_get() to access V3D registers during setup. However, this reference is never released after a successful bind. This prevents the device from ever runtime suspending, since the reference count never reaches zero. Release the runtime PM reference by adding pm_runtime_put_autosuspend() after autosuspend is configured, allowing the device to runtime suspend after the delay. Fixes: 266cff37d7fc ("drm/vc4: v3d: Rework the runtime_pm setup") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-1-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 54bf34bf7303221febeba37e8343df3d5889b6d2 Author: Long Li Date: Mon Mar 16 14:07:42 2026 -0700 PCI: hv: Set default NUMA node to 0 for devices without affinity info [ Upstream commit 7b3b1e5a87b2f5e35c52b5386d7c327be869454f ] When hv_pci_assign_numa_node() processes a device that does not have HV_PCI_DEVICE_FLAG_NUMA_AFFINITY set or has an out-of-range virtual_numa_node, the device NUMA node is left unset. On x86_64, the uninitialized default happens to be 0, but on ARM64 it is NUMA_NO_NODE (-1). Tests show that when no NUMA information is available from the Hyper-V host, devices perform best when assigned to node 0. With NUMA_NO_NODE the kernel may spread work across NUMA nodes, which degrades performance on Hyper-V, particularly for high-throughput devices like MANA. Always set the device NUMA node to 0 before the conditional NUMA affinity check, so that devices get a performant default when the host provides no NUMA information, and behavior is consistent on both x86_64 and ARM64. Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2") Signed-off-by: Long Li Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 928f9a65b9efd714aec04872e78b8657aa82fe62 Author: Sebastian Krzyszkowiak Date: Wed Jan 28 00:28:28 2026 +0100 arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency [ Upstream commit 1f99b5d93d99ca17d50b386a674d0ce1f20932d8 ] According to i.MX 8M Quad Reference Manual, GPU_AHB_CLK_ROOT's maximum frequency is 400MHz. Fixes: 45d2c84eb3a2 ("arm64: dts: imx8mq: add GPU node") Reviewed-by: Frank Li Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Peng Fan Reviewed-by: Fabio Estevam Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 192beb1bb82e2bef11c304daec561985b7b81115 Author: Potin Lai Date: Thu Jan 22 16:37:56 2026 +0800 soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching [ Upstream commit 7ec1bd3d9be671d04325b9e06149b8813f6a4836 ] The siliconid_to_name() function currently masks the input silicon ID with 0xff00ffff, but compares it against unmasked table entries. This causes matching to fail if the table entries contain non-zero values in the bits covered by the mask (bits 16-23). Update the logic to apply the 0xff00ffff mask to the table entries during comparison. This ensures that only the relevant model and revision bits are considered, providing a consistent match across different manufacturing batches. [arj: Add Fixes: tag, fix 'soninfo' typo, clarify function reference] Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver") Signed-off-by: Potin Lai Link: https://patch.msgid.link/20260122-soc_aspeed_name_fix-v1-1-33a847f2581c@gmail.com Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit aefc672eb23452c85d5972fc3aa2fe167c812775 Author: Tomasz Merta Date: Wed Apr 8 10:40:56 2026 +0200 ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J [ Upstream commit 0669631dbccd41cf3ca7aa70213fcd8bb41c4b38 ] The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A, DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK edge when SND_SOC_DAIFMT_NB_NF is used. Per ALSA convention, NB_NF requires sampling on the rising BCLK edge. The STM32MP25 SAI reference manual states that CKSTR=1 is required for signals received by the SAI to be sampled on the SCK rising edge. Without setting CKSTR=1, the SAI samples on the falling edge, violating the NB_NF convention. For comparison, the NXP FSL SAI driver correctly sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its I2S handling. This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec. RIGHT_J (LSB) is not investigated and addressed by this patch. Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified and is left for a separate investigation. Signed-off-by: Tomasz Merta Link: https://patch.msgid.link/20260408084056.20588-1-tommerta@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9c81bcc2c695e0082012a2a3d36a0eefaa51579c Author: Pengpeng Hou Date: Mon Mar 23 15:45:51 2026 +0800 wifi: brcmfmac: validate bsscfg indices in IF events [ Upstream commit 304950a467d83678bd0b0f46331882e2ac23b12d ] brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. Signed-off-by: Pengpeng Hou Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn [add missing wifi prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7cf071a0dadd0f894f4dc85eb67d432346405c3d Author: Arthur Husband Date: Mon Apr 6 15:23:35 2026 -0700 ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585 [ Upstream commit 105c42566a550e2d05fc14f763216a8765ee5d0e ] The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA support via the S64A bit in the AHCI CAP register, but their 64-bit DMA implementation is defective. Under sustained I/O, DMA transfers targeting addresses above 4GB silently corrupt data -- writes land at incorrect memory addresses with no errors logged. The failure pattern is similar to the ASMedia ASM1061 (commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers")), which also falsely advertised full 64-bit DMA support. However, the JMB585 requires a stricter 32-bit DMA mask rather than 43-bit, as corruption occurs with any address above 4GB. On the Minisforum N5 Pro specifically, the combination of the JMB585's broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes silent data corruption that is only detectable via checksumming filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA space is exhausted and the kernel transparently switches to 64-bit DMA addresses. Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585 (0x0585) before the generic JMicron class match, using a new board type that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior) with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks. Signed-off-by: Arthur Husband Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 181ea51ab0f6370842c5b49cfb86824253a1189e Author: Benoît Sevens Date: Mon Mar 23 16:11:07 2026 +0000 HID: roccat: fix use-after-free in roccat_report_event [ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ] roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex. Signed-off-by: Benoît Sevens Reviewed-by: Silvan Jegen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 72353518489742b979d4a761b0b7ee8628df8503 Author: songxiebing Date: Sun Apr 5 09:26:51 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10 [ Upstream commit f0541edb2e7333f320642c7b491a67912c1f65db ] The bass speakers are not working, and add the following entry in /etc/modprobe.d/snd.conf: options snd-sof-intel-hda-generic hda_model=alc287-yoga9-bass-spk-pin Fixes the bass speakers. So add the quick ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN here. Reported-by: Fernando Garcia Corona Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221317 Signed-off-by: songxiebing Link: https://patch.msgid.link/20260405012651.133838-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c330fbd4628fbdb8759004a7714517487c2c5d4 Author: leo vriska Date: Wed Mar 4 13:36:59 2026 -0500 HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 [ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ] According to a mailing list report [1], this controller's predecessor has the same issue. However, it uses the xpad driver instead of HID, so this quirk wouldn't apply. [1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/ Signed-off-by: leo vriska Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f074819e47b5af2f8c8f709fb501fa23da94df56 Author: Andy Shevchenko Date: Wed Mar 11 18:14:04 2026 +0100 pinctrl: intel: Fix the revision for new features (1kOhm PD, HW debouncer) [ Upstream commit a4337a24d13e9e3b98a113e71d6b80dc5ed5f8c4 ] The 1kOhm pull down and hardware debouncer are features of the revision 0.92 of the Chassis specification. Fix that in the code accordingly. Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit bb35ba4d79c0d37210c2347b6121df565c1d90a8 Author: Gilson Marquato Júnior Date: Mon Mar 30 02:43:48 2026 +0100 ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx [ Upstream commit 8ec017cf31299c4b6287ebe27afe81c986aeef88 ] The HP Laptop 15-fc0xxx (subsystem ID 0x103c8dc9) has an internal DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk entry so the internal microphone is properly detected on this model. Tested on HP Laptop 15-fc0237ns with Fedora 43 (kernel 6.19.9). Signed-off-by: Gilson Marquato Júnior Link: https://patch.msgid.link/20260330-hp-15-fc0xxx-dmic-v2-v1-1-6dd6f53a1917@hotmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fbced33599653471b4581dfe1abc7b467031f126 Author: Fredric Cover Date: Mon Mar 30 13:11:27 2026 -0700 fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath [ Upstream commit 78ec5bf2f589ec7fd8f169394bfeca541b077317 ] When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs. Signed-off-by: Fredric Cover Reviewed-by: Henrique Carvalho <[2]henrique.carvalho@suse.com> Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ffe988eb1a4eeb34dd3566a28255329c29228771 Author: Phil Willoughby Date: Sat Mar 28 08:07:34 2026 +0000 ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex [ Upstream commit bc5b4e5ae1a67700a618328217b6a3bd0f296e97 ] The NeuralDSP Quad Cortex does not support DSD playback. We need this product-specific entry with zero quirks because otherwise it falls through to the vendor-specific entry which marks it as supporting DSD playback. Cc: Yue Wang Cc: Jaroslav Kysela Cc: Takashi Iwai Signed-off-by: Phil Willoughby Link: https://patch.msgid.link/20260328080921.3310-1-willerz@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7ebc28c99df2b2620b0f68c545e6057ff674d8a3 Author: Kuninori Morimoto Date: Fri Mar 27 02:43:54 2026 +0000 ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list [ Upstream commit b9eff9732cb0f86a68c9d1592a98ceab47c01e95 ] Component has "card_aux_list" which is added/deled in bind/unbind aux dev function (A), and used in for_each_card_auxs() loop (B). static void soc_unbind_aux_dev(...) { ... for_each_card_auxs_safe(...) { ... (A) list_del(&component->card_aux_list); } ^^^^^^^^^^^^^ } static int soc_bind_aux_dev(...) { ... for_each_card_pre_auxs(...) { ... (A) list_add(&component->card_aux_list, ...); } ^^^^^^^^^^^^^ ... } #define for_each_card_auxs(card, component) \ (B) list_for_each_entry(component, ..., card_aux_list) ^^^^^^^^^^^^^ But it has been used without calling INIT_LIST_HEAD(). > git grep card_aux_list sound/soc sound/soc/soc-core.c: list_del(&component->card_aux_list); sound/soc/soc-core.c: list_add(&component->card_aux_list, ...); call missing INIT_LIST_HEAD() for it. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87341mxa8l.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e0dc1ad870d6788b049bfe1511ac75b2333a7550 Author: Pengpeng Hou Date: Mon Mar 23 16:08:45 2026 +0800 wifi: wl1251: validate packet IDs before indexing tx_frames [ Upstream commit 0fd56fad9c56356e7fa7a7c52e7ecbf807a44eb0 ] wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260323080845.40033-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f742710bb7b4b57c6de7bb0e4140f5d7faf2b88b Author: Dustin L. Howett Date: Fri Mar 27 10:54:40 2026 -0500 ALSA: hda/realtek: add quirk for Framework F111:000F [ Upstream commit bac1e57adf08c9ee33e95fb09cd032f330294e70 ] Similar to commit 7b509910b3ad ("ALSA hda/realtek: Add quirk for Framework F111:000C") and previous quirks for Framework systems with Realtek codecs. 000F is another new platform with an ALC285 which needs the same quirk. Signed-off-by: Dustin L. Howett Link: https://patch.msgid.link/20260327-framework-alsa-000f-v1-1-74013aba1c00@howett.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1c43f0dd8691ddf8884793b481ddc7511cf593c3 Author: Florian Westphal Date: Wed Mar 25 14:10:55 2026 +0100 netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry [ Upstream commit d3c0037ffe1273fa1961e779ff6906234d6cf53c ] New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map. Link: https://lore.kernel.org/netfilter-devel/20260321152506.037f68c0@elisabeth/ Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 455f2ec83aa801b79cd72429356c49874c34fedb Author: César Montoya Date: Sat Mar 21 10:36:03 2026 -0500 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx [ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ] The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly, but the subsystem ID was missing from the quirk table. GPIO pin confirmed via manual hda-verb testing: hda-verb SET_GPIO_MASK 0x10 hda-verb SET_GPIO_DIRECTION 0x10 hda-verb SET_GPIO_DATA 0x10 Signed-off-by: César Montoya Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e252db8ca2a01f82d472091f35d549b313278636 Author: Goldwyn Rodrigues Date: Fri Mar 13 14:11:39 2026 -0400 btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() [ Upstream commit a85b46db143fda5869e7d8df8f258ccef5fa1719 ] If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb. Reviewed-by: Boris Burkov Signed-off-by: Goldwyn Rodrigues Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c78782a4c951bdf8e464b9895ddfce6a5d8cbed3 Author: Wenyuan Li <2063309626@qq.com> Date: Mon Mar 16 00:00:22 2026 +0800 can: mcp251x: add error handling for power enable in open and resume [ Upstream commit 7a57354756c7df223abe2c33774235ad70cb4231 ] Add missing error handling for mcp251x_power_enable() calls in both mcp251x_open() and mcp251x_can_resume() functions. In mcp251x_open(), if power enable fails, jump to error path to close candev without attempting to disable power again. In mcp251x_can_resume(), properly check return values of power enable calls for both power and transceiver regulators. If any fails, return the error code to the PM framework and log the failure. This ensures the driver properly handles power control failures and maintains correct device state. Signed-off-by: Wenyuan Li <2063309626@qq.com> Link: https://patch.msgid.link/tencent_F3EFC5D7738AC548857B91657715E2D3AA06@qq.com [mkl: fix patch description] [mkl: mcp251x_can_resume(): replace goto by return] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit d36e27b59caf06504d33a6d0701bc42728820144 Author: Zhang Heng Date: Mon Mar 16 16:02:18 2026 +0800 ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF [ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ] Add a DMI quirk for the Thin A15 B7VF fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 101660a044b950ff9144a2a145565448f7b123b7 Author: Arnd Bergmann Date: Wed Mar 18 13:40:07 2026 +0100 ALSA: asihpi: avoid write overflow check warning [ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ] clang-22 rightfully warns that the memcpy() in adapter_prepare() copies between different structures, crossing the boundary of nested structures inside it: In file included from sound/pci/asihpi/hpimsgx.c:13: In file included from include/linux/string.h:386: include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 569 | __write_overflow_field(p_size_field, size); The two structures seem to refer to the same layout, despite the separate definitions, so the code is in fact correct. Avoid the warning by copying the two inner structures separately. I see the same pattern happens in other functions in the same file, so there is a chance that this may come back in the future, but this instance is the only one that I saw in practice, hitting it multiple times per day in randconfig build. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5165c725b4221283b39aeddd5f8e21a0c0ecc017 Author: Arnd Bergmann Date: Mon Feb 2 10:47:51 2026 +0100 media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl() [ Upstream commit c03b7dec3c4ddc97872fa12bfca75bae9cb46510 ] The deeply nested loop in rkvdec_init_v4l2_vp9_count_tbl() needs a lot of registers, so when the clang register allocator runs out, it ends up spilling countless temporaries to the stack: drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c:966:12: error: stack frame size (1472) exceeds limit (1280) in 'rkvdec_vp9_start' [-Werror,-Wframe-larger-than] Marking this function as noinline_for_stack keeps it out of rkvdec_vp9_start(), giving the compiler more room for optimization. The resulting code is good enough that both the total stack usage and the loop get enough better to stay under the warning limit, though it's still slow, and would need a larger rework if this function ends up being called in a fast path. Signed-off-by: Arnd Bergmann Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8e75f5c828c2e869bfe78fb1e453c2005180f187 Author: Andrii Kovalchuk Date: Sun Mar 15 01:08:51 2026 +0000 ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk [ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ] Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756) to enable proper mute LED and mic mute behavior using the ALC245_FIXUP_HP_X360_MUTE_LEDS fixup. Signed-off-by: Andrii Kovalchuk Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 552c36f6aa74f39b57f8eb24e1c7fe94387475b6 Author: Vee Satayamas Date: Sun Mar 15 21:25:12 2026 +0700 ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA [ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ] Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the internal microphone not being detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236 Signed-off-by: Vee Satayamas Reviewed-by: Zhang Heng Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin