- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb()
by Long Li 03 Jun '26

03 Jun '26

From: Ye Bin <yebin10(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9228 CVE: NA -------------------------------- Recently, I encountered a problem where a BUG was triggered in the write-back process. The detailed problem information is as follows: xfs_bmap_extents_to_btree: ip=0xffff888148ecad00 wasdel=0 sde: writeback error on inode 68, offset 61440, sector 1400 XFS (sde): Corruption of in-memory data (0x8) detected at xfs_trans_mod_sb+0xaa6/0xc60 (fs/xfs/xfs_trans.c:351). Shutting. XFS (sde): Please unmount the filesystem and rectify the problem(s) XFS: Assertion failed: tp->t_blk_res || tp->t_fdblocks_delta >= 0, file: fs/xfs/xfs_trans.c, line: 610 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 7.0.0-rc6-next-20260402-00028-g56f243e5f8ea-dirty #360 P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: writeback wb_workfn (flush-8:64) RIP: 0010:assfail+0x9f/0xb0 Code: fe 84 db 75 20 e8 41 2e 33 fe 0f 0b 5b 5d 41 5c 41 5d e9 94 34 a5 06 48 c7 c7 58 ae 2b 8d e8 f8 72 a0 RSP: 0018:ffffc900000dedd0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff838c91b6 RDX: ffff88810425d880 RSI: ffffffff838c91df RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10e3b14901 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8a956520 R13: 0000000000000262 R14: 0000000000000000 R15: ffffffffffffffff FS: 0000000000000000(0000) GS:ffff88878bdc5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fccb3c788f0 CR3: 000000000c98a000 CR4: 00000000000006f0 Call Trace: <TASK> xfs_trans_unreserve_and_mod_sb+0xb86/0xd00 __xfs_trans_commit+0x38b/0xe00 xfs_trans_commit+0xeb/0x1a0 xfs_bmapi_convert_one_delalloc+0xba9/0x12d0 xfs_bmapi_convert_delalloc+0x101/0x350 xfs_writeback_range+0x76c/0x12d0 iomap_writeback_folio+0x9ed/0x2100 iomap_writepages+0x13c/0x2a0 xfs_vm_writepages+0x278/0x330 do_writepages+0x247/0x5c0 __writeback_single_inode+0x123/0x1370 writeback_sb_inodes+0x71e/0x1b90 __writeback_inodes_wb+0xc3/0x280 wb_writeback+0x730/0xb80 wb_workfn+0x8b0/0xbc0 process_one_work+0xa08/0x1d00 worker_thread+0x698/0xeb0 kthread+0x408/0x540 ret_from_fork+0xa4d/0xdd0 ret_from_fork_asm+0x1a/0x30 </TASK> After analyzing the above issues, the possible triggering process is as follows: xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 5 case BMAP_LEFT_FILLING: ifp->if_nextents++; // 21 + 1 = 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 xfs_bmap_extents_to_btree // convert to btree cur->bc_ino.allocated++; // da_new = 5 - 1 = 4 da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), startblockval(PREV.br_startblock) - (bma->cur ? bma->cur->bc_ino.allocated : 0)) //xfs_bmapi_convert_one_delalloc() return PREV.br_startblock = nullstartblock(da_new); xfs_bmap_del_extent_real case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING: ifp->if_nextents--; // 22 - 1 = 21 if (xfs_bmap_needs_btree(ip, whichfork)) xfs_bmap_extents_to_btree(); else // convert to extents xfs_bmap_btree_to_extents(); ... // Alternate a few times in the middle. da_old = 4 da_old = 3 da_old = 2 da_old = 1 ... xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc // Both blocks and rtextents are 0 error = xfs_trans_alloc(mp, &M_RES(mp)->tr_write, 0, 0, XFS_TRANS_RESERVE, &tp); tp = kmem_cache_zalloc(xfs_trans_cache, GFP_KERNEL | __GFP_NOFAIL); error = xfs_trans_reserve(tp, resp, blocks, rtextents); if (blocks > 0) error = xfs_mod_fdblocks(mp, -((int64_t)blocks), rsvd); // The value of blocks is 0, so the value of tp->t_blk_res is 0 tp->t_blk_res += blocks; xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 0 // The current delay extent is just exhausted. case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING ifp->if_nextents++; // 21 + 1 + 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 // Converted to btree. da_old > 0 is false. error = xfs_bmap_extents_to_btree(bma->tp, bma->ip, &bma->cur, da_old > 0, &tmp_logflags, whichfork); args.wasdel = wasdel; // wasdel is false error = xfs_alloc_vextent_start_ag(&args, XFS_INO_TO_FSB(mp, ip->i_ino)); xfs_alloc_vextent_finish(args, minimum_agno, error, true); xfs_ag_resv_alloc_extent(args->pag, args->resv, args); case XFS_AG_RESV_NONE: field = args->wasdel ? XFS_TRANS_SB_RES_FDBLOCKS : XFS_TRANS_SB_FDBLOCKS; //args->wasdel == false xfs_trans_mod_sb(args->tp, field, -(int64_t)args->len); case XFS_TRANS_SB_FDBLOCKS: if (delta < 0) tp->t_blk_res_used += (uint)-delta; if (tp->t_blk_res_used > tp->t_blk_res) // ***tp->t_blk_res is 0, thus triggering xfs_force_shutdown()*** xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); The logic that triggers the issue above was designed by me to facilitate the construction of the problem. Besides the scenario where BTREE and EXTENTS are converted back and forth, there is also the scenario of btree splitting. The core reason for the issue is that in xfs_bmapi_convert_delalloc(), the call to xfs_bmap_worst_indlen() calculates the worst-case number of reserved blocks, which is the number of additional blocks required after a complete conversion of the entire delayed extent. It assumes that the entire conversion process is atomic. However, the current process cannot guarantee such atomicity. In the case of a fragmented filesystem, the most extreme scenario is that every block conversion triggers a full btree split, in which case the reserved blocks are far from sufficient. When this issue is triggered, the filesystem fragmentation in the environment is indeed quite severe. Further analysis of this abnormal model shows that because the reserved blocks are continuously consumed, they may eventually exceed the reserved amount. When the space is nearly exhausted, xfs_bmap_extents_to_btree() may fail to allocate blocks, triggering a warning. This failure to allocate additional blocks can lead to issues with normal block allocation. Since a single delay extent cannot guarantee a one-time completion of the conversion, the 'inlen' of the delay extent should be maintained at the value calculated by xfs_bmap_worst_indlen(). Commit d69bee6a35d3 ("xfs: fix xfs_bmap_add_extent_delay_real for partial conversions") addressed the issue of potentially not reserving enough space in emergency situations. Based on this modification, we can recalculate the worst-case 'inlen' required for the remaining delay extents after the conversion in xfs_bmap_add_extent_delay_real(), instead of using the remaining value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_bmap.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 9ed22d82c000..3d655c1bef7d 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -1656,8 +1656,7 @@ xfs_bmap_add_extent_delay_real( */ old = LEFT; temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); LEFT.br_blockcount += new->br_blockcount; @@ -1724,9 +1723,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startoff = new_endoff; PREV.br_blockcount = temp; @@ -1763,8 +1760,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_blockcount = temp; PREV.br_startblock = nullstartblock(da_new); @@ -1812,9 +1808,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startblock = nullstartblock(da_new); PREV.br_blockcount = temp; -- 2.52.0

2 1

[PATCH OLK-5.10 0/2] xfs: fix delay extent reserve issue
by Long Li 03 Jun '26

03 Jun '26

This patch set fix delay extent reserve issue. Christoph Hellwig (1): xfs: fix xfs_bmap_add_extent_delay_real for partial conversions Ye Bin (1): xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb() fs/xfs/libxfs/xfs_bmap.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6] mm/vmscan: fix wrong callback in shrinker_v2_to_v1_scan_objects()
by Qi Xi 03 Jun '26

