- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] netfilter: nft_fib: fix stale stack leak via the OIFNAME register
by superdcc97＠163.com 17 Jul '26

17 Jul '26

From: Davide Ornaghi <d.ornaghi97(a)gmail.com> stable inclusion from stable-v6.6.143 commit eb8a8124484dbc3c2b543e207da39bbccb703d31 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15828 CVE: CVE-2026-53134 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ab185e0c4fb82dfba6fb86f8271e06f931d9c64c ] For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes. Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Suggested-by: Florian Westphal <fw(a)strlen.de> Cc: stable(a)vger.kernel.org Signed-off-by: Davide Ornaghi <d.ornaghi97(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> [ kept the tree's existing `ip6_route_lookup`/`rt6_info` machinery (missing `fib6_lookup` refactor) and changed only `*dest = 0;` to `nft_fib_store_result(dest, priv, NULL)` ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv4/netfilter/nft_fib_ipv4.c | 2 +- net/ipv6/netfilter/nft_fib_ipv6.c | 2 +- net/netfilter/nft_fib.c | 6 ++++++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/nft_fib_ipv4.c b/net/ipv4/netfilter/nft_fib_ipv4.c index ba233fdd8188..94931d52048f 100644 --- a/net/ipv4/netfilter/nft_fib_ipv4.c +++ b/net/ipv4/netfilter/nft_fib_ipv4.c @@ -122,7 +122,7 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs, fl4.saddr = get_saddr(iph->daddr); } - *dest = 0; + nft_fib_store_result(dest, priv, NULL); if (fib_lookup(nft_net(pkt), &fl4, &res, FIB_LOOKUP_IGNORE_LINKSTATE)) return; diff --git a/net/ipv6/netfilter/nft_fib_ipv6.c b/net/ipv6/netfilter/nft_fib_ipv6.c index a89ce0fbfe4b..da4a35c20f10 100644 --- a/net/ipv6/netfilter/nft_fib_ipv6.c +++ b/net/ipv6/netfilter/nft_fib_ipv6.c @@ -193,7 +193,7 @@ void nft_fib6_eval(const struct nft_expr *expr, struct nft_regs *regs, } } - *dest = 0; + nft_fib_store_result(dest, priv, NULL); rt = (void *)ip6_route_lookup(nft_net(pkt), &fl6, pkt->skb, lookup_flags); if (rt->dst.error) diff --git a/net/netfilter/nft_fib.c b/net/netfilter/nft_fib.c index 507b7eba9bcd..b4f49f65fc42 100644 --- a/net/netfilter/nft_fib.c +++ b/net/netfilter/nft_fib.c @@ -107,6 +107,12 @@ int nft_fib_init(const struct nft_ctx *ctx, const struct nft_expr *expr, return -EINVAL; } + if (priv->flags & NFTA_FIB_F_PRESENT) { + if (priv->result != NFT_FIB_RESULT_OIF) + return -EINVAL; + len = sizeof(u8); + } + err = nft_parse_register_store(ctx, tb[NFTA_FIB_DREG], &priv->dreg, NULL, NFT_DATA_VALUE, len); if (err < 0) -- 2.43.0

1 0

[PATCH OLK-5.10] ocfs2: validate bg_bits during freefrag scan
by Long Li 17 Jul '26

17 Jul '26

From: ZhengYuan Huang <gality369(a)gmail.com> stable inclusion from stable-v5.10.257 commit bb2906a1065ec28de021bac2ed03f2624edd7d07 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15742 CVE: CVE-2026-53040 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 8f687eeed3da3012152b0f9473f578869de0cd7b ] [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer. Link: https://lkml.kernel.org/r/20260410034220.3825769-1-gality369@gmail.com Fixes: d24a10b9f8ed ("Ocfs2: Add a new code 'OCFS2_INFO_FREEFRAG' for o2info ioctl.") Signed-off-by: ZhengYuan Huang <gality369(a)gmail.com> Reviewed-by: Heming Zhao <heming.zhao(a)suse.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Heming Zhao <heming.zhao(a)suse.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ocfs2/ioctl.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/ioctl.c b/fs/ocfs2/ioctl.c index 89984172fc4a..b43d6c3586e0 100644 --- a/fs/ocfs2/ioctl.c +++ b/fs/ocfs2/ioctl.c @@ -438,13 +438,16 @@ static int ocfs2_info_freefrag_scan_chain(struct ocfs2_super *osb, struct buffer_head *bh = NULL; struct ocfs2_group_desc *bg = NULL; - unsigned int max_bits, num_clusters; + unsigned int max_bits, max_bitmap_bits, num_clusters; unsigned int offset = 0, cluster, chunk; unsigned int chunk_free, last_chunksize = 0; if (!le32_to_cpu(rec->c_free)) goto bail; + max_bitmap_bits = 8 * ocfs2_group_bitmap_size(osb->sb, 0, + osb->s_feature_incompat); + do { if (!bg) blkno = le64_to_cpu(rec->c_blkno); @@ -476,6 +479,19 @@ static int ocfs2_info_freefrag_scan_chain(struct ocfs2_super *osb, continue; max_bits = le16_to_cpu(bg->bg_bits); + + /* + * Non-coherent scans read raw blocks and do not get the + * bg_bits validation from + * ocfs2_read_group_descriptor(). + */ + if (max_bits > max_bitmap_bits) { + mlog(ML_ERROR, + "Group desc #%llu has %u bits, max bitmap bits %u\n", + (unsigned long long)blkno, max_bits, max_bitmap_bits); + max_bits = max_bitmap_bits; + } + offset = 0; for (chunk = 0; chunk < chunks_in_group; chunk++) { -- 2.52.0

2 1

[PATCH OLK-5.10] isofs: validate Rock Ridge CE continuation extent against volume size
by Long Li 17 Jul '26

17 Jul '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> mainline inclusion from mainline-v7.0 commit a36d990f591320e9dd379ab30063ebfe91d47e1f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15613 CVE: CVE-2026-46303 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. Fixes: f54e18f1b831 ("isofs: Fix infinite looping over CE entries") Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Link: https://patch.msgid.link/20260419212155.2169382-2-michael.bommarito@gmail.c… Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/isofs/rock.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c index 94ef92fe806c..1efa3ae2f41e 100644 --- a/fs/isofs/rock.c +++ b/fs/isofs/rock.c @@ -101,6 +101,15 @@ static int rock_continue(struct rock_state *rs) goto out; } + if ((unsigned)rs->cont_extent >= ISOFS_SB(rs->inode->i_sb)->s_nzones) { + printk(KERN_NOTICE "rock: corrupted directory entry. " + "extent=%u out of volume (nzones=%lu)\n", + (unsigned)rs->cont_extent, + ISOFS_SB(rs->inode->i_sb)->s_nzones); + ret = -EIO; + goto out; + } + if (rs->cont_extent) { struct buffer_head *bh; -- 2.52.0

2 1

[PATCH OLK-5.10] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
by Jinjiang Tu 16 Jul '26

16 Jul '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> stable inclusion from stable-v5.10.258 commit a132e199de69e2a45628aa8534df1bf5d44e1b6e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15706 CVE: CVE-2026-53004 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0cf004ffb61cd32d140531c3a84afe975f9fc7ea ] sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data. Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Acked-by: Xin Long <lucien.xin(a)gmail.com> Link: https://patch.msgid.link/20260416031903.1447072-1-michael.bommarito@gmail.c… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- net/sctp/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 279d5e9421d3..e20aa4dbf740 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -6863,7 +6863,7 @@ static int sctp_getsockopt_peer_auth_chunks(struct sock *sk, int len, /* See if the user provided enough room for all the data */ num_chunks = ntohs(ch->param_hdr.length) - sizeof(struct sctp_paramhdr); - if (len < num_chunks) + if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; if (copy_to_user(to, ch->chunks, num_chunks)) -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2025-10263
by Lin Yujun 16 Jul '26

16 Jul '26

*** BLURB HERE *** Lin Yujun (2): arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU arm64/openeuler_defconfig: add CONFIG_NVIDIA_OLYMPUS_ERRATUM_TLBI to openeuler_defconfig Documentation/arm64/silicon-errata.txt | 2 ++ arch/arm64/Kconfig | 15 +++++++++++++++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 7 +++++++ 5 files changed, 27 insertions(+) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU
by Lin Yujun 16 Jul '26

16 Jul '26

mainline inclusion from mainline-v7.1 commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15600 CVE: CVE-2025-10263 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. [linyujun: 4.19 does not have ARM64_ERRATUM_4118414 or the arm64_repeat_tlbi_list[] array. Adapt using the existing per-vendor config pattern (same as QCOM_FALKOR_ERRATUM_1009) with ERRATA_MIDR_ALL_VERSIONS.] Signed-off-by: Shanker Donthineni <sdonthineni(a)nvidia.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> Conflicts: Documentation/arm64/silicon-errata.txt arch/arm64/Kconfig arch/arm64/include/asm/cputype.h arch/arm64/kernel/cpu_errata.c [主线高版本有 ARM64_ERRATUM_4118414 通用配置和 arm64_repeat_tlbi_list[] 数组， 4.19上是每个厂商各自一个独立 Kconfig 选项（QCOM_FALKOR_ERRATUM_1009 模式）。所以这个补丁需要手动适配，按这个模式新增了NVIDIA_OLYMPUS_ERRATUM_TLBI, 并且新增对应的CPU ID 定义。] Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- Documentation/arm64/silicon-errata.txt | 2 ++ arch/arm64/Kconfig | 15 +++++++++++++++ arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 7 +++++++ 4 files changed, 26 insertions(+) diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt index 5016158f5e67..430c0dfbeca1 100644 --- a/Documentation/arm64/silicon-errata.txt +++ b/Documentation/arm64/silicon-errata.txt @@ -82,5 +82,7 @@ stable kernels. | | | | | | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | | Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 | | Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 | | Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 | +| | | | | +| NVIDIA | Olympus Core | T410-OLY-1029 | NVIDIA_OLYMPUS_ERRATUM_TLBI | diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 6498279140fc..3951b0cc8134 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -615,10 +615,25 @@ config QCOM_FALKOR_ERRATUM_1009 TLBI xxIS invalidate maintenance operation. Repeat the TLBI operation one more time to fix the issue. If unsure, say Y. +config NVIDIA_OLYMPUS_ERRATUM_TLBI + bool "NVIDIA Olympus: Completion of affected memory accesses might not be guaranteed by completion of a TLBI" + default y + select ARM64_WORKAROUND_REPEAT_TLBI + help + On NVIDIA Olympus CPU, the completion of a broadcast TLB + invalidation might not guarantee that the memory accesses + expected to be affected by it have completed. Work around + this by issuing an additional broadcast TLBI followed by DSB. + + This is erratum T410-OLY-1029 on the NVIDIA Olympus CPU, + also known as CVE-2025-10263. + + If unsure, say Y. + config QCOM_QDF2400_ERRATUM_0065 bool "QDF2400 E0065: Incorrect GITS_TYPER.ITT_Entry_size" default y help On Qualcomm Datacenter Technologies QDF2400 SoC, ITS hardware reports diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index bdec50291017..c18e48628509 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -100,10 +100,11 @@ #define QCOM_CPU_PART_FALKOR 0xC00 #define QCOM_CPU_PART_KRYO 0x200 #define NVIDIA_CPU_PART_DENVER 0x003 #define NVIDIA_CPU_PART_CARMEL 0x004 +#define NVIDIA_CPU_PART_OLYMPUS 0x010 #define HISI_CPU_PART_TSV110 0xD01 #define HISI_CPU_PART_TSV200 0xD02 #define PHYTIUM_CPU_PART_1500A 0X660 @@ -135,10 +136,11 @@ #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) #define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #define MIDR_QCOM_KRYO MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_KRYO) #define MIDR_NVIDIA_DENVER MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_DENVER) #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_CARMEL) +#define MIDR_NVIDIA_OLYMPUS MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_OLYMPUS) #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110) #define MIDR_HISI_TSV200 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV200) #define MIDR_FT_1500A MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_1500A) #define MIDR_FT_2000AHK MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000AHK) #define MIDR_FT_2000PLUS MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000PLUS) diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index 3b911e8964a7..9ba8cb0e1824 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -924,10 +924,17 @@ const struct arm64_cpu_capabilities arm64_errata[] = { .desc = "Qualcomm Technologies Falkor erratum 1009", .capability = ARM64_WORKAROUND_REPEAT_TLBI, ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0), }, #endif +#ifdef CONFIG_NVIDIA_OLYMPUS_ERRATUM_TLBI + { + .desc = "NVIDIA Olympus erratum T410-OLY-1029", + .capability = ARM64_WORKAROUND_REPEAT_TLBI, + ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS), + }, +#endif #ifdef CONFIG_ARM64_ERRATUM_858921 { /* Cortex-A73 all versions */ .desc = "ARM erratum 858921", .capability = ARM64_WORKAROUND_858921, -- 2.34.1

2 1

[PATCH OLK-5.10] ice: fix double-free of tx_buf skb
by Tengda Wu 16 Jul '26

16 Jul '26

From: Michal Schmidt <mschmidt(a)redhat.com> mainline inclusion from mainline-v7.1-rc1 commit 1a303baa715e6b78d6a406aaf335f87ff35acfcd category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15711 CVE: CVE-2026-53009 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads") Assisted-by: Claude:claude-4.6-opus-high Cursor Signed-off-by: Michal Schmidt <mschmidt(a)redhat.com> Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com> Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-4-686c33… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/intel/ice/ice_txrx.c [commit aa1d3faf71a6 ("ice: Robustify cleaning/completing XDP Tx buffers") is not merged yet, so the `type` field doesn't exist in struct ice_tx_buf. Instead of introducing the `type` field via commit aa1d3faf71a6, just set skb to NULL to prevent double-free.] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_txrx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c index 0fc891861a10..779881dfcce9 100644 --- a/drivers/net/ethernet/intel/ice/ice_txrx.c +++ b/drivers/net/ethernet/intel/ice/ice_txrx.c @@ -2369,6 +2369,9 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_ring *tx_ring) unsigned int count; int tso, csum; + /* record the location of the first descriptor for this packet */ + first = &tx_ring->tx_buf[tx_ring->next_to_use]; + count = ice_xmit_desc_count(skb); if (ice_chk_linearize(skb, count)) { if (__skb_linearize(skb)) @@ -2391,8 +2394,6 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_ring *tx_ring) offload.tx_ring = tx_ring; - /* record the location of the first descriptor for this packet */ - first = &tx_ring->tx_buf[tx_ring->next_to_use]; first->skb = skb; first->bytecount = max_t(unsigned int, skb->len, ETH_ZLEN); first->gso_segs = 1; @@ -2442,6 +2443,7 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_ring *tx_ring) out_drop: dev_kfree_skb_any(skb); + first->skb = NULL; return NETDEV_TX_OK; } -- 2.34.1

2 1

[PATCH OLK-5.10] IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
by Xia Fukun 15 Jul '26

15 Jul '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> stable inclusion from stable-v5.10.259 commit 75ee6e4aa096aa9e7b2dd5c8ff98356e30aceefb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15861 CVE: CVE-2026-53176 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 29e7b925ae6df64894e82ab6419994dc25580a8a upstream. In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Link: https://patch.msgid.link/r/20260602194642.2273217-1-michael.bommarito@gmail… Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/ulp/isert/ib_isert.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index ed375f517e8a..9f8d6113efb4 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -1388,6 +1388,12 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_desc->dma_addr, ISER_RX_SIZE, DMA_FROM_DEVICE); + if (unlikely(wc->byte_len < ISER_HEADERS_LEN)) { + isert_dbg("login request length %u is too short\n", + wc->byte_len); + return; + } + isert_conn->login_req_len = wc->byte_len - ISER_HEADERS_LEN; if (isert_conn->conn) { -- 2.34.1

2 1

[PATCH OLK-6.6 0/3] fix CVE-2026-53132
by Jinjiang Tu 15 Jul '26

15 Jul '26

Eric Dumazet (1): vsock/virtio: fix potential unbounded skb queue Stefano Garzarella (2): vsock/virtio: fix skb overhead accounting to preserve full buf_alloc vsock/virtio: reset connection on receiving queue overflow net/vmw_vsock/virtio_transport_common.c | 31 ++++++++++++++++++++----- 1 file changed, 25 insertions(+), 6 deletions(-) -- 2.43.0

2 4

[PATCH openEuler-1.0-LTS] arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU
by Lin Yujun 15 Jul '26

15 Jul '26

mainline inclusion from mainline-v7.1 commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15600 CVE: CVE-2025-10263 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. [linyujun: 4.19 does not have ARM64_ERRATUM_4118414 or the arm64_repeat_tlbi_list[] array. Adapt using the existing per-vendor config pattern (same as QCOM_FALKOR_ERRATUM_1009) with ERRATA_MIDR_ALL_VERSIONS.] Signed-off-by: Shanker Donthineni <sdonthineni(a)nvidia.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> Conflicts: Documentation/arm64/silicon-errata.txt arch/arm64/Kconfig arch/arm64/include/asm/cputype.h arch/arm64/kernel/cpu_errata.c [主线高版本有 ARM64_ERRATUM_4118414 通用配置和 arm64_repeat_tlbi_list[] 数组， 4.19上是每个厂商各自一个独立 Kconfig 选项（QCOM_FALKOR_ERRATUM_1009 模式）。所以这个补丁需要手动适配，按这个模式新增了NVIDIA_OLYMPUS_ERRATUM_TLBI, 并且新增对应的CPU ID 定义。] Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- Documentation/arm64/silicon-errata.txt | 2 ++ arch/arm64/Kconfig | 15 +++++++++++++++ arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 7 +++++++ 4 files changed, 26 insertions(+) diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt index 5016158f5e67..430c0dfbeca1 100644 --- a/Documentation/arm64/silicon-errata.txt +++ b/Documentation/arm64/silicon-errata.txt @@ -82,5 +82,7 @@ stable kernels. | | | | | | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | | Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 | | Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 | | Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 | +| | | | | +| NVIDIA | Olympus Core | T410-OLY-1029 | NVIDIA_OLYMPUS_ERRATUM_TLBI | diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 6498279140fc..3951b0cc8134 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -615,10 +615,25 @@ config QCOM_FALKOR_ERRATUM_1009 TLBI xxIS invalidate maintenance operation. Repeat the TLBI operation one more time to fix the issue. If unsure, say Y. +config NVIDIA_OLYMPUS_ERRATUM_TLBI + bool "NVIDIA Olympus: Completion of affected memory accesses might not be guaranteed by completion of a TLBI" + default y + select ARM64_WORKAROUND_REPEAT_TLBI + help + On NVIDIA Olympus CPU, the completion of a broadcast TLB + invalidation might not guarantee that the memory accesses + expected to be affected by it have completed. Work around + this by issuing an additional broadcast TLBI followed by DSB. + + This is erratum T410-OLY-1029 on the NVIDIA Olympus CPU, + also known as CVE-2025-10263. + + If unsure, say Y. + config QCOM_QDF2400_ERRATUM_0065 bool "QDF2400 E0065: Incorrect GITS_TYPER.ITT_Entry_size" default y help On Qualcomm Datacenter Technologies QDF2400 SoC, ITS hardware reports diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index bdec50291017..c18e48628509 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -100,10 +100,11 @@ #define QCOM_CPU_PART_FALKOR 0xC00 #define QCOM_CPU_PART_KRYO 0x200 #define NVIDIA_CPU_PART_DENVER 0x003 #define NVIDIA_CPU_PART_CARMEL 0x004 +#define NVIDIA_CPU_PART_OLYMPUS 0x010 #define HISI_CPU_PART_TSV110 0xD01 #define HISI_CPU_PART_TSV200 0xD02 #define PHYTIUM_CPU_PART_1500A 0X660 @@ -135,10 +136,11 @@ #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1) #define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR) #define MIDR_QCOM_KRYO MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_KRYO) #define MIDR_NVIDIA_DENVER MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_DENVER) #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_CARMEL) +#define MIDR_NVIDIA_OLYMPUS MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_OLYMPUS) #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110) #define MIDR_HISI_TSV200 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV200) #define MIDR_FT_1500A MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_1500A) #define MIDR_FT_2000AHK MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000AHK) #define MIDR_FT_2000PLUS MIDR_CPU_MODEL(ARM_CPU_IMP_PHYTIUM, PHYTIUM_CPU_PART_2000PLUS) diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index 3b911e8964a7..9ba8cb0e1824 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -924,10 +924,17 @@ const struct arm64_cpu_capabilities arm64_errata[] = { .desc = "Qualcomm Technologies Falkor erratum 1009", .capability = ARM64_WORKAROUND_REPEAT_TLBI, ERRATA_MIDR_REV(MIDR_QCOM_FALKOR_V1, 0, 0), }, #endif +#ifdef CONFIG_NVIDIA_OLYMPUS_ERRATUM_TLBI + { + .desc = "NVIDIA Olympus erratum T410-OLY-1029", + .capability = ARM64_WORKAROUND_REPEAT_TLBI, + ERRATA_MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS), + }, +#endif #ifdef CONFIG_ARM64_ERRATUM_858921 { /* Cortex-A73 all versions */ .desc = "ARM erratum 858921", .capability = ARM64_WORKAROUND_858921, -- 2.34.1

2 1