From: Greg Kroah-Hartman Date: Tue, 12 May 2026 14:30:13 +0000 (+0200) Subject: 6.12-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e7d27db710d444d814ceb264e55aa21d8d1b02cf;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch mptcp-fastclose-msk-when-linger-time-is-0.patch mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch pci-aer-clear-only-error-bits-in-pcie-device-status.patch pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch power-supply-max17042-avoid-overflow-when-determining-health.patch rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch rdma-mana-validate-rx_hash_key_len.patch rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch selftests-mptcp-check-output-catch-cmd-errors.patch selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch --- diff --git a/queue-6.12/f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch b/queue-6.12/f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch new file mode 100644 index 0000000000..fbaf3e2e7c --- /dev/null +++ b/queue-6.12/f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch @@ -0,0 +1,38 @@ +From 5471834a96fb697874be2ca0b052e74bcf3c23d1 Mon Sep 17 00:00:00 2001 +From: Cen Zhang +Date: Wed, 18 Mar 2026 15:32:53 +0800 +Subject: f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode() + +From: Cen Zhang + +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 +--- + fs/f2fs/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/f2fs/inode.c ++++ b/fs/f2fs/inode.c +@@ -663,7 +663,7 @@ void f2fs_update_inode(struct inode *ino + ri->i_uid = cpu_to_le32(i_uid_read(inode)); + ri->i_gid = cpu_to_le32(i_gid_read(inode)); + ri->i_links = cpu_to_le32(inode->i_nlink); +- ri->i_blocks = cpu_to_le64(SECTOR_TO_BLOCK(inode->i_blocks) + 1); ++ ri->i_blocks = cpu_to_le64(SECTOR_TO_BLOCK(READ_ONCE(inode->i_blocks)) + 1); + + if (!f2fs_is_atomic_file(inode) || + is_inode_flag_set(inode, FI_ATOMIC_COMMITTED)) diff --git a/queue-6.12/f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch b/queue-6.12/f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch new file mode 100644 index 0000000000..b413c8fc56 --- /dev/null +++ b/queue-6.12/f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch @@ -0,0 +1,99 @@ +From 95e159ad3e52f7478cfd22e44ec37c9f334f8993 Mon Sep 17 00:00:00 2001 +From: Yongpeng Yang +Date: Mon, 23 Mar 2026 20:06:24 +0800 +Subject: f2fs: fix fiemap boundary handling when read extent cache is incomplete +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Yongpeng Yang + +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 +--- + fs/f2fs/data.c | 25 ++++++++++++++++++++++--- + 1 file changed, 22 insertions(+), 3 deletions(-) + +--- a/fs/f2fs/data.c ++++ b/fs/f2fs/data.c +@@ -1564,8 +1564,26 @@ int f2fs_map_blocks(struct inode *inode, + if (!maxblocks) + return 0; + +- if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag)) +- goto out; ++ if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag)) { ++ struct extent_info ei; ++ ++ /* ++ * 1. If map->m_multidev_dio is true, map->m_pblk cannot be ++ * waitted by f2fs_wait_on_block_writeback_range() and are not ++ * mergeable. ++ * 2. If pgofs hits the read extent cache, it means the mapping ++ * is already cached in the extent cache, but it is not ++ * mergeable, and there is no need to query the mapping again ++ * via f2fs_get_dnode_of_data(). ++ */ ++ pgofs = (pgoff_t)map->m_lblk + map->m_len; ++ if (map->m_len == maxblocks || ++ map->m_multidev_dio || ++ f2fs_lookup_read_extent_cache(inode, pgofs, &ei)) ++ goto out; ++ ofs = map->m_len; ++ goto map_more; ++ } + + map->m_bdev = inode->i_sb->s_bdev; + map->m_multidev_dio = +@@ -1576,7 +1594,8 @@ int f2fs_map_blocks(struct inode *inode, + + /* it only supports block size == page size */ + pgofs = (pgoff_t)map->m_lblk; +- end = pgofs + maxblocks; ++map_more: ++ end = (pgoff_t)map->m_lblk + maxblocks; + + next_dnode: + if (map->m_may_create) { diff --git a/queue-6.12/f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch b/queue-6.12/f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch new file mode 100644 index 0000000000..7f878cec6c --- /dev/null +++ b/queue-6.12/f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch @@ -0,0 +1,38 @@ +From eb2ca3ca983551a80e16a4a25df5a4ce59df8484 Mon Sep 17 00:00:00 2001 +From: Yongpeng Yang +Date: Mon, 23 Mar 2026 20:06:22 +0800 +Subject: f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks() + +From: Yongpeng Yang + +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 +--- + fs/f2fs/data.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/f2fs/data.c ++++ b/fs/f2fs/data.c +@@ -1509,7 +1509,8 @@ static bool f2fs_map_blocks_cached(struc + f2fs_wait_on_block_writeback_range(inode, + map->m_pblk, map->m_len); + +- if (f2fs_allow_multi_device_dio(sbi, flag)) { ++ map->m_multidev_dio = f2fs_allow_multi_device_dio(sbi, flag); ++ if (map->m_multidev_dio) { + int bidx = f2fs_target_device_index(sbi, map->m_pblk); + struct f2fs_dev_info *dev = &sbi->devs[bidx]; + diff --git a/queue-6.12/f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch b/queue-6.12/f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch new file mode 100644 index 0000000000..c301b74323 --- /dev/null +++ b/queue-6.12/f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch @@ -0,0 +1,93 @@ +From ed78aeebef05212ef7dca93bd931e4eff67c113f Mon Sep 17 00:00:00 2001 +From: Yongpeng Yang +Date: Fri, 3 Apr 2026 22:40:17 +0800 +Subject: f2fs: fix node_cnt race between extent node destroy and writeback + +From: Yongpeng Yang + +commit ed78aeebef05212ef7dca93bd931e4eff67c113f upstream. + +f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing +extent nodes. When called from f2fs_drop_inode() with I_SYNC set, +concurrent kworker writeback can insert new extent nodes into the same +extent tree, racing with the destroy and triggering f2fs_bug_on() in +__destroy_extent_node(). The scenario is as follows: + +drop inode writeback + - iput + - f2fs_drop_inode // I_SYNC set + - f2fs_destroy_extent_node + - __destroy_extent_node + - while (node_cnt) { + write_lock(&et->lock) + __free_extent_tree + write_unlock(&et->lock) + - __writeback_single_inode + - f2fs_outplace_write_data + - f2fs_update_read_extent_cache + - __update_extent_tree_range + // FI_NO_EXTENT not set, + // insert new extent node + } // node_cnt == 0, exit while + - f2fs_bug_on(node_cnt) // node_cnt > 0 + +Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for +EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected. + +This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(), +consistent with other callers (__update_extent_tree_range and +__drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and +EX_BLOCK_AGE tree. + +Fixes: 3fc5d5a182f6 ("f2fs: fix to shrink read extent node in batches") +Cc: stable@vger.kernel.org +Signed-off-by: Yongpeng Yang +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman +--- + fs/f2fs/extent_cache.c | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/fs/f2fs/extent_cache.c ++++ b/fs/f2fs/extent_cache.c +@@ -86,9 +86,10 @@ static bool __may_extent_tree(struct ino + if (!__init_may_extent_tree(inode, type)) + return false; + ++ if (is_inode_flag_set(inode, FI_NO_EXTENT)) ++ return false; ++ + if (type == EX_READ) { +- if (is_inode_flag_set(inode, FI_NO_EXTENT)) +- return false; + if (is_inode_flag_set(inode, FI_COMPRESSED_FILE) && + !f2fs_sb_has_readonly(F2FS_I_SB(inode))) + return false; +@@ -601,6 +602,8 @@ static unsigned int __destroy_extent_nod + + while (atomic_read(&et->node_cnt)) { + write_lock(&et->lock); ++ if (!is_inode_flag_set(inode, FI_NO_EXTENT)) ++ set_inode_flag(inode, FI_NO_EXTENT); + node_cnt += __free_extent_tree(sbi, et, nr_shrink); + write_unlock(&et->lock); + } +@@ -636,12 +639,12 @@ static void __update_extent_tree_range(s + + write_lock(&et->lock); + +- if (type == EX_READ) { +- if (is_inode_flag_set(inode, FI_NO_EXTENT)) { +- write_unlock(&et->lock); +- return; +- } ++ if (is_inode_flag_set(inode, FI_NO_EXTENT)) { ++ write_unlock(&et->lock); ++ return; ++ } + ++ if (type == EX_READ) { + prev = et->largest; + dei.len = 0; + diff --git a/queue-6.12/f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch b/queue-6.12/f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch new file mode 100644 index 0000000000..dddbf49755 --- /dev/null +++ b/queue-6.12/f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch @@ -0,0 +1,62 @@ +From b635f2ecdb5ad34f9c967cabb704d6bed9382fd0 Mon Sep 17 00:00:00 2001 +From: Guangshuo Li +Date: Fri, 10 Apr 2026 20:47:26 +0800 +Subject: f2fs: fix uninitialized kobject put in f2fs_init_sysfs() + +From: Guangshuo Li + +commit b635f2ecdb5ad34f9c967cabb704d6bed9382fd0 upstream. + +In f2fs_init_sysfs(), all failure paths after kset_register() jump to +put_kobject, which unconditionally releases both f2fs_tune and +f2fs_feat. + +If kobject_init_and_add(&f2fs_feat, ...) fails, f2fs_tune has not been +initialized yet, so calling kobject_put(&f2fs_tune) is invalid. + +Fix this by splitting the unwind path so each error path only releases +objects that were successfully initialized. + +Fixes: a907f3a68ee26ba4 ("f2fs: add a sysfs entry to reclaim POSIX_FADV_NOREUSE pages") +Cc: stable@vger.kernel.org +Signed-off-by: Guangshuo Li +Reviewed-by: Chao Yu +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman +--- + fs/f2fs/sysfs.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/fs/f2fs/sysfs.c ++++ b/fs/f2fs/sysfs.c +@@ -1795,24 +1795,26 @@ int __init f2fs_init_sysfs(void) + ret = kobject_init_and_add(&f2fs_feat, &f2fs_feat_ktype, + NULL, "features"); + if (ret) +- goto put_kobject; ++ goto unregister_kset; + + ret = kobject_init_and_add(&f2fs_tune, &f2fs_tune_ktype, + NULL, "tuning"); + if (ret) +- goto put_kobject; ++ goto put_feat; + + f2fs_proc_root = proc_mkdir("fs/f2fs", NULL); + if (!f2fs_proc_root) { + ret = -ENOMEM; +- goto put_kobject; ++ goto put_tune; + } + + return 0; + +-put_kobject: ++put_tune: + kobject_put(&f2fs_tune); ++put_feat: + kobject_put(&f2fs_feat); ++unregister_kset: + kset_unregister(&f2fs_kset); + return ret; + } diff --git a/queue-6.12/kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch b/queue-6.12/kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch new file mode 100644 index 0000000000..2fb0a9f94b --- /dev/null +++ b/queue-6.12/kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch @@ -0,0 +1,56 @@ +From 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 Mon Sep 17 00:00:00 2001 +From: Quentin Perret +Date: Fri, 24 Apr 2026 09:49:08 +0100 +Subject: KVM: arm64: Fix initialisation order in __pkvm_init_finalise() + +From: Quentin Perret + +commit 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 upstream. + +fix_host_ownership() walks the hypervisor's stage-1 page-table to +adjust the host's stage-2 accordingly. Any such adjustment that +requires cache maintenance operations depends on the per-CPU hyp +fixmap being present. However, fix_host_ownership() is currently +called before fix_hyp_pgtable_refcnt() and hyp_create_fixmap(), so +the fixmap does not yet exist when it runs. + +This is benign today because the host stage-2 starts empty and no +CMOs are needed, but it becomes a latent crash as soon as +fix_host_ownership() is extended to operate on a non-empty +page-table. + +Reorder the calls so that fix_hyp_pgtable_refcnt() and +hyp_create_fixmap() complete before fix_host_ownership() is invoked. + +Fixes: 0d16d12eb26e ("KVM: arm64: Fix-up hyp stage-1 refcounts for all pages mapped at EL2") +Signed-off-by: Quentin Perret +Signed-off-by: Fuad Tabba +Link: https://patch.msgid.link/20260424084908.370776-7-tabba@google.com +Signed-off-by: Marc Zyngier +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/hyp/nvhe/setup.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/arm64/kvm/hyp/nvhe/setup.c ++++ b/arch/arm64/kvm/hyp/nvhe/setup.c +@@ -307,15 +307,15 @@ void __noreturn __pkvm_init_finalise(voi + }; + pkvm_pgtable.mm_ops = &pkvm_pgtable_mm_ops; + +- ret = fix_host_ownership(); ++ ret = fix_hyp_pgtable_refcnt(); + if (ret) + goto out; + +- ret = fix_hyp_pgtable_refcnt(); ++ ret = hyp_create_pcpu_fixmap(); + if (ret) + goto out; + +- ret = hyp_create_pcpu_fixmap(); ++ ret = fix_host_ownership(); + if (ret) + goto out; + diff --git a/queue-6.12/kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch b/queue-6.12/kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch new file mode 100644 index 0000000000..deb5cea04c --- /dev/null +++ b/queue-6.12/kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch @@ -0,0 +1,54 @@ +From a0e6ae45af17e8b27958830595799c702ffbab8d Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Tue, 7 Apr 2026 21:27:02 +0100 +Subject: KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: David Woodhouse + +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 +--- + arch/arm64/kvm/vgic/vgic-mmio-v2.c | 2 +- + arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/kvm/vgic/vgic-mmio-v2.c ++++ b/arch/arm64/kvm/vgic/vgic-mmio-v2.c +@@ -91,7 +91,7 @@ static int vgic_mmio_uaccess_write_v2_mi + * migration from old kernels to new kernels with legacy + * userspace. + */ +- reg = FIELD_GET(GICD_IIDR_REVISION_MASK, reg); ++ reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val); + switch (reg) { + case KVM_VGIC_IMP_REV_2: + case KVM_VGIC_IMP_REV_3: +--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c ++++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c +@@ -167,7 +167,7 @@ static int vgic_mmio_uaccess_write_v3_mi + if ((reg ^ val) & ~GICD_IIDR_REVISION_MASK) + return -EINVAL; + +- reg = FIELD_GET(GICD_IIDR_REVISION_MASK, reg); ++ reg = FIELD_GET(GICD_IIDR_REVISION_MASK, val); + switch (reg) { + case KVM_VGIC_IMP_REV_2: + case KVM_VGIC_IMP_REV_3: diff --git a/queue-6.12/loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch b/queue-6.12/loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch new file mode 100644 index 0000000000..3908961ff9 --- /dev/null +++ b/queue-6.12/loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch @@ -0,0 +1,103 @@ +From 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e Mon Sep 17 00:00:00 2001 +From: Wentao Guan +Date: Mon, 4 May 2026 09:00:20 +0800 +Subject: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() + +From: Wentao Guan + +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 +--- + arch/loongarch/pci/pci.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/loongarch/pci/pci.c ++++ b/arch/loongarch/pci/pci.c +@@ -133,6 +133,9 @@ static void loongson_gpu_fixup_dma_hang( + crtc_reg = regbase; + crtc_offset = 0x400; + break; ++ default: ++ iounmap(regbase); ++ return; + } + + for (i = 0; i < CRTC_NUM_MAX; i++, crtc_reg += crtc_offset) { diff --git a/queue-6.12/loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch b/queue-6.12/loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch new file mode 100644 index 0000000000..5c2f8737b4 --- /dev/null +++ b/queue-6.12/loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch @@ -0,0 +1,35 @@ +From b3e31a6650d4cab63f0814c37c0b360372c6ee9e Mon Sep 17 00:00:00 2001 +From: Qiang Ma +Date: Mon, 4 May 2026 09:00:37 +0800 +Subject: LoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS + +From: Qiang Ma + +commit b3e31a6650d4cab63f0814c37c0b360372c6ee9e upstream. + +It doesn't make sense to return the recommended maximum number of vCPUs +which exceeds the maximum possible number of vCPUs. + +Other architectures have already done this, such as commit 57a2e13ebdda +("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS") + +Cc: stable@vger.kernel.org +Reviewed-by: Bibo Mao +Signed-off-by: Qiang Ma +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/vm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/kvm/vm.c ++++ b/arch/loongarch/kvm/vm.c +@@ -91,7 +91,7 @@ int kvm_vm_ioctl_check_extension(struct + r = 1; + break; + case KVM_CAP_NR_VCPUS: +- r = num_online_cpus(); ++ r = min_t(unsigned int, num_online_cpus(), KVM_MAX_VCPUS); + break; + case KVM_CAP_MAX_VCPUS: + r = KVM_MAX_VCPUS; diff --git a/queue-6.12/loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch b/queue-6.12/loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch new file mode 100644 index 0000000000..13b6b7478b --- /dev/null +++ b/queue-6.12/loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch @@ -0,0 +1,74 @@ +From 2433f3f5724b3af569d9fb411ba728629524738b Mon Sep 17 00:00:00 2001 +From: Bibo Mao +Date: Mon, 4 May 2026 09:00:48 +0800 +Subject: LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software + +From: Bibo Mao + +commit 2433f3f5724b3af569d9fb411ba728629524738b upstream. + +With passthrough HW timer, timer interrupt is injected by HW. When +inject emulated CPU interrupt by software such SIP0/SIP1/IPI, HW timer +interrupt may be lost. + +Here check whether there is timer tick value inversion before and after +injecting emulated CPU interrupt by software, timer enabling by reading +timer cfg register is skipped. If the timer tick value is detected with +changing, then timer should be enabled. And inject a timer interrupt by +software if there is. + +Cc: +Fixes: f45ad5b8aa93 ("LoongArch: KVM: Implement vcpu interrupt operations"). +Signed-off-by: Bibo Mao +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/interrupt.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/arch/loongarch/kvm/interrupt.c ++++ b/arch/loongarch/kvm/interrupt.c +@@ -26,6 +26,7 @@ static unsigned int priority_to_irq[EXCC + static int kvm_irq_deliver(struct kvm_vcpu *vcpu, unsigned int priority) + { + unsigned int irq = 0; ++ unsigned long old, new; + + clear_bit(priority, &vcpu->arch.irq_pending); + if (priority < EXCCODE_INT_NUM) +@@ -36,7 +37,13 @@ static int kvm_irq_deliver(struct kvm_vc + case INT_IPI: + case INT_SWI0: + case INT_SWI1: ++ old = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL); + set_gcsr_estat(irq); ++ new = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL); ++ ++ /* Inject TI if TVAL inverted */ ++ if (new > old) ++ set_gcsr_estat(CPU_TIMER); + break; + + case INT_HWI0 ... INT_HWI7: +@@ -53,6 +60,7 @@ static int kvm_irq_deliver(struct kvm_vc + static int kvm_irq_clear(struct kvm_vcpu *vcpu, unsigned int priority) + { + unsigned int irq = 0; ++ unsigned long old, new; + + clear_bit(priority, &vcpu->arch.irq_clear); + if (priority < EXCCODE_INT_NUM) +@@ -63,7 +71,13 @@ static int kvm_irq_clear(struct kvm_vcpu + case INT_IPI: + case INT_SWI0: + case INT_SWI1: ++ old = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL); + clear_gcsr_estat(irq); ++ new = kvm_read_hw_gcsr(LOONGARCH_CSR_TVAL); ++ ++ /* Inject TI if TVAL inverted */ ++ if (new > old) ++ set_gcsr_estat(CPU_TIMER); + break; + + case INT_HWI0 ... INT_HWI7: diff --git a/queue-6.12/loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch b/queue-6.12/loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch new file mode 100644 index 0000000000..03593353b7 --- /dev/null +++ b/queue-6.12/loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch @@ -0,0 +1,34 @@ +From b323a441da602dfdfc24f30d3190cac786ffebf2 Mon Sep 17 00:00:00 2001 +From: Xianglai Li +Date: Mon, 4 May 2026 09:00:37 +0800 +Subject: LoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry + +From: Xianglai Li + +commit b323a441da602dfdfc24f30d3190cac786ffebf2 upstream. + +Insert the appropriate UNWIND hint into the kvm_exc_entry assembly +function to guide the generation of correct ORC table entries, thereby +solving the timeout problem ("unreliable stack") while loading the +livepatch-sample module on a physical machine running virtual machines +with multiple vcpus. + +Cc: stable@vger.kernel.org +Signed-off-by: Xianglai Li +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/switch.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/kvm/switch.S ++++ b/arch/loongarch/kvm/switch.S +@@ -112,7 +112,7 @@ + .text + .cfi_sections .debug_frame + SYM_CODE_START(kvm_exc_entry) +- UNWIND_HINT_UNDEFINED ++ UNWIND_HINT_END_OF_STACK + csrwr a2, KVM_TEMP_KS + csrrd a2, KVM_VCPU_KS + addi.d a2, a2, KVM_VCPU_ARCH diff --git a/queue-6.12/loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch b/queue-6.12/loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch new file mode 100644 index 0000000000..bc4028643f --- /dev/null +++ b/queue-6.12/loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch @@ -0,0 +1,59 @@ +From 5a873d77ba792410a796595a917be6a440f9b7d2 Mon Sep 17 00:00:00 2001 +From: Bibo Mao +Date: Mon, 4 May 2026 09:00:48 +0800 +Subject: LoongArch: KVM: Move unconditional delay into timer clear scenery + +From: Bibo Mao + +commit 5a873d77ba792410a796595a917be6a440f9b7d2 upstream. + +When timer interrupt arrives in guest kernel, guest kernel clears the +timer interrupt and program timer with the next incoming event. + +During this stage, timer tick is -1 and timer interrupt status is +disabled in ESTAT register. KVM hypervisor need write zero with timer +tick register and wait timer interrupt injection from HW side, and +then clear timer interrupt. + +So there is 2 cycle delay in KVM hypervisor to emulate such scenery, +and the delay is unnecessary if there is no need to clear the timer +interrupt. + +Here move 2 cycle delay into timer clear scenery and add timer ESTAT +checking after delay, and set max timer expire value if timer interrupt +does not arrive still. + +Cc: stable@vger.kernel.org +Signed-off-by: Bibo Mao +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/timer.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/arch/loongarch/kvm/timer.c ++++ b/arch/loongarch/kvm/timer.c +@@ -96,15 +96,21 @@ void kvm_restore_timer(struct kvm_vcpu * + * and set CSR TVAL with -1 + */ + write_gcsr_timertick(0); +- __delay(2); /* Wait cycles until timer interrupt injected */ + + /* + * Writing CSR_TINTCLR_TI to LOONGARCH_CSR_TINTCLR will clear + * timer interrupt, and CSR TVAL keeps unchanged with -1, it + * avoids spurious timer interrupt + */ +- if (!(estat & CPU_TIMER)) ++ if (!(estat & CPU_TIMER)) { ++ __delay(2); /* Wait cycles until timer interrupt injected */ ++ ++ /* Write TVAL with max value if no TI shot */ ++ estat = kvm_read_hw_gcsr(LOONGARCH_CSR_ESTAT); ++ if (!(estat & CPU_TIMER)) ++ write_gcsr_timertick(CSR_TCFG_VAL); + gcsr_write(CSR_TINTCLR_TI, LOONGARCH_CSR_TINTCLR); ++ } + return; + } + diff --git a/queue-6.12/loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch b/queue-6.12/loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch new file mode 100644 index 0000000000..9e56f56ddc --- /dev/null +++ b/queue-6.12/loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch @@ -0,0 +1,35 @@ +From 81e18777d61440511451866c7c80b34a8bdd6b33 Mon Sep 17 00:00:00 2001 +From: Tao Cui +Date: Mon, 4 May 2026 09:00:38 +0800 +Subject: LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte() + +From: Tao Cui + +commit 81e18777d61440511451866c7c80b34a8bdd6b33 upstream. + +kvm_flush_pte() is the only caller that directly assigns *pte instead +of using the kvm_set_pte() wrapper. Use the wrapper for consistency with +the rest of the file. + +No functional change intended. + +Cc: stable@vger.kernel.org +Reviewed-by: Bibo Mao +Signed-off-by: Tao Cui +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kvm/mmu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/kvm/mmu.c ++++ b/arch/loongarch/kvm/mmu.c +@@ -95,7 +95,7 @@ static int kvm_flush_pte(kvm_pte_t *pte, + else + kvm->stat.pages--; + +- *pte = ctx->invalid_entry; ++ kvm_set_pte(pte, ctx->invalid_entry); + + return 1; + } diff --git a/queue-6.12/loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch b/queue-6.12/loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch new file mode 100644 index 0000000000..2ed5a06420 --- /dev/null +++ b/queue-6.12/loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch @@ -0,0 +1,58 @@ +From 49f33840dcc907d21313d369e34872880846b61c Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Mon, 4 May 2026 09:00:20 +0800 +Subject: LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup + +From: Huacai Chen + +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 +--- + arch/loongarch/pci/acpi.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/loongarch/pci/acpi.c ++++ b/arch/loongarch/pci/acpi.c +@@ -61,11 +61,16 @@ static void acpi_release_root_info(struc + static int acpi_prepare_root_resources(struct acpi_pci_root_info *ci) + { + int status; ++ unsigned long long pci_h = 0; + struct resource_entry *entry, *tmp; + struct acpi_device *device = ci->bridge; + + status = acpi_pci_probe_root_resources(ci); + if (status > 0) { ++ acpi_evaluate_integer(device->handle, "PCIH", NULL, &pci_h); ++ if (pci_h) ++ return status; ++ + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) { + if (entry->res->flags & IORESOURCE_MEM) { + entry->offset = ci->root->mcfg_addr & GENMASK_ULL(63, 40); diff --git a/queue-6.12/mptcp-fastclose-msk-when-linger-time-is-0.patch b/queue-6.12/mptcp-fastclose-msk-when-linger-time-is-0.patch new file mode 100644 index 0000000000..cffe2de97e --- /dev/null +++ b/queue-6.12/mptcp-fastclose-msk-when-linger-time-is-0.patch @@ -0,0 +1,51 @@ +From f14d6e9c3678a067f304abba561e0c5446c7e845 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Mon, 27 Apr 2026 21:54:35 +0200 +Subject: mptcp: fastclose msk when linger time is 0 + +From: Matthieu Baerts (NGI0) + +commit f14d6e9c3678a067f304abba561e0c5446c7e845 upstream. + +The SO_LINGER socket option has been supported for a while with MPTCP +sockets [1], but it didn't cause the equivalent of a TCP reset as +expected when enabled and its time was set to 0. This was causing some +behavioural differences with TCP where some connections were not +promptly stopped as expected. + +To fix that, an extra condition is checked at close() time before +sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset. + +Note that backporting up to [1] will be difficult as more changes are +needed to be able to send MP_FASTCLOSE. It seems better to stop at [2], +which was supposed to already imitate TCP. + +Validated with MPTCP packetdrill tests [3]. + +Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1] +Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2] +Cc: stable@vger.kernel.org +Reported-by: Lance Tuller +Closes: https://github.com/lance0/xfr/pull/67 +Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3] +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-3-7432b7f279fa@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -3219,7 +3219,8 @@ bool __mptcp_close(struct sock *sk, long + goto cleanup; + } + +- if (mptcp_data_avail(msk) || timeout < 0) { ++ if (mptcp_data_avail(msk) || timeout < 0 || ++ (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime)) { + /* If the msk has read data, or the caller explicitly ask it, + * do the MPTCP equivalent of TCP reset, aka MPTCP fastclose + */ diff --git a/queue-6.12/mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch b/queue-6.12/mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch new file mode 100644 index 0000000000..9d1a25bae3 --- /dev/null +++ b/queue-6.12/mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch @@ -0,0 +1,57 @@ +From b5c52908d52c6c8eb8933264aa6087a0600fd892 Mon Sep 17 00:00:00 2001 +From: Gang Yan +Date: Mon, 27 Apr 2026 21:54:34 +0200 +Subject: mptcp: fix scheduling with atomic in timestamp sockopt + +From: Gang Yan + +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 +--- + net/mptcp/sockopt.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/net/mptcp/sockopt.c ++++ b/net/mptcp/sockopt.c +@@ -159,10 +159,10 @@ static int mptcp_setsockopt_sol_socket_t + lock_sock(sk); + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); +- bool slow = lock_sock_fast(ssk); + ++ lock_sock(ssk); + sock_set_timestamp(ssk, optname, !!val); +- unlock_sock_fast(ssk, slow); ++ release_sock(ssk); + } + + release_sock(sk); +@@ -235,10 +235,10 @@ static int mptcp_setsockopt_sol_socket_t + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); +- bool slow = lock_sock_fast(ssk); + ++ lock_sock(ssk); + sock_set_timestamping(ssk, optname, timestamping); +- unlock_sock_fast(ssk, slow); ++ release_sock(ssk); + } + + release_sock(sk); diff --git a/queue-6.12/mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch b/queue-6.12/mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch new file mode 100644 index 0000000000..3fda447f18 --- /dev/null +++ b/queue-6.12/mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch @@ -0,0 +1,50 @@ +From 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 Mon Sep 17 00:00:00 2001 +From: Gang Yan +Date: Mon, 27 Apr 2026 21:54:33 +0200 +Subject: mptcp: sockopt: set timestamp flags on subflow socket, not msk + +From: Gang Yan + +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 +--- + net/mptcp/sockopt.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/mptcp/sockopt.c ++++ b/net/mptcp/sockopt.c +@@ -161,7 +161,7 @@ static int mptcp_setsockopt_sol_socket_t + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + bool slow = lock_sock_fast(ssk); + +- sock_set_timestamp(sk, optname, !!val); ++ sock_set_timestamp(ssk, optname, !!val); + unlock_sock_fast(ssk, slow); + } + +@@ -237,7 +237,7 @@ static int mptcp_setsockopt_sol_socket_t + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + bool slow = lock_sock_fast(ssk); + +- sock_set_timestamping(sk, optname, timestamping); ++ sock_set_timestamping(ssk, optname, timestamping); + unlock_sock_fast(ssk, slow); + } + diff --git a/queue-6.12/mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch b/queue-6.12/mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch new file mode 100644 index 0000000000..6e25baed9c --- /dev/null +++ b/queue-6.12/mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch @@ -0,0 +1,45 @@ +From c4a99a921949cddc590b22bb14eeb23dffcc3ba6 Mon Sep 17 00:00:00 2001 +From: Shardul Bankar +Date: Fri, 1 May 2026 21:35:34 +0200 +Subject: mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure + +From: Shardul Bankar + +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 +--- + net/mptcp/subflow.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -578,7 +578,7 @@ static void subflow_finish_connect(struc + subflow->backup); + + if (!subflow_thmac_valid(subflow)) { +- MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC); ++ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINSYNACKMAC); + subflow->reset_reason = MPTCP_RST_EMPTCP; + goto do_reset; + } diff --git a/queue-6.12/mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch b/queue-6.12/mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch new file mode 100644 index 0000000000..38f2a34472 --- /dev/null +++ b/queue-6.12/mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch @@ -0,0 +1,44 @@ +From a6da02d4c00fdda2417e42ad2b762a9209e6cc49 Mon Sep 17 00:00:00 2001 +From: Shardul Bankar +Date: Fri, 1 May 2026 21:35:35 +0200 +Subject: mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure + +From: Shardul Bankar + +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 +--- + net/mptcp/subflow.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -910,7 +910,7 @@ create_child: + + if (!subflow_hmac_valid(req, &mp_opt)) { + SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); +- subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); ++ subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP); + goto dispose_child; + } + diff --git a/queue-6.12/pci-aer-clear-only-error-bits-in-pcie-device-status.patch b/queue-6.12/pci-aer-clear-only-error-bits-in-pcie-device-status.patch new file mode 100644 index 0000000000..2ff35050e5 --- /dev/null +++ b/queue-6.12/pci-aer-clear-only-error-bits-in-pcie-device-status.patch @@ -0,0 +1,64 @@ +From a8aeea1bf3c80cc87983689e0118770e019bd4f3 Mon Sep 17 00:00:00 2001 +From: Shuai Xue +Date: Wed, 11 Feb 2026 20:46:24 +0800 +Subject: PCI/AER: Clear only error bits in PCIe Device Status + +From: Shuai Xue + +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 +--- + drivers/pci/pci.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -2321,10 +2321,9 @@ EXPORT_SYMBOL_GPL(pci_set_pcie_reset_sta + #ifdef CONFIG_PCIEAER + void pcie_clear_device_status(struct pci_dev *dev) + { +- u16 sta; +- +- pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &sta); +- pcie_capability_write_word(dev, PCI_EXP_DEVSTA, sta); ++ pcie_capability_write_word(dev, PCI_EXP_DEVSTA, ++ PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | ++ PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); + } + #endif + diff --git a/queue-6.12/pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch b/queue-6.12/pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch new file mode 100644 index 0000000000..4775daa02e --- /dev/null +++ b/queue-6.12/pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch @@ -0,0 +1,53 @@ +From 1ab4a3c805084d752ec571efc78272295a9f2f74 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Fri, 27 Mar 2026 10:56:43 +0100 +Subject: PCI/AER: Stop ruling out unbound devices as error source + +From: Lukas Wunner + +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 +--- + drivers/pci/pcie/aer.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/pci/pcie/aer.c ++++ b/drivers/pci/pcie/aer.c +@@ -849,8 +849,6 @@ static bool is_error_source(struct pci_d + * 3) There are multiple errors and prior ID comparing fails; + * We check AER status registers to find possible reporter. + */ +- if (atomic_read(&dev->enable_cnt) == 0) +- return false; + + /* Check if AER is enabled */ + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, ®16); diff --git a/queue-6.12/pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch b/queue-6.12/pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch new file mode 100644 index 0000000000..9eb6fb1ca5 --- /dev/null +++ b/queue-6.12/pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch @@ -0,0 +1,91 @@ +From cc33985d26c92a5c908c0185239c59ec35b8637c Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Mon, 16 Feb 2026 08:46:13 +0100 +Subject: PCI/ASPM: Fix pci_clear_and_set_config_dword() usage +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Lukas Wunner + +commit cc33985d26c92a5c908c0185239c59ec35b8637c upstream. + +When aspm_calc_l12_info() programs the L1 PM Substates Control 1 register +fields Common_Mode_Restore_Time, LTR_L1.2_THRESHOLD_Value and _Scale, it +invokes pci_clear_and_set_config_dword() in an incorrect way: + +For the bits to clear it selects those corresponding to the field. So far +so good. But for the bits to set it passes a full register value. +pci_clear_and_set_config_dword() performs a boolean OR operation which +sets all bits of that value, not just the ones that were just cleared. + +Thus, when setting the LTR_L1.2_THRESHOLD_Value and _Scale on the child of +an ASPM link, aspm_calc_l12_info() also sets the Common_Mode_Restore_Time. +That's a spec violation: PCIe r7.0 sec 7.8.3.3 says this field is RsvdP +for Upstream Ports. On Adrià's Pixelbook Eve, Common_Mode_Restore_Time +of the Intel 7265 "Stone Peak" wifi card is zero, yet aspm_calc_l12_info() +does not preserve the zero bits but instead programs the value calculated +for the Root Port into the wifi card. + +Likewise, when setting the Common_Mode_Restore_Time on the Root Port, +aspm_calc_l12_info() also changes the LTR_L1.2_THRESHOLD_Value and _Scale +from the initial 163840 nsec to 237568 nsec (due to ORing those fields), +only to reduce it afterwards to 106496 nsec. + +Amend all invocations of pci_clear_and_set_config_dword() to only set bits +which are cleared. + +Finally, when setting the T_POWER_ON_Value and _Scale on the Root Port and +the wifi card, aspm_calc_l12_info() fails to preserve bits declared RsvdP +and instead overwrites them with zeroes. Replace pci_write_config_dword() +with pci_clear_and_set_config_dword() to avoid this. + +Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings") +Link: https://bugzilla.kernel.org/show_bug.cgi?id=220705#c22 +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Tested-by: Adrià Vilanova Martínez +Cc: stable@vger.kernel.org # v4.11+ +Link: https://patch.msgid.link/5c1752d7512eed0f4ea57b84b12d7ee08ca61fc5.1771226659.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pcie/aspm.c | 17 ++++++++++++----- + 1 file changed, 12 insertions(+), 5 deletions(-) + +--- a/drivers/pci/pcie/aspm.c ++++ b/drivers/pci/pcie/aspm.c +@@ -704,22 +704,29 @@ static void aspm_calc_l12_info(struct pc + } + + /* Program T_POWER_ON times in both ports */ +- pci_write_config_dword(parent, parent->l1ss + PCI_L1SS_CTL2, ctl2); +- pci_write_config_dword(child, child->l1ss + PCI_L1SS_CTL2, ctl2); ++ pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL2, ++ PCI_L1SS_CTL2_T_PWR_ON_VALUE | ++ PCI_L1SS_CTL2_T_PWR_ON_SCALE, ctl2); ++ pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL2, ++ PCI_L1SS_CTL2_T_PWR_ON_VALUE | ++ PCI_L1SS_CTL2_T_PWR_ON_SCALE, ctl2); + + /* Program Common_Mode_Restore_Time in upstream device */ + pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1, +- PCI_L1SS_CTL1_CM_RESTORE_TIME, ctl1); ++ PCI_L1SS_CTL1_CM_RESTORE_TIME, ++ ctl1 & PCI_L1SS_CTL1_CM_RESTORE_TIME); + + /* Program LTR_L1.2_THRESHOLD time in both ports */ + pci_clear_and_set_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1, + PCI_L1SS_CTL1_LTR_L12_TH_VALUE | + PCI_L1SS_CTL1_LTR_L12_TH_SCALE, +- ctl1); ++ ctl1 & (PCI_L1SS_CTL1_LTR_L12_TH_VALUE | ++ PCI_L1SS_CTL1_LTR_L12_TH_SCALE)); + pci_clear_and_set_config_dword(child, child->l1ss + PCI_L1SS_CTL1, + PCI_L1SS_CTL1_LTR_L12_TH_VALUE | + PCI_L1SS_CTL1_LTR_L12_TH_SCALE, +- ctl1); ++ ctl1 & (PCI_L1SS_CTL1_LTR_L12_TH_VALUE | ++ PCI_L1SS_CTL1_LTR_L12_TH_SCALE)); + + if (pl1_2_enables || cl1_2_enables) { + pci_clear_and_set_config_dword(parent, diff --git a/queue-6.12/power-supply-max17042-avoid-overflow-when-determining-health.patch b/queue-6.12/power-supply-max17042-avoid-overflow-when-determining-health.patch new file mode 100644 index 0000000000..9c90c789d0 --- /dev/null +++ b/queue-6.12/power-supply-max17042-avoid-overflow-when-determining-health.patch @@ -0,0 +1,41 @@ +From 9a44949da669708f19d29141e65b3ac774d08f5a Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andr=C3=A9=20Draszik?= +Date: Mon, 2 Mar 2026 13:32:05 +0000 +Subject: power: supply: max17042: avoid overflow when determining health +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: André Draszik + +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 +--- + drivers/power/supply/max17042_battery.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/power/supply/max17042_battery.c ++++ b/drivers/power/supply/max17042_battery.c +@@ -199,7 +199,7 @@ static int max17042_get_battery_health(s + goto out; + } + +- if (vbatt > chip->pdata->vmax + MAX17042_VMAX_TOLERANCE) { ++ if (vbatt > size_add(chip->pdata->vmax, MAX17042_VMAX_TOLERANCE)) { + *health = POWER_SUPPLY_HEALTH_OVERVOLTAGE; + goto out; + } diff --git a/queue-6.12/rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch b/queue-6.12/rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch new file mode 100644 index 0000000000..929037c3c7 --- /dev/null +++ b/queue-6.12/rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch @@ -0,0 +1,42 @@ +From 6aaa978c6b6218cfac15fe1dab17c76fe229ce3f Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:40 -0300 +Subject: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() + +From: Jason Gunthorpe + +commit 6aaa978c6b6218cfac15fe1dab17c76fe229ce3f upstream. + +Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal +destroy path cleans it up. + +Cc: stable@vger.kernel.org +Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") +Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 +Link: https://patch.msgid.link/r/7-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com +Reviewed-by: Long Li +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mana/qp.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mana/qp.c ++++ b/drivers/infiniband/hw/mana/qp.c +@@ -236,13 +236,15 @@ static int mana_ib_create_qp_rss(struct + ibdev_dbg(&mdev->ib_dev, + "Failed to copy to udata create rss-qp, %d\n", + ret); +- goto fail; ++ goto err_disable_vport_rx; + } + + kfree(mana_ind_table); + + return 0; + ++err_disable_vport_rx: ++ mana_disable_vport_rx(mpc); + fail: + while (i-- > 0) { + ibwq = ind_tbl->ind_tbl[i]; diff --git a/queue-6.12/rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch b/queue-6.12/rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch new file mode 100644 index 0000000000..060629189f --- /dev/null +++ b/queue-6.12/rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch @@ -0,0 +1,56 @@ +From 34ecf795692ee57c393109f4a24ccc313091e137 Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:39 -0300 +Subject: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() + +From: Jason Gunthorpe + +commit 34ecf795692ee57c393109f4a24ccc313091e137 upstream. + +Sashiko points out there are two bugs here in the error unwind flow, both +related to how the WQ table is unwound. + +First there is a double i-- on the first failure path due to the while loop +having a i--, remove it. + +Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not +undone due to the above i--. + +Cc: stable@vger.kernel.org +Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP") +Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1 +Link: https://patch.msgid.link/r/6-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com +Reviewed-by: Long Li +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mana/qp.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +--- a/drivers/infiniband/hw/mana/qp.c ++++ b/drivers/infiniband/hw/mana/qp.c +@@ -194,11 +194,8 @@ static int mana_ib_create_qp_rss(struct + + ret = mana_create_wq_obj(mpc, mpc->port_handle, GDMA_RQ, + &wq_spec, &cq_spec, &wq->rx_object); +- if (ret) { +- /* Do cleanup starting with index i-1 */ +- i--; ++ if (ret) + goto fail; +- } + + /* The GDMA regions are now owned by the WQ object */ + wq->queue.gdma_region = GDMA_INVALID_DMA_REGION; +@@ -218,8 +215,10 @@ static int mana_ib_create_qp_rss(struct + + /* Create CQ table entry */ + ret = mana_ib_install_cq_cb(mdev, cq); +- if (ret) ++ if (ret) { ++ mana_destroy_wq_obj(mpc, GDMA_RQ, wq->rx_object); + goto fail; ++ } + } + resp.num_entries = i; + diff --git a/queue-6.12/rdma-mana-validate-rx_hash_key_len.patch b/queue-6.12/rdma-mana-validate-rx_hash_key_len.patch new file mode 100644 index 0000000000..fa5efa7b7a --- /dev/null +++ b/queue-6.12/rdma-mana-validate-rx_hash_key_len.patch @@ -0,0 +1,36 @@ +From 6dd2d4ad9c8429523b1c220c5132bd551c006425 Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:37 -0300 +Subject: RDMA/mana: Validate rx_hash_key_len + +From: Jason Gunthorpe + +commit 6dd2d4ad9c8429523b1c220c5132bd551c006425 upstream. + +Sashiko points out that rx_hash_key_len comes from a uAPI structure and is +blindly passed to memcpy, allowing the userspace to trash kernel +memory. Bounds check it so the memcpy cannot overflow. + +Cc: stable@vger.kernel.org +Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") +Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1 +Link: https://patch.msgid.link/r/4-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com +Reviewed-by: Long Li +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mana/qp.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/infiniband/hw/mana/qp.c ++++ b/drivers/infiniband/hw/mana/qp.c +@@ -21,6 +21,9 @@ static int mana_ib_cfg_vport_steering(st + + gc = mdev_to_gc(dev); + ++ if (rx_hash_key_len > sizeof(req->hashkey)) ++ return -EINVAL; ++ + req_buf_size = struct_size(req, indir_tab, MANA_INDIRECT_TABLE_DEF_SIZE); + req = kzalloc(req_buf_size, GFP_KERNEL); + if (!req) diff --git a/queue-6.12/rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch b/queue-6.12/rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch new file mode 100644 index 0000000000..5a284c73d8 --- /dev/null +++ b/queue-6.12/rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch @@ -0,0 +1,41 @@ +From c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:44 -0300 +Subject: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() + +From: Jason Gunthorpe + +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 +--- + drivers/infiniband/hw/mlx4/srq.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx4/srq.c ++++ b/drivers/infiniband/hw/mlx4/srq.c +@@ -193,13 +193,15 @@ int mlx4_ib_create_srq(struct ib_srq *ib + if (udata) + if (ib_copy_to_udata(udata, &srq->msrq.srqn, sizeof (__u32))) { + err = -EFAULT; +- goto err_wrid; ++ goto err_srq; + } + + init_attr->attr.max_wr = srq->msrq.max - 1; + + return 0; + ++err_srq: ++ mlx4_srq_free(dev->dev, &srq->msrq); + err_wrid: + if (udata) + mlx4_ib_db_unmap_user(ucontext, &srq->db); diff --git a/queue-6.12/rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch b/queue-6.12/rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch new file mode 100644 index 0000000000..ea7cea8017 --- /dev/null +++ b/queue-6.12/rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch @@ -0,0 +1,43 @@ +From c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 Mon Sep 17 00:00:00 2001 +From: Junrui Luo +Date: Fri, 24 Apr 2026 13:51:02 +0800 +Subject: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() + +From: Junrui Luo + +commit c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 upstream. + +mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When +ib_create_srq() fails for s1, the error branch destroys s0 but falls +through and unconditionally assigns the freed s0 and the ERR_PTR s1 to +devr->s0 and devr->s1. + +This leads to several problems: the lock-free fast path checks +"if (devr->s1) return 0;" and treats the ERR_PTR as already initialised; +users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via +to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences +the ERR_PTR and double-frees s0 on teardown. + +Fix by adding the same `goto unlock` in the s1 failure path. + +Cc: stable@vger.kernel.org +Fixes: 5895e70f2e6e ("IB/mlx5: Allocate resources just before first QP/SRQ is created") +Link: https://patch.msgid.link/r/SYBPR01MB7881E1E0970268BD69C0BA75AF2B2@SYBPR01MB7881.ausprd01.prod.outlook.com +Reported-by: Yuhao Jiang +Signed-off-by: Junrui Luo +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/main.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/infiniband/hw/mlx5/main.c ++++ b/drivers/infiniband/hw/mlx5/main.c +@@ -3127,6 +3127,7 @@ int mlx5_ib_dev_res_srq_init(struct mlx5 + ret = PTR_ERR(s1); + mlx5_ib_err(dev, "Couldn't create SRQ 1 for res init, err=%d\n", ret); + ib_destroy_srq(s0); ++ goto unlock; + } + + devr->s0 = s0; diff --git a/queue-6.12/rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch b/queue-6.12/rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch new file mode 100644 index 0000000000..761b86747d --- /dev/null +++ b/queue-6.12/rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch @@ -0,0 +1,37 @@ +From 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:42 -0300 +Subject: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() + +From: Jason Gunthorpe + +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 +--- + drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c ++++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +@@ -620,9 +620,9 @@ static int ocrdma_copy_pd_uresp(struct o + + ucopy_err: + if (pd->dpp_enabled) +- ocrdma_del_mmap(pd->uctx, dpp_page_addr, PAGE_SIZE); ++ ocrdma_del_mmap(uctx, dpp_page_addr, PAGE_SIZE); + dpp_map_err: +- ocrdma_del_mmap(pd->uctx, db_page_addr, db_page_size); ++ ocrdma_del_mmap(uctx, db_page_addr, db_page_size); + return status; + } + diff --git a/queue-6.12/rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch b/queue-6.12/rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch new file mode 100644 index 0000000000..499c51f56f --- /dev/null +++ b/queue-6.12/rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch @@ -0,0 +1,69 @@ +From 1114c87aa6f195cf07da55a27b2122ae26557b26 Mon Sep 17 00:00:00 2001 +From: Michael Bommarito +Date: Sat, 18 Apr 2026 12:21:41 -0400 +Subject: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads + +From: Michael Bommarito + +commit 1114c87aa6f195cf07da55a27b2122ae26557b26 upstream. + +atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c +unconditionally dereferences 8 bytes at payload_addr(pkt): + + value = *(u64 *)payload_addr(pkt); + +check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == +resid == 0 because the length validation only compared pktlen against +resid. A remote initiator that sets the RETH length to 0 therefore reaches +atomic_write_reply() with a zero-byte logical payload, and the responder +reads sizeof(u64) bytes from past the logical end of the packet into +skb->head tailroom, then writes those 8 bytes into the attacker's MR via +rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel +tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). + +IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is +protocol-invalid. Hoist a strict length check into check_rkey() so the +responder never reaches the unchecked dereference, and keep the existing +WRITE-family length logic for the normal RDMA WRITE path. + +Reproduced on mainline with an unmodified rxe driver: a sustained +zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer +bytes into the attacker's MR, including recognisable kernel strings and +partial kernel-direct-map pointer words. With this patch applied the +responder rejects the PDU and the MR stays all-zero. + +Cc: stable@vger.kernel.org +Fixes: 034e285f8b99 ("RDMA/rxe: Make responder support atomic write on RC service") +Link: https://patch.msgid.link/r/20260418162141.3610201-1-michael.bommarito@gmail.com +Assisted-by: Claude:claude-opus-4-7 +Signed-off-by: Michael Bommarito +Reviewed-by: Zhu Yanjun +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/sw/rxe/rxe_resp.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/sw/rxe/rxe_resp.c ++++ b/drivers/infiniband/sw/rxe/rxe_resp.c +@@ -526,7 +526,19 @@ static enum resp_states check_rkey(struc + } + + skip_check_range: +- if (pkt->mask & (RXE_WRITE_MASK | RXE_ATOMIC_WRITE_MASK)) { ++ if (pkt->mask & RXE_ATOMIC_WRITE_MASK) { ++ /* IBA oA19-28: ATOMIC_WRITE payload is exactly 8 bytes. ++ * Reject any other length before the responder reads ++ * sizeof(u64) bytes from payload_addr(pkt); a shorter ++ * payload would read past the logical end of the packet ++ * into skb->head tailroom. ++ */ ++ if (resid != sizeof(u64) || pktlen != sizeof(u64) || ++ bth_pad(pkt)) { ++ state = RESPST_ERR_LENGTH; ++ goto err; ++ } ++ } else if (pkt->mask & RXE_WRITE_MASK) { + if (resid > mtu) { + if (pktlen != mtu || bth_pad(pkt)) { + state = RESPST_ERR_LENGTH; diff --git a/queue-6.12/rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch b/queue-6.12/rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch new file mode 100644 index 0000000000..ae4fc0efc4 --- /dev/null +++ b/queue-6.12/rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch @@ -0,0 +1,94 @@ +From 4c6f86d85d03cdb33addce86aa69aa795ca6c47a Mon Sep 17 00:00:00 2001 +From: Michael Bommarito +Date: Tue, 14 Apr 2026 07:15:55 -0400 +Subject: RDMA/rxe: Reject unknown opcodes before ICRC processing + +From: Michael Bommarito + +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 +--- + drivers/infiniband/sw/rxe/rxe_recv.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/infiniband/sw/rxe/rxe_recv.c ++++ b/drivers/infiniband/sw/rxe/rxe_recv.c +@@ -330,6 +330,17 @@ void rxe_rcv(struct sk_buff *skb) + pkt->qp = NULL; + pkt->mask |= rxe_opcode[pkt->opcode].mask; + ++ /* ++ * Unknown opcodes have a zero-initialized rxe_opcode[] entry, so ++ * both mask and length are 0. Reject them before any length math: ++ * rxe_icrc_hdr() would otherwise compute length - RXE_BTH_BYTES ++ * and pass the underflowed value to rxe_crc32(), producing an ++ * out-of-bounds read. ++ */ ++ if (unlikely(!rxe_opcode[pkt->opcode].mask || ++ !rxe_opcode[pkt->opcode].length)) ++ goto drop; ++ + if (unlikely(pkt->paylen < header_size(pkt) + bth_pad(pkt) + + RXE_ICRC_SIZE)) + goto drop; diff --git a/queue-6.12/rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch b/queue-6.12/rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch new file mode 100644 index 0000000000..db3e540ba9 --- /dev/null +++ b/queue-6.12/rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch @@ -0,0 +1,33 @@ +From e38e86995df27f1f854063dab1f0c6a513db3faf Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:43 -0300 +Subject: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path + +From: Jason Gunthorpe + +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 +--- + drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c ++++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c +@@ -350,7 +350,7 @@ int pvrdma_alloc_ucontext(struct ib_ucon + uresp.qp_tab_size = vdev->dsr->caps.max_qp; + ret = ib_copy_to_udata(udata, &uresp, sizeof(uresp)); + if (ret) { +- pvrdma_uar_free(vdev, &context->uar); ++ /* pvrdma_dealloc_ucontext() also frees the UAR */ + pvrdma_dealloc_ucontext(&context->ibucontext); + return -EFAULT; + } diff --git a/queue-6.12/selftests-mptcp-check-output-catch-cmd-errors.patch b/queue-6.12/selftests-mptcp-check-output-catch-cmd-errors.patch new file mode 100644 index 0000000000..f8c64045d1 --- /dev/null +++ b/queue-6.12/selftests-mptcp-check-output-catch-cmd-errors.patch @@ -0,0 +1,111 @@ +From 65db7b27b90e2ea8d4966935aa9a50b6a60c31ac Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 5 May 2026 17:00:58 +0200 +Subject: selftests: mptcp: check output: catch cmd errors + +From: Matthieu Baerts (NGI0) + +commit 65db7b27b90e2ea8d4966935aa9a50b6a60c31ac upstream. + +Using '${?}' inside the if-statement to check the returned value from +the command that was evaluated as part of the if-statement is not +correct: here, '${?}' will be linked to the previous instruction, not +the one that is expected here (${cmd}). + +Instead, simply mark the error, except if an error is expected. If +that's the case, 1 can be passed as the 4th argument of this helper. +Three checks from pm_netlink.sh expect an error. + +While at it, improve the error message when the command unexpectedly +fails or succeeds. + +Note that we could expect a specific returned value, but the checks +currently expecting an error can be used with 'ip mptcp' or 'pm_nl_ctl', +and these two tools don't return the same error code. + +Fixes: 2d0c1d27ea4e ("selftests: mptcp: add mptcp_lib_check_output helper") +Cc: stable@vger.kernel.org +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-10-fca8091060a4@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/net/mptcp/mptcp_lib.sh | 16 ++++++++++------ + tools/testing/selftests/net/mptcp/pm_netlink.sh | 10 ++++++---- + 2 files changed, 16 insertions(+), 10 deletions(-) + +--- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh ++++ b/tools/testing/selftests/net/mptcp/mptcp_lib.sh +@@ -407,20 +407,24 @@ mptcp_lib_wait_local_port_listen() { + wait_local_port_listen "${@}" "tcp" + } + ++# $1: error file, $2: cmd, $3: expected msg, [$4: expected error] + mptcp_lib_check_output() { + local err="${1}" + local cmd="${2}" + local expected="${3}" ++ local exp_error="${4:-0}" + local cmd_ret=0 + local out + +- if ! out=$(${cmd} 2>"${err}"); then +- cmd_ret=${?} +- fi ++ out=$(${cmd} 2>"${err}") || cmd_ret=1 + +- if [ ${cmd_ret} -ne 0 ]; then +- mptcp_lib_pr_fail "command execution '${cmd}' stderr" +- cat "${err}" ++ if [ "${cmd_ret}" != "${exp_error}" ]; then ++ mptcp_lib_pr_fail "unexpected returned code for '${cmd}', info:" ++ if [ "${exp_error}" = 0 ]; then ++ cat "${err}" ++ else ++ echo "${out}" ++ fi + return 2 + elif [ "${out}" = "${expected}" ]; then + return 0 +--- a/tools/testing/selftests/net/mptcp/pm_netlink.sh ++++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh +@@ -121,10 +121,12 @@ check() + local cmd="$1" + local expected="$2" + local msg="$3" ++ local exp_error="$4" + local rc=0 + + mptcp_lib_print_title "$msg" +- mptcp_lib_check_output "${err}" "${cmd}" "${expected}" || rc=${?} ++ mptcp_lib_check_output "${err}" "${cmd}" "${expected}" "${exp_error}" || ++ rc=${?} + if [ ${rc} -eq 2 ]; then + mptcp_lib_result_fail "${msg} # error ${rc}" + ret=${KSFT_FAIL} +@@ -157,13 +159,13 @@ check "show_endpoints" \ + "3,10.0.1.3,signal backup")" "dump addrs" + + del_endpoint 2 +-check "get_endpoint 2" "" "simple del addr" ++check "get_endpoint 2" "" "simple del addr" 1 + check "show_endpoints" \ + "$(format_endpoints "1,10.0.1.1" \ + "3,10.0.1.3,signal backup")" "dump addrs after del" + + add_endpoint 10.0.1.3 2>/dev/null +-check "get_endpoint 4" "" "duplicate addr" ++check "get_endpoint 4" "" "duplicate addr" 1 + + add_endpoint 10.0.1.4 flags signal + check "get_endpoint 4" "$(format_endpoints "4,10.0.1.4,signal")" "id addr increment" +@@ -172,7 +174,7 @@ for i in $(seq 5 9); do + add_endpoint "10.0.1.${i}" flags signal >/dev/null 2>&1 + done + check "get_endpoint 9" "$(format_endpoints "9,10.0.1.9,signal")" "hard addr limit" +-check "get_endpoint 10" "" "above hard addr limit" ++check "get_endpoint 10" "" "above hard addr limit" 1 + + del_endpoint 9 + for i in $(seq 10 255); do diff --git a/queue-6.12/selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch b/queue-6.12/selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch new file mode 100644 index 0000000000..139dc7b7a9 --- /dev/null +++ b/queue-6.12/selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch @@ -0,0 +1,47 @@ +From 53705ddfa18408f8e1f064331b6387509fa19f7f Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 5 May 2026 17:00:59 +0200 +Subject: selftests: mptcp: pm: restrict 'unknown' check to pm_nl_ctl + +From: Matthieu Baerts (NGI0) + +commit 53705ddfa18408f8e1f064331b6387509fa19f7f upstream. + +When pm_netlink.sh is executed with '-i', 'ip mptcp' is used instead of +'pm_nl_ctl'. IPRoute2 doesn't support the 'unknown' flag, which has only +been added to 'pm_nl_ctl' for this specific check: to ensure that the +kernel ignores such unsupported flag. + +No reason to add this flag to 'ip mptcp'. Then, this check should be +skipped when 'ip mptcp' is used. + +Fixes: 0cef6fcac24d ("selftests: mptcp: ip_mptcp option for more scripts") +Cc: stable@vger.kernel.org +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-11-fca8091060a4@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/net/mptcp/pm_netlink.sh | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/tools/testing/selftests/net/mptcp/pm_netlink.sh ++++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh +@@ -193,9 +193,13 @@ check "show_endpoints" \ + flush_endpoint + check "show_endpoints" "" "flush addrs" + +-add_endpoint 10.0.1.1 flags unknown +-check "show_endpoints" "$(format_endpoints "1,10.0.1.1")" "ignore unknown flags" +-flush_endpoint ++# "unknown" flag is only supported by pm_nl_ctl ++if ! mptcp_lib_is_ip_mptcp; then ++ add_endpoint 10.0.1.1 flags unknown ++ check "show_endpoints" "$(format_endpoints "1,10.0.1.1")" \ ++ "ignore unknown flags" ++ flush_endpoint ++fi + + set_limits 9 1 2>/dev/null + check "get_limits" "${default_limits}" "rcv addrs above hard limit" diff --git a/queue-6.12/series b/queue-6.12/series index 72a7f681ac..312509fc63 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -141,3 +141,37 @@ smb-client-validate-dacloffset-before-building-dacl-pointers.patch kvm-x86-check-for-nept-nnpt-in-slow-flush-hypercalls.patch mm-damon-sysfs-schemes-protect-memcg_path-kfree-with-damon_sysfs_lock.patch pci-update-saved_config_space-upon-resource-assignment.patch +pci-aer-clear-only-error-bits-in-pcie-device-status.patch +pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch +pci-aspm-fix-pci_clear_and_set_config_dword-usage.patch +power-supply-max17042-avoid-overflow-when-determining-health.patch +rdma-mana-fix-error-unwind-in-mana_ib_create_qp_rss.patch +rdma-mana-fix-mana_destroy_wq_obj-cleanup-in-mana_ib_create_qp_rss.patch +rdma-mana-validate-rx_hash_key_len.patch +rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch +rdma-mlx5-fix-error-path-fall-through-in-mlx5_ib_dev_res_srq_init.patch +rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch +rdma-rxe-reject-non-8-byte-atomic_write-payloads.patch +rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch +rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch +selftests-mptcp-check-output-catch-cmd-errors.patch +selftests-mptcp-pm-restrict-unknown-check-to-pm_nl_ctl.patch +mptcp-fastclose-msk-when-linger-time-is-0.patch +mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch +mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch +mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch +mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch +f2fs-add-read_once-for-i_blocks-in-f2fs_update_inode.patch +f2fs-fix-fiemap-boundary-handling-when-read-extent-cache-is-incomplete.patch +f2fs-fix-incorrect-multidevice-info-in-trace_f2fs_map_blocks.patch +f2fs-fix-node_cnt-race-between-extent-node-destroy-and-writeback.patch +f2fs-fix-uninitialized-kobject-put-in-f2fs_init_sysfs.patch +kvm-arm64-vgic-fix-iidr-revision-field-extracted-from-wrong-value.patch +kvm-arm64-fix-initialisation-order-in-__pkvm_init_finalise.patch +loongarch-fix-potential-ade-in-loongson_gpu_fixup_dma_hang.patch +loongarch-kvm-cap-kvm_cap_nr_vcpus-by-kvm_cap_max_vcpus.patch +loongarch-kvm-fix-unreliable-stack-for-kvm_exc_entry.patch +loongarch-kvm-fix-hw-timer-interrupt-lost-when-inject-interrupt-by-software.patch +loongarch-kvm-move-unconditional-delay-into-timer-clear-scenery.patch +loongarch-kvm-use-kvm_set_pte-in-kvm_flush_pte.patch +loongarch-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch