- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 v2 0/4] net: Fix CVE-2026-43025
by superdcc97＠163.com 23 Jun '26

23 Jun '26

From: Dong Chenchen <dongchenchen2(a)huawei.com> Fix CVE-2026-43025 Pablo Neira Ayuso (3): netfilter: nf_conntrack_expect: store netns and zone in expectation netfilter: ctnetlink: ignore explicit helper on new expectations netfilter: nf_conntrack_expect: restore helper propagation via expectation Dong Chenchen (1): net: Fix kabi breakage of struct nf_conntrack_expect include/net/netfilter/nf_conntrack_expect.h | 21 ++++++- net/netfilter/nf_conntrack_broadcast.c | 7 ++- net/netfilter/nf_conntrack_core.c | 7 ++- net/netfilter/nf_conntrack_expect.c | 10 +++- net/netfilter/nf_conntrack_h323_main.c | 12 ++-- net/netfilter/nf_conntrack_helper.c | 5 ++ net/netfilter/nf_conntrack_netlink.c | 61 ++++++++------------- net/netfilter/nf_conntrack_sip.c | 2 +- 8 files changed, 72 insertions(+), 53 deletions(-) -- 2.43.0

2 5

[PATCH OLK-6.6 0/4] net: Fix CVE-2026-43025
by superdcc97＠163.com 22 Jun '26

22 Jun '26

From: Sashiko Review <sashiko(a)example.com> Fix CVE-2026-43025 Pablo Neira Ayuso (3): netfilter: nf_conntrack_expect: store netns and zone in expectation netfilter: ctnetlink: ignore explicit helper on new expectations netfilter: nf_conntrack_expect: restore helper propagation via expectation Dong Chenchen (1): net: Fix kabi breakage of struct nf_conntrack_expect include/net/netfilter/nf_conntrack_expect.h | 21 ++++++- net/netfilter/nf_conntrack_broadcast.c | 7 ++- net/netfilter/nf_conntrack_core.c | 7 ++- net/netfilter/nf_conntrack_expect.c | 10 +++- net/netfilter/nf_conntrack_h323_main.c | 12 ++-- net/netfilter/nf_conntrack_helper.c | 5 ++ net/netfilter/nf_conntrack_netlink.c | 61 ++++++++------------- net/netfilter/nf_conntrack_sip.c | 2 +- 8 files changed, 72 insertions(+), 53 deletions(-) -- 2.43.0

2 5

[PATCH OLK-6.6 0/2] net: Fix CVE-2026-45859
by superdcc97＠163.com 22 Jun '26

22 Jun '26

From: Dong Chenchen <dongchenchen2(a)huawei.com> Fix CVE-2026-45859 Florian Westphal (1): netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation Dong Chenchen (1): net: Fix kabi breakage of struct nf_queue_entry include/net/netfilter/nf_queue.h | 1 + net/netfilter/nfnetlink_queue.c | 122 +++++++++++++++++++------------ 2 files changed, 75 insertions(+), 48 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] perf: arm_pmuv3: Use BR_RETIRED for HW branch event if enabled
by Yushan Wang 22 Jun '26

22 Jun '26

From: Ilkka Koskinen <ilkka(a)os.amperecomputing.com> mainline inclusion from mainline-v6.12-rc1 commit 5967a19f1c2ffb530f5d4589ddc4b4afbb6c7bd4 category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9455 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ----------------------------------------------- The PMU driver attempts to use PC_WRITE_RETIRED for the HW branch event, if enabled. However, PC_WRITE_RETIRED counts only taken branches, whereas BR_RETIRED counts also non-taken ones. Furthermore, perf uses HW branch event to calculate branch misses ratio, implying BR_RETIRED is the correct event to count. We keep PC_WRITE_RETIRED still as an option in case BR_RETIRED isn't implemented. Signed-off-by: Ilkka Koskinen <ilkka(a)os.amperecomputing.com> Signed-off-by: Yushan Wang <wangyushan12(a)huawei.com> Signed-off-by: Ying Jiang <jiangying44(a)h-partners.com> --- drivers/perf/arm_pmuv3.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c index 5d750678a70e..d112d904c8c9 100644 --- a/drivers/perf/arm_pmuv3.c +++ b/drivers/perf/arm_pmuv3.c @@ -1419,14 +1419,14 @@ static int __armv8_pmuv3_map_event_id(struct arm_pmu *armpmu, if (event->attr.type == PERF_TYPE_HARDWARE && event->attr.config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS) { - if (test_bit(ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED, - armpmu->pmceid_bitmap)) - return ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED; - if (test_bit(ARMV8_PMUV3_PERFCTR_BR_RETIRED, armpmu->pmceid_bitmap)) return ARMV8_PMUV3_PERFCTR_BR_RETIRED; + if (test_bit(ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED, + armpmu->pmceid_bitmap)) + return ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED; + return HW_OP_UNSUPPORTED; } -- 2.43.0

2 1

[PATCH OLK-6.6] netfilter: nf_tables: use list_del_rcu for netlink hooks
by superdcc97＠163.com 22 Jun '26

22 Jun '26

From: Florian Westphal <fw(a)strlen.de> mainline inclusion from mainline-v7.1-rc2 commit f3224ee463f8f6f6ced7dcdf6081add4f8128527 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15588 CVE: CVE-2026-46324 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers. Add a new helper and use it consistently. Fixes: f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path") Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Conflicts: net/netfilter/nf_tables_api.c [commit 73319a8ee18b ("netfilter: nf_tables: Have a list of nf_hook_ops in nft_hook") introduced the ops_list structure and __nft_netdev_hook_free_rcu() helper which are not present in OLK-6.6. Adapted to use the single hook->ops and existing kfree_rcu()-based nft_netdev_hook_free_rcu() helper instead.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_tables_api.c | 38 +++++++++++++++-------------------- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 919be34ac7a0..8602dc3dfe08 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -333,6 +333,12 @@ static void nft_netdev_hook_free_rcu(struct nft_hook *hook) kfree_rcu(hook, rcu); } +static void nft_netdev_hook_unlink_free_rcu(struct nft_hook *hook) +{ + list_del_rcu(&hook->list); + nft_netdev_hook_free_rcu(hook); +} + static void nft_netdev_unregister_hooks(struct net *net, struct list_head *hook_list, bool release_netdev) @@ -341,10 +347,8 @@ static void nft_netdev_unregister_hooks(struct net *net, list_for_each_entry_safe(hook, next, hook_list, list) { nf_unregister_net_hook(net, &hook->ops); - if (release_netdev) { - list_del(&hook->list); - nft_netdev_hook_free_rcu(hook); - } + if (release_netdev) + nft_netdev_hook_unlink_free_rcu(hook); } } @@ -2106,10 +2110,8 @@ void nf_tables_chain_destroy(struct nft_chain *chain) if (nft_base_chain_netdev(table->family, basechain->ops.hooknum)) { list_for_each_entry_safe(hook, next, - &basechain->hook_list, list) { - list_del_rcu(&hook->list); - nft_netdev_hook_free_rcu(hook); - } + &basechain->hook_list, list) + nft_netdev_hook_unlink_free_rcu(hook); } module_put(basechain->type->owner); if (rcu_access_pointer(basechain->stats)) { @@ -2784,6 +2786,7 @@ static int nf_tables_updchain(struct nft_ctx *ctx, u8 genmask, u8 policy, list_for_each_entry_safe(h, next, &hook.list, list) { if (unregister) nf_unregister_net_hook(ctx->net, &h->ops); + /* hook.list is on stack, no need for list_del_rcu() */ list_del(&h->list); nft_netdev_hook_free_rcu(h); } @@ -8495,10 +8498,8 @@ static void __nft_unregister_flowtable_net_hooks(struct net *net, nf_unregister_net_hook(net, &hook->ops); flowtable->data.type->setup(&flowtable->data, hook->ops.dev, FLOW_BLOCK_UNBIND); - if (release_netdev) { - list_del(&hook->list); - nft_netdev_hook_free_rcu(hook); - } + if (release_netdev) + nft_netdev_hook_unlink_free_rcu(hook); } } @@ -8557,8 +8558,7 @@ static int nft_register_flowtable_net_hooks(struct net *net, break; nft_unregister_flowtable_hook(net, flowtable, hook); - list_del_rcu(&hook->list); - nft_netdev_hook_free_rcu(hook); + nft_netdev_hook_unlink_free_rcu(hook); } return err; @@ -8655,8 +8655,7 @@ static int nft_flowtable_update(struct nft_ctx *ctx, const struct nlmsghdr *nlh, list_for_each_entry_safe(hook, next, &flowtable_hook.list, list) { if (unregister) nft_unregister_flowtable_hook(ctx->net, flowtable, hook); - list_del_rcu(&hook->list); - nft_netdev_hook_free_rcu(hook); + nft_netdev_hook_unlink_free_rcu(hook); } return err; @@ -9149,13 +9148,8 @@ static void nf_tables_flowtable_notify(struct nft_ctx *ctx, static void nf_tables_flowtable_destroy(struct nft_flowtable *flowtable) { - struct nft_hook *hook, *next; - flowtable->data.type->free(&flowtable->data); - list_for_each_entry_safe(hook, next, &flowtable->hook_list, list) { - list_del_rcu(&hook->list); - nft_netdev_hook_free_rcu(hook); - } + nft_hooks_destroy(&flowtable->hook_list); kfree(flowtable->name); module_put(flowtable->data.type->owner); kfree(flowtable); -- 2.43.0

2 1

[PATCH OLK-5.10] ext4: don't cache extent during splitting extent
by Long Li 18 Jun '26

18 Jun '26

From: Zhang Yi <yi.zhang(a)huawei.com> stable inclusion from stable-v5.10.251 commit 8302b5b4aacdbb378f7b1216bb2ee782b5142415 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15152 CVE: CVE-2026-45912 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 8b4b19a2f96348d70bfa306ef7d4a13b0bcbea79 upstream. Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> Reviewed-by: Baokun Li <libaokun1(a)huawei.com> Cc: stable(a)kernel.org Message-ID: <20251129103247.686136-6-yi.zhang(a)huaweicloud.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ext4/extents.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 89a43a8fa808..ac260a66b4d9 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3214,6 +3214,9 @@ static int ext4_split_extent_at(handle_t *handle, BUG_ON((split_flag & (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)) == (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)); + /* Do not cache extents that are in the process of being modified. */ + flags |= EXT4_EX_NOCACHE; + ext_debug(inode, "logical block %llu\n", (unsigned long long)split); ext4_ext_show_leaf(inode, path); @@ -3389,6 +3392,9 @@ static int ext4_split_extent(handle_t *handle, ee_len = ext4_ext_get_actual_len(ex); unwritten = ext4_ext_is_unwritten(ex); + /* Do not cache extents that are in the process of being modified. */ + flags |= EXT4_EX_NOCACHE; + if (map->m_lblk + map->m_len < ee_block + ee_len) { split_flag1 = split_flag & EXT4_EXT_MAY_ZEROOUT; flags1 = flags | EXT4_GET_BLOCKS_PRE_IO; -- 2.52.0

2 1

[PATCH OLK-6.6] xfs: remove xfs_attr_leaf_hasname
by Long Li 18 Jun '26

18 Jun '26

From: Christoph Hellwig <hch(a)lst.de> mainline inclusion from mainline-v6.19-rc6 commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14700 CVE: CVE-2026-43153 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- mainline inclusion from mainline-v6.17-rc7 commit 3a65ea768b8094e4699e72f9ab420eb9e0f3f568 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14700 CVE: CVE-2026-43153 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values. Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read. Cc: stable(a)vger.kernel.org # v5.19+ Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Reported-by: Mark Tinguely <mark.tinguely(a)oracle.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> Conflicts: fs/xfs/libxfs/xfs_attr.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr.c | 75 +++++++++++++--------------------------- 1 file changed, 24 insertions(+), 51 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index 33edf047e0ad..1a2e69d89113 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -49,7 +49,6 @@ STATIC int xfs_attr_shortform_addname(xfs_da_args_t *args); */ STATIC int xfs_attr_leaf_get(xfs_da_args_t *args); STATIC int xfs_attr_leaf_removename(xfs_da_args_t *args); -STATIC int xfs_attr_leaf_hasname(struct xfs_da_args *args, struct xfs_buf **bp); STATIC int xfs_attr_leaf_try_add(struct xfs_da_args *args); /* @@ -866,11 +865,12 @@ xfs_attr_lookup( return xfs_attr_sf_findname(args, NULL, NULL); if (xfs_attr_is_leaf(dp)) { - error = xfs_attr_leaf_hasname(args, &bp); - - if (bp) - xfs_trans_brelse(args->trans, bp); - + error = xfs_attr3_leaf_read(args->trans, args->dp, + 0, &bp); + if (error) + return error; + error = xfs_attr3_leaf_lookup_int(bp, args); + xfs_trans_brelse(args->trans, bp); return error; } @@ -1246,27 +1246,6 @@ xfs_attr_leaf_try_add( return error; } -/* - * Return EEXIST if attr is found, or ENOATTR if not - */ -STATIC int -xfs_attr_leaf_hasname( - struct xfs_da_args *args, - struct xfs_buf **bp) -{ - int error = 0; - - error = xfs_attr3_leaf_read(args->trans, args->dp, 0, bp); - if (error) - return error; - - error = xfs_attr3_leaf_lookup_int(*bp, args); - if (error != -ENOATTR && error != -EEXIST) - xfs_trans_brelse(args->trans, *bp); - - return error; -} - /* * Remove a name from the leaf attribute list structure * @@ -1277,25 +1256,22 @@ STATIC int xfs_attr_leaf_removename( struct xfs_da_args *args) { - struct xfs_inode *dp; - struct xfs_buf *bp; + struct xfs_inode *dp = args->dp; int error, forkoff; + struct xfs_buf *bp; trace_xfs_attr_leaf_removename(args); - /* - * Remove the attribute. - */ - dp = args->dp; - - error = xfs_attr_leaf_hasname(args, &bp); - if (error == -ENOATTR) { + error = xfs_attr3_leaf_read(args->trans, args->dp, 0, &bp); + if (error) + return error; + error = xfs_attr3_leaf_lookup_int(bp, args); + if (error != -EEXIST) { xfs_trans_brelse(args->trans, bp); - if (args->op_flags & XFS_DA_OP_RECOVERY) + if (error == -ENOATTR && (args->op_flags & XFS_DA_OP_RECOVERY)) return 0; return error; - } else if (error != -EEXIST) - return error; + } xfs_attr3_leaf_remove(bp, args); @@ -1319,23 +1295,20 @@ xfs_attr_leaf_removename( * Returns 0 on successful retrieval, otherwise an error. */ STATIC int -xfs_attr_leaf_get(xfs_da_args_t *args) +xfs_attr_leaf_get( + struct xfs_da_args *args) { - struct xfs_buf *bp; - int error; + struct xfs_buf *bp; + int error; trace_xfs_attr_leaf_get(args); - error = xfs_attr_leaf_hasname(args, &bp); - - if (error == -ENOATTR) { - xfs_trans_brelse(args->trans, bp); + error = xfs_attr3_leaf_read(args->trans, args->dp, 0, &bp); + if (error) return error; - } else if (error != -EEXIST) - return error; - - - error = xfs_attr3_leaf_getvalue(bp, args); + error = xfs_attr3_leaf_lookup_int(bp, args); + if (error == -EEXIST) + error = xfs_attr3_leaf_getvalue(bp, args); xfs_trans_brelse(args->trans, bp); return error; } -- 2.52.0

2 1

[PATCH OLK-5.10] hfs: validate record offset in hfsplus_bmap_alloc
by Jinjiang Tu 18 Jun '26

18 Jun '26

From: Yang Chenzhi <yang.chenzhi(a)vivo.com> stable inclusion from stable-v5.10.246 commit 40dfe7a4215a1f20842561ffaf5a6f83a987e75b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11616 CVE: CVE-2025-40349 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 738d5a51864ed8d7a68600b8c0c63fe6fe5c4f20 ] hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] <TASK> [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 <f3> 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] </TASK> When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions. Reported-by: syzbot+356aed408415a56543cd(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67bcb4a6.050a0220.bbfd1.008f.GAE@google.com/ Signed-off-by: Yang Chenzhi <yang.chenzhi(a)vivo.com> Reviewed-by: Viacheslav Dubeyko <slava(a)dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava(a)dubeyko.com> Link: https://lore.kernel.org/r/20250818141734.8559-2-yang.chenzhi@vivo.com Signed-off-by: Viacheslav Dubeyko <slava(a)dubeyko.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/hfsplus/hfsplus_fs.h [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/hfsplus/bnode.c | 41 ---------------------------------------- fs/hfsplus/btree.c | 6 ++++++ fs/hfsplus/hfsplus_fs.h | 42 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 41 deletions(-) diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c index c9c38fddf505..e566cea23827 100644 --- a/fs/hfsplus/bnode.c +++ b/fs/hfsplus/bnode.c @@ -18,47 +18,6 @@ #include "hfsplus_fs.h" #include "hfsplus_raw.h" -static inline -bool is_bnode_offset_valid(struct hfs_bnode *node, int off) -{ - bool is_valid = off < node->tree->node_size; - - if (!is_valid) { - pr_err("requested invalid offset: " - "NODE: id %u, type %#x, height %u, " - "node_size %u, offset %d\n", - node->this, node->type, node->height, - node->tree->node_size, off); - } - - return is_valid; -} - -static inline -int check_and_correct_requested_length(struct hfs_bnode *node, int off, int len) -{ - unsigned int node_size; - - if (!is_bnode_offset_valid(node, off)) - return 0; - - node_size = node->tree->node_size; - - if ((off + len) > node_size) { - int new_len = (int)node_size - off; - - pr_err("requested length has been corrected: " - "NODE: id %u, type %#x, height %u, " - "node_size %u, offset %d, " - "requested_len %d, corrected_len %d\n", - node->this, node->type, node->height, - node->tree->node_size, off, len, new_len); - - return new_len; - } - - return len; -} /* Copy a specified range of bytes from the raw data of a node */ void hfs_bnode_read(struct hfs_bnode *node, void *buf, int off, int len) diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c index 66774f4cb4fd..2211907537fe 100644 --- a/fs/hfsplus/btree.c +++ b/fs/hfsplus/btree.c @@ -392,6 +392,12 @@ struct hfs_bnode *hfs_bmap_alloc(struct hfs_btree *tree) len = hfs_brec_lenoff(node, 2, &off16); off = off16; + if (!is_bnode_offset_valid(node, off)) { + hfs_bnode_put(node); + return ERR_PTR(-EIO); + } + len = check_and_correct_requested_length(node, off, len); + off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap(*pagep); diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h index daf5a828eaaf..ff43287ba29a 100644 --- a/fs/hfsplus/hfsplus_fs.h +++ b/fs/hfsplus/hfsplus_fs.h @@ -562,6 +562,48 @@ static inline __be32 __hfsp_ut2mt(time64_t ut) return cpu_to_be32(lower_32_bits(ut) + HFSPLUS_UTC_OFFSET); } +static inline +bool is_bnode_offset_valid(struct hfs_bnode *node, int off) +{ + bool is_valid = off < node->tree->node_size; + + if (!is_valid) { + pr_err("requested invalid offset: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d\n", + node->this, node->type, node->height, + node->tree->node_size, off); + } + + return is_valid; +} + +static inline +int check_and_correct_requested_length(struct hfs_bnode *node, int off, int len) +{ + unsigned int node_size; + + if (!is_bnode_offset_valid(node, off)) + return 0; + + node_size = node->tree->node_size; + + if ((off + len) > node_size) { + int new_len = (int)node_size - off; + + pr_err("requested length has been corrected: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d, " + "requested_len %d, corrected_len %d\n", + node->this, node->type, node->height, + node->tree->node_size, off, len, new_len); + + return new_len; + } + + return len; +} + /* compatibility */ #define hfsp_mt2ut(t) (struct timespec64){ .tv_sec = __hfsp_mt2ut(t) } #define hfsp_ut2mt(t) __hfsp_ut2mt((t).tv_sec) -- 2.43.0

2 1

[PATCH OLK-5.10] libceph: make decode_pool() more resilient against corrupted osdmaps
by Jinjiang Tu 18 Jun '26

18 Jun '26

From: Ilya Dryomov <idryomov(a)gmail.com> stable inclusion from stable-v5.10.248 commit d061be4c8040ffb1110d537654a038b8b6ad39d2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13431 CVE: CVE-2025-71116 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8c738512714e8c0aa18f8a10c072d5b01c83db39 upstream. If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value. This patch adds explicit bounds checks for each field that is decoded or skipped. Cc: stable(a)vger.kernel.org Reported-by: ziming zhang <ezrakiez(a)gmail.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: Xiubo Li <xiubli(a)redhat.com> Tested-by: ziming zhang <ezrakiez(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- net/ceph/osdmap.c | 116 +++++++++++++++++++++------------------------- 1 file changed, 52 insertions(+), 64 deletions(-) diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c index fe6de7d72752..fe796775e3e9 100644 --- a/net/ceph/osdmap.c +++ b/net/ceph/osdmap.c @@ -790,51 +790,49 @@ static int decode_pool(void **p, void *end, struct ceph_pg_pool_info *pi) ceph_decode_need(p, end, len, bad); pool_end = *p + len; + ceph_decode_need(p, end, 4 + 4 + 4, bad); pi->type = ceph_decode_8(p); pi->size = ceph_decode_8(p); pi->crush_ruleset = ceph_decode_8(p); pi->object_hash = ceph_decode_8(p); - pi->pg_num = ceph_decode_32(p); pi->pgp_num = ceph_decode_32(p); - *p += 4 + 4; /* skip lpg* */ - *p += 4; /* skip last_change */ - *p += 8 + 4; /* skip snap_seq, snap_epoch */ + /* lpg*, last_change, snap_seq, snap_epoch */ + ceph_decode_skip_n(p, end, 8 + 4 + 8 + 4, bad); /* skip snaps */ - num = ceph_decode_32(p); + ceph_decode_32_safe(p, end, num, bad); while (num--) { - *p += 8; /* snapid key */ - *p += 1 + 1; /* versions */ - len = ceph_decode_32(p); - *p += len; + /* snapid key, pool snap (with versions) */ + ceph_decode_skip_n(p, end, 8 + 2, bad); + ceph_decode_skip_string(p, end, bad); } - /* skip removed_snaps */ - num = ceph_decode_32(p); - *p += num * (8 + 8); + /* removed_snaps */ + ceph_decode_skip_map(p, end, 64, 64, bad); + ceph_decode_need(p, end, 8 + 8 + 4, bad); *p += 8; /* skip auid */ pi->flags = ceph_decode_64(p); *p += 4; /* skip crash_replay_interval */ if (ev >= 7) - pi->min_size = ceph_decode_8(p); + ceph_decode_8_safe(p, end, pi->min_size, bad); else pi->min_size = pi->size - pi->size / 2; if (ev >= 8) - *p += 8 + 8; /* skip quota_max_* */ + /* quota_max_* */ + ceph_decode_skip_n(p, end, 8 + 8, bad); if (ev >= 9) { - /* skip tiers */ - num = ceph_decode_32(p); - *p += num * 8; + /* tiers */ + ceph_decode_skip_set(p, end, 64, bad); + ceph_decode_need(p, end, 8 + 1 + 8 + 8, bad); *p += 8; /* skip tier_of */ *p += 1; /* skip cache_mode */ - pi->read_tier = ceph_decode_64(p); pi->write_tier = ceph_decode_64(p); } else { @@ -842,86 +840,76 @@ static int decode_pool(void **p, void *end, struct ceph_pg_pool_info *pi) pi->write_tier = -1; } - if (ev >= 10) { - /* skip properties */ - num = ceph_decode_32(p); - while (num--) { - len = ceph_decode_32(p); - *p += len; /* key */ - len = ceph_decode_32(p); - *p += len; /* val */ - } - } + if (ev >= 10) + /* properties */ + ceph_decode_skip_map(p, end, string, string, bad); if (ev >= 11) { - /* skip hit_set_params */ - *p += 1 + 1; /* versions */ - len = ceph_decode_32(p); - *p += len; + /* hit_set_params (with versions) */ + ceph_decode_skip_n(p, end, 2, bad); + ceph_decode_skip_string(p, end, bad); - *p += 4; /* skip hit_set_period */ - *p += 4; /* skip hit_set_count */ + /* hit_set_period, hit_set_count */ + ceph_decode_skip_n(p, end, 4 + 4, bad); } if (ev >= 12) - *p += 4; /* skip stripe_width */ + /* stripe_width */ + ceph_decode_skip_32(p, end, bad); - if (ev >= 13) { - *p += 8; /* skip target_max_bytes */ - *p += 8; /* skip target_max_objects */ - *p += 4; /* skip cache_target_dirty_ratio_micro */ - *p += 4; /* skip cache_target_full_ratio_micro */ - *p += 4; /* skip cache_min_flush_age */ - *p += 4; /* skip cache_min_evict_age */ - } + if (ev >= 13) + /* target_max_*, cache_target_*, cache_min_* */ + ceph_decode_skip_n(p, end, 16 + 8 + 8, bad); - if (ev >= 14) { - /* skip erasure_code_profile */ - len = ceph_decode_32(p); - *p += len; - } + if (ev >= 14) + /* erasure_code_profile */ + ceph_decode_skip_string(p, end, bad); /* * last_force_op_resend_preluminous, will be overridden if the * map was encoded with RESEND_ON_SPLIT */ if (ev >= 15) - pi->last_force_request_resend = ceph_decode_32(p); + ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad); else pi->last_force_request_resend = 0; if (ev >= 16) - *p += 4; /* skip min_read_recency_for_promote */ + /* min_read_recency_for_promote */ + ceph_decode_skip_32(p, end, bad); if (ev >= 17) - *p += 8; /* skip expected_num_objects */ + /* expected_num_objects */ + ceph_decode_skip_64(p, end, bad); if (ev >= 19) - *p += 4; /* skip cache_target_dirty_high_ratio_micro */ + /* cache_target_dirty_high_ratio_micro */ + ceph_decode_skip_32(p, end, bad); if (ev >= 20) - *p += 4; /* skip min_write_recency_for_promote */ + /* min_write_recency_for_promote */ + ceph_decode_skip_32(p, end, bad); if (ev >= 21) - *p += 1; /* skip use_gmt_hitset */ + /* use_gmt_hitset */ + ceph_decode_skip_8(p, end, bad); if (ev >= 22) - *p += 1; /* skip fast_read */ + /* fast_read */ + ceph_decode_skip_8(p, end, bad); - if (ev >= 23) { - *p += 4; /* skip hit_set_grade_decay_rate */ - *p += 4; /* skip hit_set_search_last_n */ - } + if (ev >= 23) + /* hit_set_grade_decay_rate, hit_set_search_last_n */ + ceph_decode_skip_n(p, end, 4 + 4, bad); if (ev >= 24) { - /* skip opts */ - *p += 1 + 1; /* versions */ - len = ceph_decode_32(p); - *p += len; + /* opts (with versions) */ + ceph_decode_skip_n(p, end, 2, bad); + ceph_decode_skip_string(p, end, bad); } if (ev >= 25) - pi->last_force_request_resend = ceph_decode_32(p); + ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad); /* ignore the rest */ -- 2.43.0

2 1

[PATCH OLK-5.10] xfs: fix freemap adjustments when adding xattrs to leaf blocks
by Long Li 18 Jun '26

18 Jun '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v5.10.251 commit d08976725355b9d54d8332fce223fa281cc304a5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14828 CVE: CVE-2026-43158 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 3eefc0c2b78444b64feeb3783c017d6adc3cd3ce ] xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: <stable(a)vger.kernel.org> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr_leaf.c | 36 +++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 3954bf017c8d..3da4643b26cb 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1472,6 +1472,7 @@ xfs_attr3_leaf_add_work( struct xfs_attr_leaf_name_local *name_loc; struct xfs_attr_leaf_name_remote *name_rmt; struct xfs_mount *mp; + int old_end, new_end; int tmp; int i; @@ -1563,17 +1564,36 @@ xfs_attr3_leaf_add_work( if (be16_to_cpu(entry->nameidx) < ichdr->firstused) ichdr->firstused = be16_to_cpu(entry->nameidx); - ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf)); - tmp = (ichdr->count - 1) * sizeof(xfs_attr_leaf_entry_t) - + xfs_attr3_leaf_hdr_size(leaf); + new_end = ichdr->count * sizeof(struct xfs_attr_leaf_entry) + + xfs_attr3_leaf_hdr_size(leaf); + old_end = new_end - sizeof(struct xfs_attr_leaf_entry); + + ASSERT(ichdr->firstused >= new_end); for (i = 0; i < XFS_ATTR_LEAF_MAPSIZE; i++) { - if (ichdr->freemap[i].base == tmp) { - ichdr->freemap[i].base += sizeof(xfs_attr_leaf_entry_t); + int diff = 0; + + if (ichdr->freemap[i].base == old_end) { + /* + * This freemap entry starts at the old end of the + * leaf entry array, so we need to adjust its base + * upward to accomodate the larger array. + */ + diff = sizeof(struct xfs_attr_leaf_entry); + } else if (ichdr->freemap[i].size > 0 && + ichdr->freemap[i].base < new_end) { + /* + * This freemap entry starts in the space claimed by + * the new leaf entry. Adjust its base upward to + * reflect that. + */ + diff = new_end - ichdr->freemap[i].base; + } + + if (diff) { + ichdr->freemap[i].base += diff; ichdr->freemap[i].size -= - min_t(uint16_t, ichdr->freemap[i].size, - sizeof(xfs_attr_leaf_entry_t)); + min_t(uint16_t, ichdr->freemap[i].size, diff); } /* -- 2.52.0

2 1

[PATCH OLK-6.6] nvmet-tcp: fix race between ICReq handling and queue teardown
by Long Li 18 Jun '26

18 Jun '26

From: Chaitanya Kulkarni <kch(a)nvidia.com> mainline inclusion from mainline-v7.0-rc3 commit 5293a8882c549fab4a878bc76b0b6c951f980a61 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15382 CVE: CVE-2026-46135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes. Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reported-by: Shivam Kumar <skumar47(a)syr.edu> Tested-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Chaitanya Kulkarni <kch(a)nvidia.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/target/tcp.c [not merge main commit 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- drivers/nvme/target/tcp.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 5f85c4a812ab..6ec6912b2b47 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -389,6 +389,19 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) { + /* + * Keep rcv_state at RECV_ERR even for the internal -ESHUTDOWN path. + * nvmet_tcp_handle_icreq() can return -ESHUTDOWN after the ICReq has + * already been consumed and queue teardown has started. + * + * If nvmet_tcp_data_ready() or nvmet_tcp_write_space() queues + * nvmet_tcp_io_work() again before nvmet_tcp_release_queue_work() + * cancels it, the queue must not keep that old receive state. + * Otherwise the next nvmet_tcp_io_work() run can reach + * nvmet_tcp_done_recv_pdu() and try to handle the same ICReq again. + * + * That is why queue->rcv_state needs to be updated before we return. + */ queue->rcv_state = NVMET_TCP_RECV_ERR; if (status == -EPIPE || status == -ECONNRESET) kernel_sock_shutdown(queue->sock, SHUT_RDWR); @@ -938,7 +951,14 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) if (ret < 0) return ret; /* queue removal will cleanup */ + spin_lock_bh(&queue->state_lock); + if (queue->state == NVMET_TCP_Q_DISCONNECTING) { + spin_unlock_bh(&queue->state_lock); + /* Tell nvmet_tcp_socket_error() teardown is in progress. */ + return -ESHUTDOWN; + } queue->state = NVMET_TCP_Q_LIVE; + spin_unlock_bh(&queue->state_lock); nvmet_prepare_receive_pdu(queue); return 0; } -- 2.52.0

2 1

[PATCH OLK-5.10] nvmet-tcp: fix race between ICReq handling and queue teardown
by Long Li 18 Jun '26

18 Jun '26

From: Chaitanya Kulkarni <kch(a)nvidia.com> mainline inclusion from mainline-v7.0-rc3 commit 5293a8882c549fab4a878bc76b0b6c951f980a61 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15382 CVE: CVE-2026-46135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes. Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reported-by: Shivam Kumar <skumar47(a)syr.edu> Tested-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Chaitanya Kulkarni <kch(a)nvidia.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/target/tcp.c [not merge main commit 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- drivers/nvme/target/tcp.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 6b506783ea4f..1f048ad19f6a 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -354,6 +354,19 @@ static void nvmet_tcp_fatal_error(struct nvmet_tcp_queue *queue) static void nvmet_tcp_socket_error(struct nvmet_tcp_queue *queue, int status) { + /* + * Keep rcv_state at RECV_ERR even for the internal -ESHUTDOWN path. + * nvmet_tcp_handle_icreq() can return -ESHUTDOWN after the ICReq has + * already been consumed and queue teardown has started. + * + * If nvmet_tcp_data_ready() or nvmet_tcp_write_space() queues + * nvmet_tcp_io_work() again before nvmet_tcp_release_queue_work() + * cancels it, the queue must not keep that old receive state. + * Otherwise the next nvmet_tcp_io_work() run can reach + * nvmet_tcp_done_recv_pdu() and try to handle the same ICReq again. + * + * That is why queue->rcv_state needs to be updated before we return. + */ queue->rcv_state = NVMET_TCP_RECV_ERR; if (status == -EPIPE || status == -ECONNRESET) kernel_sock_shutdown(queue->sock, SHUT_RDWR); @@ -890,7 +903,14 @@ static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) if (ret < 0) return ret; /* queue removal will cleanup */ + spin_lock_bh(&queue->state_lock); + if (queue->state == NVMET_TCP_Q_DISCONNECTING) { + spin_unlock_bh(&queue->state_lock); + /* Tell nvmet_tcp_socket_error() teardown is in progress. */ + return -ESHUTDOWN; + } queue->state = NVMET_TCP_Q_LIVE; + spin_unlock_bh(&queue->state_lock); nvmet_prepare_receive_pdu(queue); return 0; } -- 2.52.0

2 1

[PATCH OLK-6.6 0/3] Fix CVE-2026-31453
by Long Li 18 Jun '26

18 Jun '26

Fix CVE-2026-31453 Long Li (1): Revert "xfs: fix a UAF when inode item push" Yuto Ohnuki (2): xfs: save ailp before dropping the AIL lock in push callbacks xfs: avoid dereferencing log items after push callbacks fs/xfs/xfs_dquot_item.c | 9 +++++++-- fs/xfs/xfs_inode_item.c | 17 ++++++++--------- fs/xfs/xfs_trace.h | 36 ++++++++++++++++++++++++++++++++---- fs/xfs/xfs_trans_ail.c | 26 +++++++++++++++++++------- 4 files changed, 66 insertions(+), 22 deletions(-) -- 2.52.0

2 4

[PATCH OLK-5.10] xfs: stop reclaim before pushing AIL during unmount
by Long Li 17 Jun '26

17 Jun '26

From: Yuto Ohnuki <ytohnuki(a)amazon.com> stable inclusion from stable-v5.10.252 commit e6cc490048f78b009259a5f032acead9f789c34c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14197 CVE: CVE-2026-31455 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 4f24a767e3d64a5f58c595b5c29b6063a201f1e3 ] The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable. Reported-by: syzbot+652af2b3c5569c4ab63c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable(a)vger.kernel.org # v5.9 Signed-off-by: Yuto Ohnuki <ytohnuki(a)amazon.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> [ dropped xfs_inodegc_stop() call ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/xfs/xfs_mount.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_mount.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 4983fe7eadf0..cb99ac78d904 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -687,8 +687,9 @@ xfs_ifree_unmount( * have been retrying in the background. This will prevent never-ending * retries in AIL pushing from hanging the unmount. * - * Finally, we can push the AIL to clean all the remaining dirty objects, then - * reclaim the remaining inodes that are still in memory at this point in time. + * Stop inodegc and background reclaim before pushing the AIL so that they + * are not running while the AIL is being flushed. Then push the AIL to + * clean all the remaining dirty objects and reclaim the remaining inodes. */ static void xfs_unmount_flush_inodes( @@ -700,9 +701,9 @@ xfs_unmount_flush_inodes( set_bit(XFS_OPSTATE_UNMOUNTING, &mp->m_opstate); - xfs_ail_push_all_sync(mp->m_ail); xfs_inodegc_stop(mp); cancel_delayed_work_sync(&mp->m_reclaim_work); + xfs_ail_push_all_sync(mp->m_ail); xfs_reclaim_inodes(mp); xfs_health_unmount(mp); } -- 2.52.0

2 1

[PATCH OLK-5.10 0/3] Fix CVE-2026-31453
by Long Li 17 Jun '26

17 Jun '26

Fix CVE-2026-31453. Long Li (1): Revert "xfs: fix a UAF when inode item push" Yuto Ohnuki (2): xfs: avoid dereferencing log items after push callbacks xfs: save ailp before dropping the AIL lock in push callbacks fs/xfs/xfs_dquot_item.c | 9 ++++-- fs/xfs/xfs_inode_item.c | 17 ++++++----- fs/xfs/xfs_trace.c | 1 + fs/xfs/xfs_trace.h | 63 ++++++++++++++++++++--------------------- fs/xfs/xfs_trans_ail.c | 26 ++++++++++++----- 5 files changed, 66 insertions(+), 50 deletions(-) -- 2.52.0

2 4

[PATCH OLK-5.10] xfs: delete attr leaf freemap entries when empty
by Long Li 17 Jun '26

17 Jun '26

From: "Darrick J. Wong" <djwong(a)kernel.org> stable inclusion from stable-v5.10.251 commit f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14733 CVE: CVE-2026-43187 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 6f13c1d2a6271c2e73226864a0e83de2770b6f34 ] Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: <stable(a)vger.kernel.org> # v2.6.12 Fixes: 1da177e4c3f415 ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_attr_leaf.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index e953bc44d4d0..3954bf017c8d 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -1575,6 +1575,19 @@ xfs_attr3_leaf_add_work( min_t(uint16_t, ichdr->freemap[i].size, sizeof(xfs_attr_leaf_entry_t)); } + + /* + * Don't leave zero-length freemaps with nonzero base lying + * around, because we don't want the code in _remove that + * matches on base address to get confused and create + * overlapping freemaps. If we end up with no freemap entries + * then the next _add will compact the leaf block and + * regenerate the freemaps. + */ + if (ichdr->freemap[i].size == 0 && ichdr->freemap[i].base > 0) { + ichdr->freemap[i].base = 0; + ichdr->holes = 1; + } } ichdr->usedbytes += xfs_attr_leaf_entsize(leaf, args->index); return 0; -- 2.52.0

2 1

[PATCH OLK-5.10] fuse: reject oversized dirents in page cache
by Long Li 17 Jun '26

17 Jun '26

From: Samuel Page <sam(a)bynar.io> mainline inclusion from mainline-v7.0 commit 51a8de6c50bf947c8f534cd73da4c8f0a13e7bed category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14444 CVE: CVE-2026-31694 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable(a)vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam(a)bynar.io> Reported-by: Qi Tang <tpluszz77(a)gmail.com> Reported-by: Zijun Hu <nightu(a)northwestern.edu> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/fuse/readdir.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c index f18632027d8b..00b2fc180bc7 100644 --- a/fs/fuse/readdir.c +++ b/fs/fuse/readdir.c @@ -41,6 +41,10 @@ static void fuse_add_dirent_to_cache(struct file *file, unsigned int offset; void *addr; + /* Dirent doesn't fit in readdir cache page? Skip caching. */ + if (reclen > PAGE_SIZE) + return; + spin_lock(&fi->rdc.lock); /* * Is cache already completed? Or this entry does not go at the end of -- 2.52.0

2 1

[PATCH OLK-5.10] ntfs: ->d_compare() must not block
by Yifan Qiao 17 Jun '26

17 Jun '26

From: Al Viro <viro(a)zeniv.linux.org.uk> mainline inclusion from mainline-v7.0-rc1 commit ca2a04e84af79596e5cd9cfe697d5122ec39c8ce category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14789 CVE: CVE-2026-43245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ntfs3/dir.c | 5 ++--- fs/ntfs3/inode.c | 12 ++++++------ fs/ntfs3/namei.c | 9 ++++----- fs/ntfs3/xattr.c | 4 ++-- 4 files changed, 14 insertions(+), 16 deletions(-) diff --git a/fs/ntfs3/dir.c b/fs/ntfs3/dir.c index fb438d604040..27713367aa64 100644 --- a/fs/ntfs3/dir.c +++ b/fs/ntfs3/dir.c @@ -390,8 +390,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) if (!dir_emit_dots(file, ctx)) return 0; - /* Allocate PATH_MAX bytes. */ - name = __getname(); + name = kmalloc(PATH_MAX, GFP_KERNEL); if (!name) return -ENOMEM; @@ -470,7 +469,7 @@ static int ntfs_readdir(struct file *file, struct dir_context *ctx) out: - __putname(name); + kfree(name); put_indx_node(node); if (err == -ENOENT) { diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c index b1849c4c48e1..c582eb08d5f8 100644 --- a/fs/ntfs3/inode.c +++ b/fs/ntfs3/inode.c @@ -1280,7 +1280,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, fa |= FILE_ATTRIBUTE_READONLY; /* Allocate PATH_MAX bytes. */ - new_de = __getname(); + new_de = kzalloc(PATH_MAX, GFP_KERNEL); if (!new_de) { err = -ENOMEM; goto out1; @@ -1653,7 +1653,7 @@ struct inode *ntfs_create_inode(struct user_namespace *mnt_userns, ntfs_mark_rec_free(sbi, ino); out2: - __putname(new_de); + kfree(new_de); kfree(rp); out1: @@ -1676,7 +1676,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) struct ATTR_FILE_NAME *de_name; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1699,7 +1699,7 @@ int ntfs_link_inode(struct inode *inode, struct dentry *dentry) err = ni_add_name(ntfs_i(d_inode(dentry->d_parent)), ni, de); out: - __putname(de); + kfree(de); return err; } @@ -1723,7 +1723,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) return -EINVAL; /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kzalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -1761,7 +1761,7 @@ int ntfs_unlink_inode(struct inode *dir, const struct dentry *dentry) out: ni_unlock(ni); - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c index 18330d982b07..49f5246abfdd 100644 --- a/fs/ntfs3/namei.c +++ b/fs/ntfs3/namei.c @@ -66,7 +66,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, u32 flags) { struct ntfs_inode *ni = ntfs_i(dir); - struct cpu_str *uni = __getname(); + struct cpu_str *uni = kmalloc(PATH_MAX, GFP_KERNEL); struct inode *inode; int err; @@ -83,7 +83,7 @@ static struct dentry *ntfs_lookup(struct inode *dir, struct dentry *dentry, inode = dir_search_u(dir, uni, NULL); ni_unlock(ni); } - __putname(uni); + kfree(uni); } return d_splice_alias(inode, dentry); @@ -280,8 +280,7 @@ static int ntfs_rename(struct inode *dir, return err; } - /* Allocate PATH_MAX bytes. */ - de = __getname(); + de = kmalloc(PATH_MAX, GFP_KERNEL); if (!de) return -ENOMEM; @@ -325,7 +324,7 @@ static int ntfs_rename(struct inode *dir, ni_unlock(ni); ni_unlock(dir_ni); out: - __putname(de); + kfree(de); return err; } diff --git a/fs/ntfs3/xattr.c b/fs/ntfs3/xattr.c index 24d739000c80..ddec586d4de6 100644 --- a/fs/ntfs3/xattr.c +++ b/fs/ntfs3/xattr.c @@ -533,7 +533,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, void *buf; /* Allocate PATH_MAX bytes. */ - buf = __getname(); + buf = kmalloc(PATH_MAX, GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); @@ -566,7 +566,7 @@ static struct posix_acl *ntfs_get_acl_ex(struct user_namespace *mnt_userns, if (!IS_ERR(acl)) set_cached_acl(inode, type, acl); - __putname(buf); + kfree(buf); return acl; } -- 2.52.0

2 1

社区update版本合入截止时间和构建时间调整公示
by Xushanshan(Sassa,openEuler) 16 Jun '26

16 Jun '26

Add kernel sig 发件人: Xushanshan(Sassa,openEuler) <xushanshan3(a)huawei.com> 发送时间: 2026年6月16日 23:17 收件人: release(a)openeuler.org 抄送: tc(a)openeuler.org; qa(a)openeuler.org; dev(a)openeuler.org; cicd(a)openeuler.org; kernel(a)openeuler.org 主题: [Dev] 社区update版本合入截止时间和构建时间调整公示 Hi ALL：经RM sig评审，update 版本的构建时间调整为周一合入，周三发布；整体触发背景和结论如下，如有相关的意见，可在06/22前反馈。一：变更背景：社区构建资源紧张，内核&用户态等PR集中提交的情况下，资源冲突，PR高峰期合入要等待2-3小时，构建出包10+小时。从工程能力和版本发布周期等维度讨论了部分优化措施，过程中识别到主干Next分支和update版本发布时间存在重叠（周三12点截止PR合入，周五出版本），资源抢占较多，影响两个版本，因此申请错开两个版本。其他优化措施见四；二：决策结论：社区update版本的PR截止合入时间，调整为周一16点，版本发布时间调整为周三晚；update变更开始执行时间：0622 三：修改后的合入时间建议：版本类型版本 PR截止合入时间版本发布时间内核用户态源码仓制品仓源码仓制品仓开发分支（保持不变） Next主干开发分支(当前24.03 LTS SP4) 周三16：00 周三18：00 / 周三18：00 周五晚维护版本 24.03 LTS SP3 update 周一16:00 周一18：00 / 周一18:00 周三晚 24.03 LTS SP1 update 22.03 LTS SP4 update 20.03 LTS SP4 四：其他工程能力优化措施和进展：问题改进措施进展内核源码编译门禁执行时间长 1、新增蓝区arm物理机集群，对接oe社区Jenkins 2、该集群用于内核源码编译，并根据负载情况进行扩缩容 done 检查类门禁（trigger门禁）排队时间长 1、增加trigger机器资源(done) 2、能自动停止同一个pr中已经失效的但还在排队或者执行中的任务目标730 多个版本集中在同一时间构建，导致EulerMaker负载大，调度慢 1、update版本和SP版本严格管控合入时间，按天错开构建时间(done) 2、EulerMaker进行重构，从架构层面解决调度问题目标930 构建流程存在断连，每个步骤都通过定时触发，而不是前后依赖触发，导致端到端构建总时间过长（20点开始包构建，凌晨6点左右出包，端到端需要10小时） 1、通过Jenkins流水线能力连编排EulerMaker everyting工程构建，ISO镜像构建，EulerMaker epol工程构建，docker镜像和虚拟机镜像构建，openQA测试等全流程，端到端时间缩短到4-6小时 done

1 0

[PATCH OLK-6.6 0/1] ACPI: CPPC: Move reference performance to capabilities
by Pengjie Zhang 16 Jun '26

16 Jun '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.1-rc1 commit 8505bfb4e4eca28ef1b20d3369435ec2d6a125c6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- Currently, the Reference Performance register is read every time the CPU frequency is sampled in cppc_get_perf_ctrs(). This function is on the hot path of the cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves reference_perf from the dynamic feedback counters structure (cppc_perf_fb_ctrs) to the static capabilities structure (cppc_perf_caps). Pengjie Zhang (1): ACPI: CPPC: Move reference performance to capabilities drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++---------------- drivers/cpufreq/cppc_cpufreq.c | 2 +- include/acpi/cppc_acpi.h | 2 +- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.33.0

2 2

[PATCH OLK-6.6] Revert "!20376 [OLK-6.6] Support 1G hugetlb for CSV3 and other CSV3 optimizations."
by Tengda Wu 16 Jun '26

16 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9430 -------------------------------- This reverts commit 14e583ccc8af52f03a29ea704970e8e4b28966c2, reversing changes made to adbe47b6cb32f8ea1644528dc0efce88d043f126. It introduces a x86_64 check_build error: In file included from drivers/char/tpm/tpm_hygon.c:18: ./include/linux/psp-hygon.h:51:9: error: redeclaration of enumerator ‘CSV3_CMD_LAUNCH_FINISH_EX’ 51 | CSV3_CMD_LAUNCH_FINISH_EX = 0x204, | ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/psp-hygon.h:48:9: note: previous definition of ‘CSV3_CMD_LAUNCH_FINISH_EX’ with type ‘int’ 48 | CSV3_CMD_LAUNCH_FINISH_EX = 0x204, | ^~~~~~~~~~~~~~~~~~~~~~~~~ Revert it to avoid compilation issues. Fixes: 78d3389e7d6b ("crypto: ccp: Define CSV3 LAUNCH_FINISH_EX command id") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/crypto/ccp/hygon/csv-dev.c | 1 - include/linux/psp-hygon.h | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/crypto/ccp/hygon/csv-dev.c b/drivers/crypto/ccp/hygon/csv-dev.c index 03f7e6db0e39..adf6bd89304f 100644 --- a/drivers/crypto/ccp/hygon/csv-dev.c +++ b/drivers/crypto/ccp/hygon/csv-dev.c @@ -65,7 +65,6 @@ int csv_cmd_buffer_len(int cmd) case CSV3_CMD_RECEIVE_ENCRYPT_DATA: return sizeof(struct csv3_data_receive_encrypt_data); case CSV3_CMD_RECEIVE_ENCRYPT_CONTEXT: - case CSV3_CMD_LAUNCH_FINISH_EX: return sizeof(struct csv3_data_launch_finish_ex); return sizeof(struct csv3_data_receive_encrypt_context); case CSV3_CMD_LAUNCH_FINISH_EX: return sizeof(struct csv3_data_launch_finish_ex); default: return 0; diff --git a/include/linux/psp-hygon.h b/include/linux/psp-hygon.h index 29f63bbfa1e1..0b81edaf2d56 100644 --- a/include/linux/psp-hygon.h +++ b/include/linux/psp-hygon.h @@ -45,7 +45,6 @@ enum csv3_cmd { CSV3_CMD_SET_GUEST_PRIVATE_MEMORY = 0x200, CSV3_CMD_LAUNCH_ENCRYPT_DATA = 0x201, CSV3_CMD_LAUNCH_ENCRYPT_VMCB = 0x202, - CSV3_CMD_LAUNCH_FINISH_EX = 0x204, /* Guest NPT(Nested Page Table) management commands */ CSV3_CMD_UPDATE_NPT = 0x203, CSV3_CMD_LAUNCH_FINISH_EX = 0x204, -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] ACPI: CPPC: Move reference performance to capabilities
by Pengjie Zhang 16 Jun '26

16 Jun '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.1-rc1 commit 8505bfb4e4eca28ef1b20d3369435ec2d6a125c6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- Currently, the Reference Performance register is read every time the CPU frequency is sampled in cppc_get_perf_ctrs(). This function is on the hot path of the cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves reference_perf from the dynamic feedback counters structure (cppc_perf_fb_ctrs) to the static capabilities structure (cppc_perf_caps). Pengjie Zhang (1): ACPI: CPPC: Move reference performance to capabilities drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++---------------- drivers/cpufreq/cppc_cpufreq.c | 2 +- include/acpi/cppc_acpi.h | 2 +- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.33.0

1 1

回复：[kernel] 驱动 Hht2dr 内核合入申请
by 刘俊豪 16 Jun '26

16 Jun '26

尊敬的 openEuler SIG 团队：您好！我司华澜微电子股份有限公司申请将 Hst2dr驱动（用于SAS HBA）加入 openEuler 内核，便于后续业务部署。烦请协助推进驱动合入相关事宜。如需要补充任何信息或材料，请随时与我联系。联系人：刘俊豪电子邮箱：junhao.liu(a)sage-micro.com.cn 感谢您的支持！华澜微电子股份有限公司 2026 年 06 月 11 日

2 1

[PATCH OLK-6.6 0/1] ACPI: CPPC: Move reference performance to capabilities
by Pengjie Zhang 15 Jun '26

15 Jun '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.1-rc1 commit 8505bfb4e4eca28ef1b20d3369435ec2d6a125c6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- Currently, the Reference Performance register is read every time the CPU frequency is sampled in cppc_get_perf_ctrs(). This function is on the hot path of the cpufreq driver. Reference Performance indicates the performance level that corresponds to the Reference Counter incrementing and is not expected to change dynamically during runtime (unlike the Delivered and Reference counters). Reading this register in the hot path incurs unnecessary overhead, particularly on platforms where CPC registers are located in the PCC (Platform Communication Channel) subspace. This patch moves reference_perf from the dynamic feedback counters structure (cppc_perf_fb_ctrs) to the static capabilities structure (cppc_perf_caps). Pengjie Zhang (1): ACPI: CPPC: Move reference performance to capabilities drivers/acpi/cppc_acpi.c | 41 ++++++++++++++++++---------------- drivers/cpufreq/cppc_cpufreq.c | 2 +- include/acpi/cppc_acpi.h | 2 +- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.33.0

1 0

[PATCH OLK-6.6 0/4] Relax stage2 device MMIO mapping to Normal-NC
by Tian Zheng 15 Jun '26

15 Jun '26

elax stage2 mapping from hardcoded DEVICE_nGnRE to Normal-NC for vfio-pci devices via an opt-in VMA flag (VM_ALLOW_ANY_UNCACHED). This restores guest control over device MMIO attributes, enabling write-combining (Normal-NC) when requested by guest drivers. DEVICE_nGnRE is not safer than Normal-NC; platform safety depends on PCIe AER/DPC containment, not stage2 type. Performance: mlx5 RDMA VFIO latency improves from ~2.95us to ~2.45us (bare-metal level) as BlueFlame doorbell WC becomes effective. Non-PCI devices (e.g. GICv2) unaffected. Ankit Agrawal (4): KVM: arm64: Introduce new flag for non-cacheable IO memory mm: Introduce new flag to indicate wc safe KVM: arm64: Set io memory s2 pte as normalnc for vfio pci device vfio: Convey kvm that the vfio-pci device is wc safe arch/arm64/include/asm/kvm_pgtable.h | 4 +++- arch/arm64/include/asm/memory.h | 2 ++ arch/arm64/kvm/hyp/pgtable.c | 24 +++++++++++++++++++----- arch/arm64/kvm/mmu.c | 14 ++++++++++---- drivers/vfio/pci/vfio_pci_core.c | 19 ++++++++++++++++++- include/linux/mm.h | 14 ++++++++++++++ 6 files changed, 66 insertions(+), 11 deletions(-) -- 2.33.0

1 4

[PATCH OLK-6.6 0/1] KVM: arm64: Reject HDBSS enable when dirty ring is active
by Tian Zheng 15 Jun '26

15 Jun '26

Enabling HDBSS alongside the dirty ring leads to a guest hang after live migration. This occurs because HDBSS currently lacks support for the dirty ring data structures, preventing proper dirty page tracking and synchronization during migration. Add a check in kvm_cap_arm_enable_hdbss() to return -EINVAL if the dirty ring is already in use to prevent this conflicting and unsafe configuration. patchapply (1): KVM: arm64: Reject HDBSS enable when dirty ring is active arch/arm64/kvm/arm.c | 5 +++++ 1 file changed, 5 insertions(+) -- 2.33.0

1 0

[PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 15 Jun '26

15 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Fixes: 36fc586982d7 ("irqchip/gicv3-its: Add workaround for HIP09/HIP10/HIP10C/HIP12 erratum 162100803/162200807/162400807/165010802") Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..e3abbf0d9a4d 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,10 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time required to clear the cache once is approximately 100 + * nanoseconds. Based on a timeout period of 1 second, we set the + * number of timeout attempts to 1,000,000. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] hugetlbfs: prevent filesystem stacking of hugetlbfs
by Zeng Heng 15 Jun '26

15 Jun '26

From: Mike Kravetz <mike.kravetz(a)oracle.com> mainline inclusion from mainline-v5.9-rc1 commit 15568299b7d9988063afce60731df605ab236e2a category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9351 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot found issues with having hugetlbfs on a union/overlay as reported in [1]. Due to the limitations (no write) and special functionality of hugetlbfs, it does not work well in filesystem stacking. There are no know use cases for hugetlbfs stacking. Rather than making modifications to get hugetlbfs working in such environments, simply prevent stacking. [1] https://lore.kernel.org/linux-mm/000000000000b4684e05a2968ca6@google.com/ Reported-by: syzbot+d6ec23007e951dadf3de(a)syzkaller.appspotmail.com Suggested-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Miklos Szeredi <mszeredi(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Colin Walters <walters(a)verbum.org> Link: http://lkml.kernel.org/r/80f869aa-810d-ef6c-8888-b46cee135907@oracle.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: fs/hugetlbfs/inode.c [Fix context conflicts.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- fs/hugetlbfs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 39a4d1f820d2..6825c870d0b5 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1452,6 +1452,12 @@ hugetlbfs_fill_super(struct super_block *sb, void *data, int silent) sb->s_magic = HUGETLBFS_MAGIC; sb->s_op = &hugetlbfs_ops; sb->s_time_gran = 1; + + /* + * Due to the special and limited functionality of hugetlbfs, it does + * not work well as a stacking filesystem. + */ + sb->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; sb->s_root = d_make_root(hugetlbfs_get_root(sb, &config)); if (!sb->s_root) goto out_free; -- 2.43.0

2 1

[PATCH OLK-6.6 0/1] KVM: arm64: Reject HDBSS enable when dirty ring is active
by Tian Zheng 15 Jun '26

15 Jun '26

Enabling HDBSS alongside the dirty ring leads to a guest hang after live migration. This occurs because HDBSS currently lacks support for the dirty ring data structures, preventing proper dirty page tracking and synchronization during migration. Add a check in kvm_cap_arm_enable_hdbss() to return -EINVAL if the dirty ring is already in use to prevent this conflicting and unsafe configuration. patchapply (1): KVM: arm64: Reject HDBSS enable when dirty ring is active arch/arm64/kvm/arm.c | 5 +++++ 1 file changed, 5 insertions(+) -- 2.33.0

1 0

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

2 1

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

2 1

[PATCH OLK-6.6] x86/kexec: Disable KCOV instrumentation after load_segments()
by Jinjie Ruan 12 Jun '26

12 Jun '26

From: Aleksandr Nogikh <nogikh(a)google.com> stable inclusion from stable-v6.12.93 commit 593d67032544b9271094fc9b43e437e017cb2b2f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14889 CVE: CVE-2026-43331 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 917e3ad3321e75ca0223d5ccf26ceda116aa51e1 ] The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ] Fixes: 0d345996e4cb ("x86/kernel: increase kcov coverage under arch/x86/kernel folder") Signed-off-by: Aleksandr Nogikh <nogikh(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260325154825.551191-1-nogikh@google.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/Makefile [context conflict.] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/Makefile | 14 ++++++++++++++ arch/x86/mm/Makefile | 2 ++ 2 files changed, 16 insertions(+) diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 341422135d9d..767bbcfd4dc3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -39,6 +39,20 @@ KMSAN_SANITIZE_nmi.o := n KCOV_INSTRUMENT_head$(BITS).o := n KCOV_INSTRUMENT_sev.o := n +# Disable KCOV to prevent crashes during kexec: load_segments() invalidates +# the GS base, which KCOV relies on for per-CPU data. +# +# As KCOV and KEXEC compatibility should be preserved (e.g. syzkaller is +# using it to collect crash dumps during kernel fuzzing), disabling +# KCOV for KEXEC kernels is not an option. Selectively disabling KCOV +# instrumentation for individual affected functions can be fragile, while +# adding more checks to KCOV would slow it down. +# +# As a compromise solution, disable KCOV instrumentation for the whole +# source code file. If its coverage is ever needed, other approaches +# should be considered. +KCOV_INSTRUMENT_machine_kexec_64.o := n + CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace obj-y += head_$(BITS).o diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index c9d9bee63d7d..d8f01c0f717b 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -5,6 +5,8 @@ KCOV_INSTRUMENT_mem_encrypt.o := n KCOV_INSTRUMENT_mem_encrypt_amd.o := n KCOV_INSTRUMENT_mem_encrypt_identity.o := n KCOV_INSTRUMENT_pgprot.o := n +# See the "Disable KCOV" comment in arch/x86/kernel/Makefile. +KCOV_INSTRUMENT_physaddr.o := n KASAN_SANITIZE_mem_encrypt.o := n KASAN_SANITIZE_mem_encrypt_amd.o := n -- 2.34.1

2 1

[PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..e3abbf0d9a4d 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,10 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time required to clear the cache once is approximately 100 + * nanoseconds. Based on a timeout period of 1 second, we set the + * number of timeout attempts to 1,000,000. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

2 1

[PATCH OLK-5.10] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index ea519c4fa7b3..3bb9c0dced6e 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1205,10 +1205,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index 2b00359e4825..bf6251fa5c3d 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1169,10 +1169,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH OLK-6.6] netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
by superdcc97＠163.com 12 Jun '26

12 Jun '26

From: Qi Tang <tpluszz77(a)gmail.com> stable inclusion from stable-v6.6.134 commit 2898080c054ea4d6ddfaaf21bbedbc229a9a8376 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14558 CVE: CVE-2026-43026 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 35177c6877134a21315f37d57a5577846225623e ] ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Qi Tang <tpluszz77(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_conntrack_netlink.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 67a0762915e3..90c32031bcf1 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -3571,6 +3571,12 @@ ctnetlink_alloc_expect(const struct nlattr * const cda[], struct nf_conn *ct, exp, nf_ct_l3num(ct)); if (err < 0) goto err_out; +#if IS_ENABLED(CONFIG_NF_NAT) + } else { + memset(&exp->saved_addr, 0, sizeof(exp->saved_addr)); + memset(&exp->saved_proto, 0, sizeof(exp->saved_proto)); + exp->dir = 0; +#endif } return exp; err_out: -- 2.43.0

2 1

[PATCH] [PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..dbceebb97ed4 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,9 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time for each loop operation is approximately 100ns to 500ns, + * and the ITS should clear the DT cache within 1,000,000 loops. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

1 0

[PATCH OLK-5.10] mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()
by Jinjiang Tu 11 Jun '26

11 Jun '26

From: Breno Leitao <leitao(a)debian.org> stable inclusion from stable-v6.6.136 commit 115a5266749dcde7fe4127e8623d19c752088f69 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14332 CVE: CVE-2026-31586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Dennis Zhou <dennis(a)kernel.org> Reviewed-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: David Hildenbrand <david(a)kernel.org> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Josef Bacik <josef(a)toxicpanda.com> Cc: JP Kobryn <inwardvessel(a)gmail.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Martin KaFai Lau <martin.lau(a)linux.dev> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: mm/backing-dev.c [Wupeng Ma: context conflicts] Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/backing-dev.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/backing-dev.c b/mm/backing-dev.c index bc406d62c617..ffc14382dc53 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -537,12 +537,13 @@ static void cgwb_release_workfn(struct work_struct *work) wb_shutdown(wb); css_put(wb->memcg_css); - css_put(wb->blkcg_css); - mutex_unlock(&wb->bdi->cgwb_release_mutex); /* triggers blkg destruction if no online users left */ blkcg_unpin_online(blkcg); + css_put(wb->blkcg_css); + mutex_unlock(&wb->bdi->cgwb_release_mutex); + fprop_local_destroy_percpu(&wb->memcg_completions); wb_exit(wb); call_rcu(&wb->rcu, cgwb_free_rcu); -- 2.43.0

2 1

[PATCH OLK-6.6 0/13] Update Share Pool
by Yin Tirui 11 Jun '26

11 Jun '26

Zhou Guanghui (1): mm: reserve address range for svsp fs/hugetlbfs/inode.c | 13 +++++ include/linux/ascend_vm.h | 69 ++++++++++++++++++++++++++ include/linux/share_pool.h | 11 ++-- include/uapi/asm-generic/mman-common.h | 1 + mm/Makefile | 1 + mm/ascend_vm.c | 21 ++++++++ mm/mmap.c | 15 ++++-- 7 files changed, 125 insertions(+), 6 deletions(-) create mode 100644 include/linux/ascend_vm.h create mode 100644 mm/ascend_vm.c -- 2.43.0

2 14

[PATCH OLK-5.10] jbd2: limit checkpoint buffers scanned per j_list_lock hold during shrink
by Zizhi Wo 10 Jun '26

10 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9375 -------------------------------- When the shrinker walks a journal's checkpoint list via jbd2_journal_shrink_checkpoint_list(), it holds j_list_lock across each call to journal_shrink_one_cp_list() and only releases it when need_resched() or spin_needbreak() becomes true. journal_shrink_one_cp_list() charges the scan budget (nr_to_scan) only for buffers it actually frees. In JBD2_SHRINK_BUSY_SKIP mode, when metadata is heavily contended, most buffers are busy and cannot be freed, so "nr_to_scan" decreases slowly and the loop keeps walking the list for a long time. On large journals under heavy ext4 writeback, a single shrinker invocation can therefore hold j_list_lock long enough to starve other CPUs spinning for the same lock, triggering softlockups. Fix this by introducing a user-configurable per-hold budget that bounds the number of checkpoint buffers examined while j_list_lock is held, preventing the shrinker from walking the list for an unbounded time. The cap is disabled by default (value 0, preserving the previous behaviour) and can be enabled at runtime via /sys/module/jbd2/parameters/shrink_batch. Fixes: 82c2be921b1a ("jbd2,ext4: add a shrinker to release checkpointed buffers") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/jbd2/checkpoint.c | 48 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index 727f3505280c..ca7d60f6a858 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -19,10 +19,23 @@ #include <linux/jbd2.h> #include <linux/errno.h> #include <linux/slab.h> #include <linux/blkdev.h> #include <trace/events/jbd2.h> +#include <linux/moduleparam.h> + +/* + * Max number of checkpoint buffers to examine while holding j_list_lock + * in a single pass. + * + * Tunable at runtime via /sys/module/jbd2/parameters/shrink_batch. + * A value of 0 disables the per-hold cap (legacy behaviour). + */ +static unsigned int jbd2_shrink_batch; +module_param_named(shrink_batch, jbd2_shrink_batch, uint, 0644); +MODULE_PARM_DESC(shrink_batch, + "Max checkpoint buffers examined per j_list_lock hold during shrink (0 = unlimited)"); /* * Unlink a buffer from a transaction checkpoint list. * * Called with j_list_lock held. @@ -364,11 +377,12 @@ enum shrink_type {SHRINK_DESTROY, SHRINK_BUSY_STOP, SHRINK_BUSY_SKIP}; * * Called with j_list_lock held. */ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, enum shrink_type type, - bool *released) + bool *released, + unsigned long *scan_budget) { struct journal_head *last_jh; struct journal_head *next_jh = jh; unsigned long nr_freed = 0; int ret; @@ -383,10 +397,22 @@ static unsigned long journal_shrink_one_cp_list(struct journal_head *jh, next_jh = jh->b_cpnext; if (type == SHRINK_DESTROY) { ret = __jbd2_journal_remove_checkpoint(jh); } else { + /* + * Charge budget per examined buffer, not per freed one, + * so a run of busy buffers (the 'continue' path below, + * freeing nothing) still bounds how long one j_list_lock + * hold walks the checkpoint list. + */ + if (scan_budget) { + if (*scan_budget == 0) + break; + (*scan_budget)--; + } + ret = jbd2_journal_try_remove_checkpoint(jh); if (ret < 0) { if (type == SHRINK_BUSY_SKIP) continue; break; @@ -422,12 +448,23 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, bool __maybe_unused released; tid_t first_tid = 0, last_tid = 0, next_tid = 0; tid_t tid = 0; unsigned long nr_freed = 0; unsigned long freed; + unsigned long scan_budget; + unsigned int batch = READ_ONCE(jbd2_shrink_batch); again: + /* + * Reset the per-hold examination budget on every (re)acquire of + * j_list_lock: one hold examines at most `batch` buffers, decoupled + * from journal size, list length and busy ratio, so the lock hold + * stays short even when the whole list is busy and nothing is freed. + * batch == 0 means no cap, exactly the legacy behaviour. + */ + scan_budget = batch; + spin_lock(&journal->j_list_lock); if (!journal->j_checkpoint_transactions) { spin_unlock(&journal->j_list_lock); goto out; } @@ -452,13 +489,17 @@ unsigned long jbd2_journal_shrink_checkpoint_list(journal_t *journal, transaction = next_transaction; next_transaction = transaction->t_cpnext; tid = transaction->t_tid; freed = journal_shrink_one_cp_list(transaction->t_checkpoint_list, - SHRINK_BUSY_SKIP, &released); + SHRINK_BUSY_SKIP, &released, + batch ? &scan_budget : NULL); nr_freed += freed; (*nr_to_scan) -= min(*nr_to_scan, freed); + + if (batch && scan_budget == 0) + break; if (*nr_to_scan == 0) break; if (need_resched() || spin_needbreak(&journal->j_list_lock)) break; } while (transaction != last_transaction); @@ -505,12 +546,13 @@ void __jbd2_journal_clean_checkpoint_list(journal_t *journal, bool destroy) last_transaction = transaction->t_cpprev; next_transaction = transaction; do { transaction = next_transaction; next_transaction = transaction->t_cpnext; + /* destroy/clean path: clear everything, no scan budget */ journal_shrink_one_cp_list(transaction->t_checkpoint_list, - type, &released); + type, &released, NULL); /* * This function only frees up some memory if possible so we * dont have an obligation to finish processing. Bail out if * preemption requested: */ -- 2.52.0

2 1

[PATCH OLK-6.6 0/2] xfrm: Fix CVE-2026-43091 RCU use-after-free in policy netns exit
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Sashiko Review <sashiko(a)example.com> This patch series fixes CVE-2026-43091 in the OLK-6.6 branch. * Patch 1: Add synchronize_rcu() before freeing policy hash tables to prevent RCU use-after-free during policy netns exit. * Patch 2: Move the RCU sync from per-netns .exit to .pre_exit to avoid O(N) RCU grace periods during batch netns cleanup. Steffen Klassert (1): xfrm: Wait for RCU readers during policy netns exit Usama Arif (1): xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit net/xfrm/xfrm_policy.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6 0/2] CVE-2026-31588
by Xinyu Zheng 10 Jun '26

10 Jun '26

Sean Christopherson (1): KVM: x86: Use scratch field in MMIO fragment to hold small write values Xinyu Zheng (1): fix "KVM: x86: Use scratch field in MMIO fragment to hold small write values" KABI CRC break issue arch/x86/include/uapi/asm/kvm.h | 3 +++ arch/x86/kvm/x86.c | 15 ++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] CVE-2026-31588
by Xinyu Zheng 10 Jun '26

10 Jun '26

Sean Christopherson (1): KVM: x86: Use scratch field in MMIO fragment to hold small write values Xinyu Zheng (1): fix "KVM: x86: Use scratch field in MMIO fragment to hold small write values" KABI CRC break issue arch/x86/include/uapi/asm/kvm.h | 3 +++ arch/x86/kvm/x86.c | 15 ++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6] bpf: Fix bpf_xdp_store_bytes proto for read-only arg
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Paul Chaignon <paul.chaignon(a)gmail.com> stable inclusion from stable-v6.6.128 commit ddc34a1b85505c919026ddc82fafdada9a160b15 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15180 CVE: CVE-2026-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6557f1565d779851c4db9c488c49c05a47a6e72f ] While making some maps in Cilium read-only from the BPF side, we noticed that the bpf_xdp_store_bytes proto is incorrect. In particular, the verifier was throwing the following error: ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4 nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE. The verifier checks the helper's memory access to R3 in check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails. Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading from uninitialized memory. This patch simply fixes the expected argument type to match that of bpf_skb_store_bytes. Fixes: 3f364222d032 ("net: xdp: introduce bpf_xdp_pointer utility routine") Signed-off-by: Paul Chaignon <paul.chaignon(a)gmail.com> Link: https://lore.kernel.org/r/9fa3c9f72d806e82541071c4df88b8cba28ad6a9.17698754… Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/core/filter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/filter.c b/net/core/filter.c index a4691cee3994..26b715a89e29 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -4128,7 +4128,7 @@ static const struct bpf_func_proto bpf_xdp_store_bytes_proto = { .ret_type = RET_INTEGER, .arg1_type = ARG_PTR_TO_CTX, .arg2_type = ARG_ANYTHING, - .arg3_type = ARG_PTR_TO_UNINIT_MEM, + .arg3_type = ARG_PTR_TO_MEM | MEM_RDONLY, .arg4_type = ARG_CONST_SIZE, }; -- 2.43.0

2 1

