- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] tls: always refresh the queue when reading sock
by Bowen You 29 Jul '25

29 Jul '25

From: Jakub Kicinski <kuba(a)kernel.org> stable inclusion from stable-v6.6.100 commit 1f3a429c21e0e43e8b8c55d30701e91411a4df02 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPD5H CVE: CVE-2025-38471 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4ab26bce3969f8fd925fe6f6f551e4d1a508c68b ] After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len"). Fixes: 0d87bbd39d7f ("tls: strp: make sure the TCP skbs do not have overlapping data") Link: https://patch.msgid.link/20250716143850.1520292-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/tls/tls_strp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/tls/tls_strp.c b/net/tls/tls_strp.c index 5df08d848b5c..c8a0e499fe70 100644 --- a/net/tls/tls_strp.c +++ b/net/tls/tls_strp.c @@ -510,9 +510,8 @@ static int tls_strp_read_sock(struct tls_strparser *strp) if (inq < strp->stm.full_len) return tls_strp_read_copy(strp, true); + tls_strp_load_anchor_with_queue(strp, inq); if (!strp->stm.full_len) { - tls_strp_load_anchor_with_queue(strp, inq); - sz = tls_rx_msg_size(strp, strp->anchor); if (sz < 0) { tls_strp_abort_strp(strp, sz); -- 2.34.1

2 1

[PATCH OLK-6.6 v7 0/3] arm64: Add hardware xcall framework support
by Jinjie Ruan 29 Jul '25

29 Jul '25

Add hardware xcall framework support. Changes in v7: - Add missing lock for xinfo syscall table copy. - Check xcall entry under lock for set_hw_xcall_entry(). - Clear ACTLR_ELx_XCALL when xcall_scno_count count to zero to reduce overhead. Changes in v6: - Use system_uses_xcall_xint() instead of static key for hardware xcall. - xcall_scno_enabled -> xcall_scno_count for each task_struct. - Use xcall_scno_enabled instead of static_branch_unlikely() for performance-insensitive code. - Some cleanup. Changes in v5: - Not adjust the software xcall and hardware xcall hwcap detect order. - Not udapte xcall 1.0 enrty code. - Some cleanup. Changes in v4: - Merge the percpu and csel patch. - Use static key to improve the software and hardware xcall code. - Some cleanup. - Fix a build problem. Changes in v3: - Optimize the use of hardware xcall and not use them at the same time. - Use syscall table instead of xcall enable bitmap in hardware xcall. - Use percpu syscall table cache to simplfy code. - Use csel to improve the jump instruction. Changes in v2: - Split software xcall and hardware xcall code and use same bitmap to check xcall enable. Jinjie Ruan (3): arm64: Refactor the xcall proc code arm64: Reserve a kabi in task_struct exclusively for xcall arm64: Add hardware xcall framework support arch/arm64/Kconfig.turbo | 1 + arch/arm64/include/asm/cpufeature.h | 2 - arch/arm64/include/asm/exception.h | 5 + arch/arm64/include/asm/mmu_context.h | 7 + arch/arm64/include/asm/xcall.h | 96 +++++++++++++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/asm-offsets.c | 2 +- arch/arm64/kernel/cpufeature.c | 41 +++--- arch/arm64/kernel/entry-common.c | 2 +- arch/arm64/kernel/entry.S | 6 +- arch/arm64/kernel/xcall/Makefile | 2 + arch/arm64/kernel/xcall/entry.S | 195 +++++++++++++++++++++++++++ arch/arm64/kernel/xcall/xcall.c | 77 +++++++++++ fs/proc/Makefile | 1 + fs/proc/base.c | 109 --------------- fs/proc/internal.h | 4 + fs/proc/proc_xcall.c | 178 ++++++++++++++++++++++++ include/linux/sched.h | 2 +- kernel/fork.c | 15 +-- 19 files changed, 605 insertions(+), 141 deletions(-) create mode 100644 arch/arm64/include/asm/xcall.h create mode 100644 arch/arm64/kernel/xcall/Makefile create mode 100644 arch/arm64/kernel/xcall/entry.S create mode 100644 arch/arm64/kernel/xcall/xcall.c create mode 100644 fs/proc/proc_xcall.c -- 2.34.1

2 4

[PATCH OLK-6.6] arm64/nmi: fix using wrong nmi check
by Yang Yingliang 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I90N2C CVE: NA ---------------------------------------------------------------------- If ARM64_HAS_NMI is enabled, it doesn't mean NMI is enabled. When NMI is enabled, ARM64_USES_NMI is set to true, so use it instead. Fixes: 1c203efa0a42 ("arm64/asm: Introduce assembly macros for managing ALLINT") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 38b23786aeb4..d54615963885 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -36,7 +36,7 @@ .macro disable_allint #ifdef CONFIG_ARM64_NMI -alternative_if ARM64_HAS_NMI +alternative_if ARM64_USES_NMI msr_s SYS_ALLINT_SET, xzr alternative_else_nop_endif #endif @@ -44,7 +44,7 @@ alternative_else_nop_endif .macro enable_allint #ifdef CONFIG_ARM64_NMI -alternative_if ARM64_HAS_NMI +alternative_if ARM64_USES_NMI msr_s SYS_ALLINT_CLR, xzr alternative_else_nop_endif #endif -- 2.25.1

2 1

[PATCH OLK-5.10] arm-smmu-v3: adjust ecmdq log level
by Yin Tirui 29 Jul '25

29 Jul '25

From: Tirui Yin <yintirui(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBW5SK -------------------------------- If SMMU is detected to support ECMDQ, a large number of logs will be printed during initialization. Adjust log level of ECMDQ messages from info to debug. Fixes: d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") Signed-off-by: Tirui Yin <yintirui(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 6389a1694188..524b7c2cf413 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -4495,7 +4495,7 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device *smmu, } if (!WARN_ON(q->base_dma & (qsz - 1))) { - dev_info(smmu->dev, "allocated %u entries for %s\n", + dev_dbg(smmu->dev, "allocated %u entries for %s\n", 1 << q->llq.max_n_shift, name); } -- 2.43.0

2 1

[PATCH OLK-6.6] arm-smmu-v3: adjust ecmdq log level
by Yin Tirui 29 Jul '25

29 Jul '25

From: Tirui Yin <yintirui(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBW5SK -------------------------------- If SMMU is detected to support ECMDQ, a large number of logs will be printed during initialization. Adjust log level of ECMDQ messages from info to debug. Fixes: d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") Signed-off-by: Tirui Yin <yintirui(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 6389a1694188..524b7c2cf413 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -4495,7 +4495,7 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device *smmu, } if (!WARN_ON(q->base_dma & (qsz - 1))) { - dev_info(smmu->dev, "allocated %u entries for %s\n", + dev_dbg(smmu->dev, "allocated %u entries for %s\n", 1 << q->llq.max_n_shift, name); } -- 2.43.0

2 1

openEuler Kernel SIG双周例会
by openEuler conference 29 Jul '25

29 Jul '25

您好！ Kernel 邀请您参加 2025-08-01 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，也可填报至会议纪要看板）会议链接：https://meeting.huaweicloud.com:36443/#/j/962225783 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! Kernel invites you to attend the WeLink conference(auto recording) will be held at 2025-08-01 14:00, The subject of the conference is openEuler Kernel SIG双周例会 Summary: 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，也可填报至会议纪要看板） You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/962225783 Add topics at https://etherpad.openeuler.org/p/Kernel-meetings More information: https://www.openeuler.org/en/

1 0

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] fs/resctrl: Enqueue mon_event_count() forcefully for MPAM
by Zeng Heng 29 Jul '25

29 Jul '25

Zeng Heng (2): fs/resctrl: Enqueue mon_event_count() forcefully for MPAM arm64/mpam: Ensure the err variable is initialized drivers/platform/mpam/mpam_devices.c | 8 ++++---- fs/resctrl/ctrlmondata.c | 2 +- include/linux/resctrl.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] dm-bufio: fix sched in atomic context
by Li Lingfeng 29 Jul '25

29 Jul '25

From: Sheng Yong <shengyong1(a)xiaomi.com> mainline inclusion from mainline-v6.17-rc1 commit b1bf1a782fdf5c482215c0c661b5da98b8e75773 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPD56 CVE: CVE-2025-38496 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: <TASK> dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 </TASK> That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] Cc: stable(a)vger.kernel.org # v6.4+ Fixes: 450e8dee51aa ("dm bufio: improve concurrent IO performance") Signed-off-by: Wang Shuai <wangshuai12(a)xiaomi.com> Signed-off-by: Sheng Yong <shengyong1(a)xiaomi.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Conflicts: drivers/md/dm-bufio.c [Commit 9769378133bb ("dm-bufio: remove maximum age based eviction") removed the definition of __evict_many().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-bufio.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index 30ddfb21f658..376d2d8278f7 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -2701,7 +2701,11 @@ static unsigned long __evict_many(struct dm_bufio_client *c, __make_buffer_clean(b); __free_buffer_wake(b); - cond_resched(); + if (need_resched()) { + dm_bufio_unlock(c); + cond_resched(); + dm_bufio_lock(c); + } } return count; -- 2.46.1

2 1

[PATCH OLK-6.6] livepatch: fix insn length check
by Pan Taixi 29 Jul '25

29 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICPCXQ ---------------------------------------- When livepatch checks the instruction length while ftrace is modifying the instruction, livepatch might read incorrect insn length. This tries to fix the issue by holding jump_label_lock() when doing insn check. Fixes: 4fe95df15c61 ("livepatch/core: Avoid conflict with static {call,key}") Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- kernel/livepatch/core.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index bb7ecc516b4a..6c5b3f52967a 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -21,6 +21,7 @@ #include <linux/completion.h> #include <linux/memory.h> #include <linux/rcupdate.h> +#include <linux/jump_label.h> #include <asm/cacheflush.h> #include "core.h" #ifdef CONFIG_LIVEPATCH_FTRACE @@ -1602,18 +1603,11 @@ static int check_address_conflict(struct klp_patch *patch) { struct klp_object *obj; struct klp_func *func; - int ret; + int ret = 0; void *start; void *end; - /* - * Locks seem required as comment of jump_label_text_reserved() said: - * Caller must hold jump_label_mutex. - * But looking into implementation of jump_label_text_reserved() and - * static_call_text_reserved(), call sites of every jump_label or static_call - * are checked, and they won't be changed after corresponding module inserted, - * so no need to take jump_label_lock and static_call_lock here. - */ + jump_label_lock(); klp_for_each_object(patch, obj) { klp_for_each_func(obj, func) { start = func->old_func; @@ -1622,17 +1616,21 @@ static int check_address_conflict(struct klp_patch *patch) if (ret) { pr_err("'%s' has static key in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } ret = static_call_text_reserved(start, end); if (ret) { pr_err("'%s' has static call in first %zu bytes, ret=%d\n", func->old_name, KLP_MAX_REPLACE_SIZE, ret); - return -EINVAL; + ret = -EINVAL; + goto out; } } } - return 0; +out: + jump_label_unlock(); + return ret; } static int state_show(struct seq_file *m, void *v) -- 2.34.1

2 1