03 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/15059 CVE: NA --------------------------- Fixes the incorrect callback invocation that would cause shrinker behavior mismatch when adapting v2 shrinkers to v1 interface. Fixes: 0dabf4e3ac0f ("mm/shrinker: Implementation of register_shrinker() and unregister_shrinker()") Signed-off-by: Qi Xi <xiqi5703(a)163.com> --- mm/vmscan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index cf6b9e6dc8cd..5c81e3e1e2d7 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7623,9 +7623,9 @@ static unsigned long shrinker_v2_to_v1_scan_objects(struct shrinker_v2 *shk_v2, struct shrink_control *sc) { if (shk_v2->v1) - return shk_v2->v1->count_objects(shk_v2->v1, sc); + return shk_v2->v1->scan_objects(shk_v2->v1, sc); - return SHRINK_EMPTY; + return SHRINK_STOP; } int register_shrinker(struct shrinker *shrinker, const char *fmt, ...) -- 2.53.0

2 1

[PATCH openEuler-1.0-LTS] netfilter: nf_conntrack_helper: pass helper to expect cleanup
by superdcc97＠163.com 03 Jun '26

03 Jun '26

From: Qi Tang <tpluszz77(a)gmail.com> mainline inclusion from mainline-v7.0-rc7 commit a242a9ae58aa46ff7dae51ce64150a93957abe65 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14559 CVE: CVE-2026-43027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0) Fixes: ac7b84839003 ("netfilter: expect: add and use nf_ct_expect_iterate helpers") Signed-off-by: Qi Tang <tpluszz77(a)gmail.com> Reviewed-by: Phil Sutter <phil(a)nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Conflicts: net/netfilter/nf_conntrack_helper.c [commit 9c42bc9db90a1 ("netfilter: nf_conntrack_expect: honor expectation helper field") is not backported, which lead to conflicts. The target kernel still contains the old comment and an extra synchronize_rcu() call after nf_ct_iterate_destroy(), while the patch context expects the new comment from mainline.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_conntrack_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c index 06c70d4584cf..31cc05a437c2 100644 --- a/net/netfilter/nf_conntrack_helper.c +++ b/net/netfilter/nf_conntrack_helper.c @@ -464,7 +464,7 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me) */ synchronize_rcu(); - nf_ct_expect_iterate_destroy(expect_iter_me, NULL); + nf_ct_expect_iterate_destroy(expect_iter_me, me); nf_ct_iterate_destroy(unhelp, me); /* Maybe someone has gotten the helper already when unhelp above. -- 2.43.0

2 1

[PATCH OLK-6.6] xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb()
by Long Li 03 Jun '26

03 Jun '26

From: Ye Bin <yebin10(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9228 -------------------------------- Recently, I encountered a problem where a BUG was triggered in the write-back process. The detailed problem information is as follows: xfs_bmap_extents_to_btree: ip=0xffff888148ecad00 wasdel=0 sde: writeback error on inode 68, offset 61440, sector 1400 XFS (sde): Corruption of in-memory data (0x8) detected at xfs_trans_mod_sb+0xaa6/0xc60 (fs/xfs/xfs_trans.c:351). Shutting. XFS (sde): Please unmount the filesystem and rectify the problem(s) XFS: Assertion failed: tp->t_blk_res || tp->t_fdblocks_delta >= 0, file: fs/xfs/xfs_trans.c, line: 610 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 7.0.0-rc6-next-20260402-00028-g56f243e5f8ea-dirty #360 P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: writeback wb_workfn (flush-8:64) RIP: 0010:assfail+0x9f/0xb0 Code: fe 84 db 75 20 e8 41 2e 33 fe 0f 0b 5b 5d 41 5c 41 5d e9 94 34 a5 06 48 c7 c7 58 ae 2b 8d e8 f8 72 a0 RSP: 0018:ffffc900000dedd0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff838c91b6 RDX: ffff88810425d880 RSI: ffffffff838c91df RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10e3b14901 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8a956520 R13: 0000000000000262 R14: 0000000000000000 R15: ffffffffffffffff FS: 0000000000000000(0000) GS:ffff88878bdc5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fccb3c788f0 CR3: 000000000c98a000 CR4: 00000000000006f0 Call Trace: <TASK> xfs_trans_unreserve_and_mod_sb+0xb86/0xd00 __xfs_trans_commit+0x38b/0xe00 xfs_trans_commit+0xeb/0x1a0 xfs_bmapi_convert_one_delalloc+0xba9/0x12d0 xfs_bmapi_convert_delalloc+0x101/0x350 xfs_writeback_range+0x76c/0x12d0 iomap_writeback_folio+0x9ed/0x2100 iomap_writepages+0x13c/0x2a0 xfs_vm_writepages+0x278/0x330 do_writepages+0x247/0x5c0 __writeback_single_inode+0x123/0x1370 writeback_sb_inodes+0x71e/0x1b90 __writeback_inodes_wb+0xc3/0x280 wb_writeback+0x730/0xb80 wb_workfn+0x8b0/0xbc0 process_one_work+0xa08/0x1d00 worker_thread+0x698/0xeb0 kthread+0x408/0x540 ret_from_fork+0xa4d/0xdd0 ret_from_fork_asm+0x1a/0x30 </TASK> After analyzing the above issues, the possible triggering process is as follows: xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 5 case BMAP_LEFT_FILLING: ifp->if_nextents++; // 21 + 1 = 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 xfs_bmap_extents_to_btree // convert to btree cur->bc_ino.allocated++; // da_new = 5 - 1 = 4 da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), startblockval(PREV.br_startblock) - (bma->cur ? bma->cur->bc_ino.allocated : 0)) //xfs_bmapi_convert_one_delalloc() return PREV.br_startblock = nullstartblock(da_new); xfs_bmap_del_extent_real case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING: ifp->if_nextents--; // 22 - 1 = 21 if (xfs_bmap_needs_btree(ip, whichfork)) xfs_bmap_extents_to_btree(); else // convert to extents xfs_bmap_btree_to_extents(); ... // Alternate a few times in the middle. da_old = 4 da_old = 3 da_old = 2 da_old = 1 ... xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc // Both blocks and rtextents are 0 error = xfs_trans_alloc(mp, &M_RES(mp)->tr_write, 0, 0, XFS_TRANS_RESERVE, &tp); tp = kmem_cache_zalloc(xfs_trans_cache, GFP_KERNEL | __GFP_NOFAIL); error = xfs_trans_reserve(tp, resp, blocks, rtextents); if (blocks > 0) error = xfs_mod_fdblocks(mp, -((int64_t)blocks), rsvd); // The value of blocks is 0, so the value of tp->t_blk_res is 0 tp->t_blk_res += blocks; xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 0 // The current delay extent is just exhausted. case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING ifp->if_nextents++; // 21 + 1 + 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 // Converted to btree. da_old > 0 is false. error = xfs_bmap_extents_to_btree(bma->tp, bma->ip, &bma->cur, da_old > 0, &tmp_logflags, whichfork); args.wasdel = wasdel; // wasdel is false error = xfs_alloc_vextent_start_ag(&args, XFS_INO_TO_FSB(mp, ip->i_ino)); xfs_alloc_vextent_finish(args, minimum_agno, error, true); xfs_ag_resv_alloc_extent(args->pag, args->resv, args); case XFS_AG_RESV_NONE: field = args->wasdel ? XFS_TRANS_SB_RES_FDBLOCKS : XFS_TRANS_SB_FDBLOCKS; //args->wasdel == false xfs_trans_mod_sb(args->tp, field, -(int64_t)args->len); case XFS_TRANS_SB_FDBLOCKS: if (delta < 0) tp->t_blk_res_used += (uint)-delta; if (tp->t_blk_res_used > tp->t_blk_res) // ***tp->t_blk_res is 0, thus triggering xfs_force_shutdown()*** xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); The logic that triggers the issue above was designed by me to facilitate the construction of the problem. Besides the scenario where BTREE and EXTENTS are converted back and forth, there is also the scenario of btree splitting. The core reason for the issue is that in xfs_bmapi_convert_delalloc(), the call to xfs_bmap_worst_indlen() calculates the worst-case number of reserved blocks, which is the number of additional blocks required after a complete conversion of the entire delayed extent. It assumes that the entire conversion process is atomic. However, the current process cannot guarantee such atomicity. In the case of a fragmented filesystem, the most extreme scenario is that every block conversion triggers a full btree split, in which case the reserved blocks are far from sufficient. When this issue is triggered, the filesystem fragmentation in the environment is indeed quite severe. Further analysis of this abnormal model shows that because the reserved blocks are continuously consumed, they may eventually exceed the reserved amount. When the space is nearly exhausted, xfs_bmap_extents_to_btree() may fail to allocate blocks, triggering a warning. This failure to allocate additional blocks can lead to issues with normal block allocation. Since a single delay extent cannot guarantee a one-time completion of the conversion, the 'inlen' of the delay extent should be maintained at the value calculated by xfs_bmap_worst_indlen(). Commit d69bee6a35d3 ("xfs: fix xfs_bmap_add_extent_delay_real for partial conversions") addressed the issue of potentially not reserving enough space in emergency situations. Based on this modification, we can recalculate the worst-case 'inlen' required for the remaining delay extents after the conversion in xfs_bmap_add_extent_delay_real(), instead of using the remaining value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_bmap.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 9ed22d82c000..3d655c1bef7d 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -1656,8 +1656,7 @@ xfs_bmap_add_extent_delay_real( */ old = LEFT; temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); LEFT.br_blockcount += new->br_blockcount; @@ -1724,9 +1723,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startoff = new_endoff; PREV.br_blockcount = temp; @@ -1763,8 +1760,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_blockcount = temp; PREV.br_startblock = nullstartblock(da_new); @@ -1812,9 +1808,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startblock = nullstartblock(da_new); PREV.br_blockcount = temp; -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS V1] RDMA/rxe: Fix double free in rxe_srq_from_init
by Cheng Yu 03 Jun '26

03 Jun '26

From: Jiasheng Jiang <jiashengjiangcool(a)gmail.com> mainline inclusion from mainline-v7.0-rc1 commit 0beefd0e15d962f497aad750b2d5e9c3570b66d1 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15105 CVE: CVE-2026-45852 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. Fixes: aae0484e15f0 ("IB/rxe: avoid srq memory leak") Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)gmail.com> Link: https://patch.msgid.link/20260112015412.29458-1-jiashengjiangcool@gmail.com Reviewed-by: Zhu Yanjun <yanjun.Zhu(a)linux.dev> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/sw/rxe/rxe_srq.c [The conflict is caused by not having applied the patch cc28f351155d("RDMA/rxe: Fix rxe_modify_srq"). ] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/infiniband/sw/rxe/rxe_srq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/infiniband/sw/rxe/rxe_srq.c b/drivers/infiniband/sw/rxe/rxe_srq.c index c41a5fee81f7..3630d00ca71d 100644 --- a/drivers/infiniband/sw/rxe/rxe_srq.c +++ b/drivers/infiniband/sw/rxe/rxe_srq.c @@ -144,6 +144,9 @@ int rxe_srq_from_init(struct rxe_dev *rxe, struct rxe_srq *srq, } } + srq->rq.queue = q; + init->attr.max_wr = srq->rq.max_wr; + return 0; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] netfilter: x_tables: ensure names are nul-terminated
by superdcc97＠163.com 03 Jun '26

03 Jun '26

From: Florian Westphal <fw(a)strlen.de> mainline inclusion from mainline-v7.0-rc7 commit a958a4f90ddd7de0800b33ca9d7b886b7d40f74e 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/torvalds/linux.git/commit/?… -------------------------------- 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: 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 5cb1ecb29ea4..e54fbda5e435 100644 --- a/net/netfilter/xt_cgroup.c +++ b/net/netfilter/xt_cgroup.c @@ -56,6 +56,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", @@ -88,6 +91,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 bf77326861af..a9a60a8fc758 100644 --- a/net/netfilter/xt_rateest.c +++ b/net/netfilter/xt_rateest.c @@ -94,6 +94,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 v2 0/2] bpf mainline
by Pu Lehui 03 Jun '26

03 Jun '26

Daniel Borkmann (2): bpf: Drop pkt_end markers on arithmetic to prevent is_pkt_ptr_branch_taken selftests/bpf: Add test for stale pkt range after scalar arithmetic kernel/bpf/verifier.c | 33 +++++++++- .../bpf/progs/verifier_direct_packet_access.c | 61 +++++++++++++++++++ 2 files changed, 91 insertions(+), 3 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] netfilter: nft_ct: fix use-after-free in timeout object destroy
by superdcc97＠163.com 03 Jun '26

03 Jun '26

From: Tuan Do <tuan(a)calif.io> mainline inclusion from mainline-v7.1-rc1 commit f8dca15a1b190787bbd03285304b569631160eda category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14407 CVE: CVE-2026-31665 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0 Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support") Cc: stable(a)vger.kernel.org Signed-off-by: Tuan Do <tuan(a)calif.io> Signed-off-by: Florian Westphal <fw(a)strlen.de> Conflicts: include/net/netfilter/nf_conntrack_timeout.h net/netfilter/nft_ct.c [commit 6daf14140129 ("netfilter: Replace zero-length array with flexible-array member") is not backport, target uses 'char data[0]' instead of 'char data[]', need to insert struct rcu_head before data[0]. commit b184356d0a00 ("netfilter: conntrack: remove module owner field") is not backport, target still has nf_ct_l4proto_put(timeout->l4proto) in nft_ct_timeout_obj_destroy(), need to preserve it while replacing kfree with kfree_rcu.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- include/net/netfilter/nf_conntrack_timeout.h | 1 + net/netfilter/nft_ct.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/net/netfilter/nf_conntrack_timeout.h b/include/net/netfilter/nf_conntrack_timeout.h index 3394d75e1c80..d6f74145f945 100644 --- a/include/net/netfilter/nf_conntrack_timeout.h +++ b/include/net/netfilter/nf_conntrack_timeout.h @@ -14,6 +14,7 @@ struct nf_ct_timeout { __u16 l3num; const struct nf_conntrack_l4proto *l4proto; + struct rcu_head rcu; char data[0]; }; diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c index b17604b5b48b..2fc92f42cea6 100644 --- a/net/netfilter/nft_ct.c +++ b/net/netfilter/nft_ct.c @@ -906,7 +906,7 @@ static void nft_ct_timeout_obj_destroy(const struct nft_ctx *ctx, nf_ct_untimeout(ctx->net, timeout); nf_ct_l4proto_put(timeout->l4proto); nf_ct_netns_put(ctx->net, ctx->family); - kfree(priv->timeout); + kfree_rcu(priv->timeout, rcu); } static int nft_ct_timeout_obj_dump(struct sk_buff *skb, -- 2.43.0

2 1

[PATCH 0/2] xfs: fix delay extent reserve issue
by Long Li 03 Jun '26

03 Jun '26

This patch set fix delay extent reserve issue. Christoph Hellwig (1): xfs: fix xfs_bmap_add_extent_delay_real for partial conversions Ye Bin (1): xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb() fs/xfs/libxfs/xfs_bmap.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) -- 2.52.0

1 2