[PATCH OLK-5.10] xfrm: ah: account for ESN high bits in async callbacks
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> mainline inclusion from mainline-v7.1-rc3 commit ec54093e6a8f87e800bb6aa15eb7fc1e33faa524 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15434 CVE: CVE-2026-46193 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine. Fixes: d4d573d0334d ("{IPv4,xfrm} Add ESN support for AH egress part") Fixes: d8b2a8600b0e ("{IPv4,xfrm} Add ESN support for AH ingress part") Fixes: 26dd70c3fad3 ("{IPv6,xfrm} Add ESN support for AH egress part") Fixes: 8d6da6f32557 ("{IPv6,xfrm} Add ESN support for AH ingress part") Cc: stable(a)vger.kernel.org Assisted-by: Codex:gpt-5-4 Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Conflicts: net/ipv4/ah4.c net/ipv6/ah6.c [commit ec54093e6a8f and e77f5dd70138 changed function signatures and ah_tmp_icv() parameter count that differ between mainline and OLK-5.10. Adapted to preserve OLK-5.10's struct crypto_async_request *base parameter and 3-arg ah_tmp_icv().] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv4/ah4.c | 14 ++++++++++++-- net/ipv6/ah6.c | 14 ++++++++++++-- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c index 36ed85bf2ad5..819e9f5ab3bc 100644 --- a/net/ipv4/ah4.c +++ b/net/ipv4/ah4.c @@ -127,9 +127,14 @@ static void ah_output_done(struct crypto_async_request *base, int err) struct iphdr *top_iph = ip_hdr(skb); struct ip_auth_hdr *ah = ip_auth_hdr(skb); int ihl = ip_hdrlen(skb); + int seqhi_len = 0; + __be32 *seqhi; + if (x->props.flags & XFRM_STATE_ESN) + seqhi_len = sizeof(*seqhi); iph = AH_SKB_CB(skb)->tmp; - icv = ah_tmp_icv(ahp->ahash, iph, ihl); + seqhi = (__be32 *)((char *)iph + ihl); + icv = ah_tmp_icv(ahp->ahash, seqhi, seqhi_len); memcpy(ah->auth_data, icv, ahp->icv_trunc_len); top_iph->tos = iph->tos; @@ -273,12 +278,17 @@ static void ah_input_done(struct crypto_async_request *base, int err) struct ip_auth_hdr *ah = ip_auth_hdr(skb); int ihl = ip_hdrlen(skb); int ah_hlen = (ah->hdrlen + 2) << 2; + int seqhi_len = 0; + __be32 *seqhi; if (err) goto out; + if (x->props.flags & XFRM_STATE_ESN) + seqhi_len = sizeof(*seqhi); work_iph = AH_SKB_CB(skb)->tmp; - auth_data = ah_tmp_auth(work_iph, ihl); + seqhi = (__be32 *)((char *)work_iph + ihl); + auth_data = ah_tmp_auth(seqhi, seqhi_len); icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len); err = crypto_memneq(icv, auth_data, ahp->icv_trunc_len) ? -EBADMSG : 0; diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c index 080ee7f44c64..d7a9e792cdf2 100644 --- a/net/ipv6/ah6.c +++ b/net/ipv6/ah6.c @@ -295,14 +295,19 @@ static void ah6_output_done(struct crypto_async_request *base, int err) struct ipv6hdr *top_iph = ipv6_hdr(skb); struct ip_auth_hdr *ah = ip_auth_hdr(skb); struct tmp_ext *iph_ext; + int seqhi_len = 0; + __be32 *seqhi; extlen = skb_network_header_len(skb) - sizeof(struct ipv6hdr); if (extlen) extlen += sizeof(*iph_ext); + if (x->props.flags & XFRM_STATE_ESN) + seqhi_len = sizeof(*seqhi); iph_base = AH_SKB_CB(skb)->tmp; iph_ext = ah_tmp_ext(iph_base); - icv = ah_tmp_icv(ahp->ahash, iph_ext, extlen); + seqhi = (__be32 *)((char *)iph_ext + extlen); + icv = ah_tmp_icv(ahp->ahash, seqhi, seqhi_len); memcpy(ah->auth_data, icv, ahp->icv_trunc_len); memcpy(top_iph, iph_base, IPV6HDR_BASELEN); @@ -465,13 +470,18 @@ static void ah6_input_done(struct crypto_async_request *base, int err) struct ip_auth_hdr *ah = ip_auth_hdr(skb); int hdr_len = skb_network_header_len(skb); int ah_hlen = ipv6_authlen(ah); + int seqhi_len = 0; + __be32 *seqhi; if (err) goto out; + if (x->props.flags & XFRM_STATE_ESN) + seqhi_len = sizeof(*seqhi); work_iph = AH_SKB_CB(skb)->tmp; auth_data = ah_tmp_auth(work_iph, hdr_len); - icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len); + seqhi = (__be32 *)(auth_data + ahp->icv_trunc_len); + icv = ah_tmp_icv(ahp->ahash, seqhi, seqhi_len); err = crypto_memneq(icv, auth_data, ahp->icv_trunc_len) ? -EBADMSG : 0; if (err) -- 2.43.0

2 1

[PATCH OLK-5.10] bonding: alb: fix UAF in rlb_arp_recv during bond up/down
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v5.10.252 commit fd54ddc929be1d6c3b3b7b35d6d4642a5d9e803c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15209 CVE: CVE-2026-45970 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e6834a4c474697df23ab9948fd3577b26bf48656 ] The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li <liali(a)redhat.com> Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov <nikolay(a)nvidia.com> Acked-by: Jay Vosburgh <jv(a)jvosburgh.net> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/bonding/bond_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 055211842fb6..c6e625ef6d34 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3951,9 +3951,13 @@ static int bond_close(struct net_device *bond_dev) bond_work_cancel_all(bond); bond->send_peer_notif = 0; + WRITE_ONCE(bond->recv_probe, NULL); + + /* Wait for any in-flight RX handlers */ + synchronize_net(); + if (bond_is_lb(bond)) bond_alb_deinitialize(bond); - bond->recv_probe = NULL; if (bond_uses_primary(bond)) { rcu_read_lock(); -- 2.43.0

2 1

[PATCH OLK-6.6] netfilter: x_tables: ensure names are nul-terminated
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Florian Westphal <fw(a)strlen.de> stable inclusion from stable-v6.6.134 commit c2d4a3abb15ca14716c6d8b9ffcbcd7c63626af4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14560 CVE: CVE-2026-43028 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a958a4f90ddd7de0800b33ca9d7b886b7d40f74e ] Reject names that lack a \0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/xt_cgroup.c | 6 ++++++ net/netfilter/xt_rateest.c | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/net/netfilter/xt_cgroup.c b/net/netfilter/xt_cgroup.c index c0f5e9a4f3c6..bfc98719684e 100644 --- a/net/netfilter/xt_cgroup.c +++ b/net/netfilter/xt_cgroup.c @@ -53,6 +53,9 @@ static int cgroup_mt_check_v1(const struct xt_mtchk_param *par) info->priv = NULL; if (info->has_path) { + if (strnlen(info->path, sizeof(info->path)) >= sizeof(info->path)) + return -ENAMETOOLONG; + cgrp = cgroup_get_from_path(info->path); if (IS_ERR(cgrp)) { pr_info_ratelimited("invalid path, errno=%ld\n", @@ -85,6 +88,9 @@ static int cgroup_mt_check_v2(const struct xt_mtchk_param *par) info->priv = NULL; if (info->has_path) { + if (strnlen(info->path, sizeof(info->path)) >= sizeof(info->path)) + return -ENAMETOOLONG; + cgrp = cgroup_get_from_path(info->path); if (IS_ERR(cgrp)) { pr_info_ratelimited("invalid path, errno=%ld\n", diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c index 72324bd976af..b1d736c15fcb 100644 --- a/net/netfilter/xt_rateest.c +++ b/net/netfilter/xt_rateest.c @@ -91,6 +91,11 @@ static int xt_rateest_mt_checkentry(const struct xt_mtchk_param *par) goto err1; } + if (strnlen(info->name1, sizeof(info->name1)) >= sizeof(info->name1)) + return -ENAMETOOLONG; + if (strnlen(info->name2, sizeof(info->name2)) >= sizeof(info->name2)) + return -ENAMETOOLONG; + ret = -ENOENT; est1 = xt_rateest_lookup(par->net, info->name1); if (!est1) -- 2.43.0

2 1

[PATCH OLK-6.6] netconsole: avoid OOB reads, msg is not nul-terminated
by Jinjiang Tu 10 Jun '26

10 Jun '26

From: Jakub Kicinski <kuba(a)kernel.org> mainline inclusion from mainline-v7.0-rc2 commit 82aec772fca2223bc5774bd9af486fd95766e578 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14743 CVE: CVE-2026-43197 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00) Fixes: c62c0a17f9b7 ("netconsole: Append kernel version to message") Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20260219195021.2099699-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: drivers/net/netconsole.c [Context conflicts due to commit e7650d8d475c ("net: netconsole: split send_ext_msg_udp() function") isn't merged.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/net/netconsole.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c index fffffa3658d2..69d54f58aa97 100644 --- a/drivers/net/netconsole.c +++ b/drivers/net/netconsole.c @@ -854,7 +854,8 @@ static void send_ext_msg_udp(struct netconsole_target *nt, const char *msg, if (msg_len + release_len <= MAX_PRINT_CHUNK) { /* No fragmentation needed */ if (nt->release) { - scnprintf(buf, MAX_PRINT_CHUNK, "%s,%s", release, msg); + scnprintf(buf, MAX_PRINT_CHUNK, "%s,%.*s", release, + msg_len, msg); msg_len += release_len; msg_ready = buf; } -- 2.43.0

2 1

[PATCH OLK-6.6] bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs
by Luo Gengkun 10 Jun '26

10 Jun '26

From: Deepanshu Kartikey <kartikey406(a)gmail.com> maillist inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15537 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF Fixes: 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") Reported-by: syzbot+36e50496c8ac4bcde3f9(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=36e50496c8ac4bcde3f9 Suggested-by: Al Viro <viro(a)zeniv.linux.org.uk> Link: https://lore.kernel.org/all/20260423043906.GN3518998@ZenIV/ Link: https://lore.kernel.org/all/20260602002607.110866-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20260602025249.113828-1-kartikey406@gmail.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/bpf/inode.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c index 9a9630adcba4..99ec74325175 100644 --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -611,10 +611,18 @@ static void bpf_destroy_inode(struct inode *inode) { enum bpf_type type; - if (S_ISLNK(inode->i_mode)) - kfree(inode->i_link); if (!bpf_inode_type(inode, &type)) bpf_any_put(inode->i_private, type); +} + +/* + * Called after RCU grace period - safe to free inode and anything + * that might be accessed by RCU pathwalk (inode fields, i_link). + */ +static void bpf_free_inode(struct inode *inode) +{ + if (S_ISLNK(inode->i_mode)) + kfree(inode->i_link); free_inode_nonrcu(inode); } @@ -623,6 +631,7 @@ static const struct super_operations bpf_super_ops = { .drop_inode = generic_delete_inode, .show_options = bpf_show_options, .destroy_inode = bpf_destroy_inode, + .free_inode = bpf_free_inode, }; enum { -- 2.34.1

2 1

[PATCH OLK-5.10] netfilter: x_tables: ensure names are nul-terminated
by superdcc97＠163.com 10 Jun '26

10 Jun '26

From: Florian Westphal <fw(a)strlen.de> stable inclusion from stable-v5.10.253 commit bcac50ea0a29d430eedc5ac87b215393b567baa9 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14560 CVE: CVE-2026-43028 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a958a4f90ddd7de0800b33ca9d7b886b7d40f74e ] Reject names that lack a \0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/xt_cgroup.c | 6 ++++++ net/netfilter/xt_rateest.c | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/net/netfilter/xt_cgroup.c b/net/netfilter/xt_cgroup.c index c0f5e9a4f3c6..bfc98719684e 100644 --- a/net/netfilter/xt_cgroup.c +++ b/net/netfilter/xt_cgroup.c @@ -53,6 +53,9 @@ static int cgroup_mt_check_v1(const struct xt_mtchk_param *par) info->priv = NULL; if (info->has_path) { + if (strnlen(info->path, sizeof(info->path)) >= sizeof(info->path)) + return -ENAMETOOLONG; + cgrp = cgroup_get_from_path(info->path); if (IS_ERR(cgrp)) { pr_info_ratelimited("invalid path, errno=%ld\n", @@ -85,6 +88,9 @@ static int cgroup_mt_check_v2(const struct xt_mtchk_param *par) info->priv = NULL; if (info->has_path) { + if (strnlen(info->path, sizeof(info->path)) >= sizeof(info->path)) + return -ENAMETOOLONG; + cgrp = cgroup_get_from_path(info->path); if (IS_ERR(cgrp)) { pr_info_ratelimited("invalid path, errno=%ld\n", diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c index 72324bd976af..b1d736c15fcb 100644 --- a/net/netfilter/xt_rateest.c +++ b/net/netfilter/xt_rateest.c @@ -91,6 +91,11 @@ static int xt_rateest_mt_checkentry(const struct xt_mtchk_param *par) goto err1; } + if (strnlen(info->name1, sizeof(info->name1)) >= sizeof(info->name1)) + return -ENAMETOOLONG; + if (strnlen(info->name2, sizeof(info->name2)) >= sizeof(info->name2)) + return -ENAMETOOLONG; + ret = -ENOENT; est1 = xt_rateest_lookup(par->net, info->name1); if (!est1) -- 2.43.0

2 1