--- /dev/null
+From 5471834a96fb697874be2ca0b052e74bcf3c23d1 Mon Sep 17 00:00:00 2001
+From: Cen Zhang <zzzccc427@gmail.com>
+Date: Wed, 18 Mar 2026 15:32:53 +0800
+Subject: f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode()
+
+From: Cen Zhang <zzzccc427@gmail.com>
+
+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 <zzzccc427@gmail.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/inode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/f2fs/inode.c
++++ b/fs/f2fs/inode.c
+@@ -665,7 +665,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))
--- /dev/null
+From 95e159ad3e52f7478cfd22e44ec37c9f334f8993 Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+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 <yangyongpeng@xiaomi.com>
+
+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 <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/data.c | 25 ++++++++++++++++++++++---
+ 1 file changed, 22 insertions(+), 3 deletions(-)
+
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -1543,8 +1543,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 =
+@@ -1555,7 +1573,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) {
--- /dev/null
+From eb2ca3ca983551a80e16a4a25df5a4ce59df8484 Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Date: Mon, 23 Mar 2026 20:06:22 +0800
+Subject: f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks()
+
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+
+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 <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/data.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -1507,7 +1507,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];
+
--- /dev/null
+From ed78aeebef05212ef7dca93bd931e4eff67c113f Mon Sep 17 00:00:00 2001
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+Date: Fri, 3 Apr 2026 22:40:17 +0800
+Subject: f2fs: fix node_cnt race between extent node destroy and writeback
+
+From: Yongpeng Yang <yangyongpeng@xiaomi.com>
+
+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 <yangyongpeng@xiaomi.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -87,9 +87,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;
+@@ -602,6 +603,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);
+ }
+@@ -637,12 +640,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;
+
--- /dev/null
+From 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 Mon Sep 17 00:00:00 2001
+From: Quentin Perret <qperret@google.com>
+Date: Fri, 24 Apr 2026 09:49:08 +0100
+Subject: KVM: arm64: Fix initialisation order in __pkvm_init_finalise()
+
+From: Quentin Perret <qperret@google.com>
+
+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 <qperret@google.com>
+Signed-off-by: Fuad Tabba <tabba@google.com>
+Link: https://patch.msgid.link/20260424084908.370776-7-tabba@google.com
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -284,15 +284,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;
+
--- /dev/null
+From a0e6ae45af17e8b27958830595799c702ffbab8d Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+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 <dwmw@amazon.co.uk>
+
+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 <dwmw@amazon.co.uk>
+Link: https://patch.msgid.link/20260407210949.2076251-2-dwmw2@infradead.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e Mon Sep 17 00:00:00 2001
+From: Wentao Guan <guanwentao@uniontech.com>
+Date: Mon, 4 May 2026 09:00:20 +0800
+Subject: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()
+
+From: Wentao Guan <guanwentao@uniontech.com>
+
+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 <guanwentao@uniontech.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 49f33840dcc907d21313d369e34872880846b61c Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+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 <chenhuacai@loongson.cn>
+
+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 <lichao@loongson.cn>
+Tested-by: Dongyan Qian <qiandongyan@loongson.cn>
+Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From f14d6e9c3678a067f304abba561e0c5446c7e845 Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Mon, 27 Apr 2026 21:54:35 +0200
+Subject: mptcp: fastclose msk when linger time is 0
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+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 <lance@lance0.com>
+Closes: https://github.com/lance0/xfr/pull/67
+Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3]
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-3-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -3177,7 +3177,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
+ */
--- /dev/null
+From b5c52908d52c6c8eb8933264aa6087a0600fd892 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:34 +0200
+Subject: mptcp: fix scheduling with atomic in timestamp sockopt
+
+From: Gang Yan <yangang@kylinos.cn>
+
+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 <sashiko-bot@kernel.org>
+Closes: https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-2-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:33 +0200
+Subject: mptcp: sockopt: set timestamp flags on subflow socket, not msk
+
+From: Gang Yan <yangang@kylinos.cn>
+
+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 <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-1-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From c4a99a921949cddc590b22bb14eeb23dffcc3ba6 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:34 +0200
+Subject: mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+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) <matttbe@kernel.org>
+Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-1-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -558,7 +558,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;
+ }
--- /dev/null
+From a6da02d4c00fdda2417e42ad2b762a9209e6cc49 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:35 +0200
+Subject: mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+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) <matttbe@kernel.org>
+Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-2-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -885,7 +885,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;
+ }
+
--- /dev/null
+From a8aeea1bf3c80cc87983689e0118770e019bd4f3 Mon Sep 17 00:00:00 2001
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+Date: Wed, 11 Feb 2026 20:46:24 +0800
+Subject: PCI/AER: Clear only error bits in PCIe Device Status
+
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+
+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 <lukas@wunner.de>
+Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -2426,10 +2426,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
+
--- /dev/null
+From 1ab4a3c805084d752ec571efc78272295a9f2f74 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Fri, 27 Mar 2026 10:56:43 +0100
+Subject: PCI/AER: Stop ruling out unbound devices as error source
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
+Cc: stable@vger.kernel.org # v6.0+
+Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 9a44949da669708f19d29141e65b3ac774d08f5a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+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 <andre.draszik@linaro.org>
+
+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 <andre.draszik@linaro.org>
+Link: https://patch.msgid.link/20260302-max77759-fg-v3-6-3c5f01dbda23@linaro.org
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+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 <jgg@nvidia.com>
+
+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 <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 Mon Sep 17 00:00:00 2001
+From: Junrui Luo <moonafterrain@outlook.com>
+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 <moonafterrain@outlook.com>
+
+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 <danisjiang@gmail.com>
+Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -2924,6 +2924,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;
--- /dev/null
+From 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+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 <jgg@nvidia.com>
+
+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 <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 1114c87aa6f195cf07da55a27b2122ae26557b26 Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Sat, 18 Apr 2026 12:21:41 -0400
+Subject: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+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 <michael.bommarito@gmail.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -536,7 +536,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;
--- /dev/null
+From 4c6f86d85d03cdb33addce86aa69aa795ca6c47a Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Tue, 14 Apr 2026 07:15:55 -0400
+Subject: RDMA/rxe: Reject unknown opcodes before ICRC processing
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+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 <michael.bommarito@gmail.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From e38e86995df27f1f854063dab1f0c6a513db3faf Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+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 <jgg@nvidia.com>
+
+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 <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
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-aer-clear-only-error-bits-in-pcie-device-status.patch
+pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch
+power-supply-max17042-avoid-overflow-when-determining-health.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
+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
+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-use-per-root-bridge-pcih-flag-to-skip-mem-resource-fixup.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
