- Kernel - mailweb.openeuler.org

[PTACH OLK-6.6] sched: Add the qos schduler's cgroup v2 interface
by Chen Jinghuang 10 Aug '26

10 Aug '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9738 -------------------------------- Add the qos schduler's cgroup v2 interface. Cgroup v2 use the qos scheduler, as follows: offline group: echo -1 > /sys/fs/cgroup/xxxx/offline/cpu.qos_level online group: /sys/fs/cgroup/xxxx/online/cpu.qos_level Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index cdc931c14930..fd8fdaaf7cbb 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -10660,6 +10660,14 @@ static struct cftype cpu_files[] = { .write = cpu_uclamp_max_write, }, #endif +#endif +#ifdef CONFIG_QOS_SCHED + { + .name = "qos_level", + .flags = CFTYPE_NOT_ON_ROOT, + .read_s64 = cpu_qos_read, + .write_s64 = cpu_qos_write, + }, #ifdef CONFIG_SCHED_SOFT_DOMAIN { .name = "soft_domain", -- 2.34.1

1 0

[PATCH OLK-5.10] bpf, cgroup: Fix storage null-ptr-deref after replacing prog
by Pu Lehui 10 Aug '26

10 Aug '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9715 Reference: https://git.kernel.org/bpf/bpf-next/c/3f562c537e9e -------------------------------- Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Signed-off-by: Pu Lehui <pulehui(a)huawei.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Amery Hung <ameryhung(a)gmail.com> Acked-by: Leon Hwang <leon.hwang(a)linux.dev> Link: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweiclou… [1] Link: https://lore.kernel.org/bpf/20260807104403.1013064-1-pulehui@huaweicloud.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cgroup.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 41bd6032c6b4..c044c25eadbd 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -591,6 +591,20 @@ static void replace_effective_prog(struct cgroup *cgrp, } } +static bool cgroup_bpf_storages_compatible(struct bpf_prog *old_prog, + struct bpf_prog *new_prog) +{ + enum bpf_cgroup_storage_type stype; + + for_each_cgroup_storage_type(stype) { + if (old_prog->aux->cgroup_storage[stype] != + new_prog->aux->cgroup_storage[stype]) + return false; + } + + return true; +} + /** * __cgroup_bpf_replace() - Replace link's program and propagate the change * to descendants @@ -628,6 +642,9 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp, if (!found) return -ENOENT; + if (!cgroup_bpf_storages_compatible(link->link.prog, new_prog)) + return -EINVAL; + old_prog = xchg(&link->link.prog, new_prog); replace_effective_prog(cgrp, atype, link); bpf_prog_put(old_prog); -- 2.34.1

2 1

[PATCH OLK-6.6] bpf, cgroup: Fix storage null-ptr-deref after replacing prog
by Pu Lehui 10 Aug '26

10 Aug '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9715 Reference: https://git.kernel.org/bpf/bpf-next/c/3f562c537e9e -------------------------------- Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting link update with -EINVAL if new_prog's cgroup storage is incompatible with link->prog. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Signed-off-by: Pu Lehui <pulehui(a)huawei.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Amery Hung <ameryhung(a)gmail.com> Acked-by: Leon Hwang <leon.hwang(a)linux.dev> Link: https://lore.kernel.org/bpf/20260728132336.2857800-1-pulehui@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweiclou… [1] Link: https://lore.kernel.org/bpf/20260807104403.1013064-1-pulehui@huaweicloud.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cgroup.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 10bd2335631b..1c8513521951 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -824,6 +824,20 @@ static void replace_effective_prog(struct cgroup *cgrp, } } +static bool cgroup_bpf_storages_compatible(struct bpf_prog *old_prog, + struct bpf_prog *new_prog) +{ + enum bpf_cgroup_storage_type stype; + + for_each_cgroup_storage_type(stype) { + if (old_prog->aux->cgroup_storage[stype] != + new_prog->aux->cgroup_storage[stype]) + return false; + } + + return true; +} + /** * __cgroup_bpf_replace() - Replace link's program and propagate the change * to descendants @@ -862,6 +876,9 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp, if (!found) return -ENOENT; + if (!cgroup_bpf_storages_compatible(link->link.prog, new_prog)) + return -EINVAL; + old_prog = xchg(&link->link.prog, new_prog); replace_effective_prog(cgrp, atype, link); bpf_prog_put(old_prog); -- 2.34.1

2 1

[PATCH OLK-5.10] Bluetooth: add kfree in hci_cleanup_dev()
by Chen Jinghuang 09 Aug '26

09 Aug '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/1593 CVE: CVE-2026-53252 -------------------------------- When adapting commit fbdc919a77f7("[Backport] Bluetooth: fix memory leak in error path of hci_alloc_dev()"), the mainline hci_release_dev() was found to include kfree(), but the current version of hci_cleanup_dev() missed this deallocation. This commit adds the missing kfree() to prevent memory leaks and ensure resource cleanup is consistent with the mainline implementation. Fixes: fbdc919a77f7 ("[Backport] Bluetooth: fix memory leak in error path of hci_alloc_dev()") Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- net/bluetooth/hci_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index e3b98fd6e1f3..89f55b2833e8 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3938,6 +3938,7 @@ void hci_cleanup_dev(struct hci_dev *hdev) ida_simple_remove(&hci_index_ida, hdev->id); kfree_skb(hdev->sent_cmd); + kfree(hdev); } /* Suspend HCI device */ -- 2.34.1

2 1

[PATCH] erofs: fix stack-out-of-bounds in erofs_put_metabuf
by Liu Mingrui 08 Aug '26

08 Aug '26

From: Mingrui Liu <liumingrui(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16872 -------------------------------- Commit 1d4b040dd8ee moved erofs_put_metabuf() to out_unlock, but some error paths jump there before buf is initialized, unlike mainline where buf is always set. This triggers : BUG: KASAN: stack-out-of-bounds in erofs_put_metabuf+0x54/0x158 [erofs] Call Trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0xc8 print_address_description.constprop.0+0x84/0x3c8 print_report+0xb0/0x280 kasan_report+0x84/0xd0 __asan_load8+0x9c/0xc0 erofs_put_metabuf+0x54/0x158 [erofs] erofs_init_inode_xattrs+0x194/0x560 [erofs] erofs_getxattr+0xc8/0x238 [erofs] erofs_get_acl+0x6c/0x150 [erofs] __get_acl.part.0+0x218/0x390 vfs_get_acl+0xd0/0x150 do_get_acl+0x38/0x2a0 do_getxattr+0x9c/0x250 getxattr+0xe0/0x148 path_getxattr+0xdc/0x150 __arm64_sys_getxattr+0x60/0x80 invoke_syscall+0x64/0x178 el0_svc_common.constprop.0+0x11c/0x150 do_el0_svc+0x38/0x50 el0_svc+0x44/0x228 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix by zero-initializing buf at declaration so erofs_put_metabuf() can safely handle it. Fixes: 6a89c63750cb ("erofs: fix metabuf leak in inode xattr initialization") Signed-off-by: Mingrui Liu <liumingrui(a)huawei.com> --- fs/erofs/xattr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/erofs/xattr.c b/fs/erofs/xattr.c index b270226be379..abd23e990a3a 100644 --- a/fs/erofs/xattr.c +++ b/fs/erofs/xattr.c @@ -34,6 +34,8 @@ static int erofs_init_inode_xattrs(struct inode *inode) struct super_block *sb = inode->i_sb; int ret = 0; + it.buf = __EROFS_BUF_INITIALIZER; + /* the most case is that xattrs of this inode are initialized. */ if (test_bit(EROFS_I_EA_INITED_BIT, &vi->flags)) { /* @@ -76,7 +78,6 @@ static int erofs_init_inode_xattrs(struct inode *inode) goto out_unlock; } - it.buf = __EROFS_BUF_INITIALIZER; erofs_init_metabuf(&it.buf, sb); it.pos = erofs_iloc(inode) + vi->inode_isize; -- 2.34.1

1 0

[PATCH OLK-6.6] [Backport] mm: refactor mm_access() to not return NULL
by Tang Hui 08 Aug '26

08 Aug '26

From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> stable inclusion from stable-v6.6.146 commit d8a1f7420d2d58fcbde479bd72d0900fb512cb2d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16888 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cd3f8467afd470ccab0de2fbc7c76664af4a0bac ] mm_access() can return NULL if the mm is not found, but this is handled the same as an error in all callers, with some translating this into an -ESRCH error. Only proc_mem_open() returns NULL if no mm is found, however in this case it is clearer and makes more sense to explicitly handle the error. Additionally we take the opportunity to refactor the function to eliminate unnecessary nesting. d8a1f7420d2d58fcbde479bd72d0900fb512cb2d Simplify things by simply returning -ESRCH if no mm is found - this both eliminates confusing use of the IS_ERR_OR_NULL() macro, and simplifies callers which would return -ESRCH by returning this error directly. [lorenzo.stoakes(a)oracle.com: prefer neater pointer error comparison] Link: https://lkml.kernel.org/r/2fae1834-749a-45e1-8594-5e5979cf7103@lucifer.local Link: https://lkml.kernel.org/r/20240924201023.193135-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: mm/madvise.c [Context conflicts due to backport] Signed-off-by: Tang Hui <tanghui20(a)huawei.com> --- fs/proc/base.c | 26 ++++++++++++++------------ kernel/fork.c | 5 +++-- mm/madvise.c | 4 ++-- mm/process_vm_access.c | 4 ++-- 4 files changed, 21 insertions(+), 18 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index cac883cf29fa..7ee2285910bb 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -815,19 +815,21 @@ static const struct file_operations proc_single_file_operations = { struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode) { struct task_struct *task = get_proc_task(inode); - struct mm_struct *mm = ERR_PTR(-ESRCH); + struct mm_struct *mm; - if (task) { - mm = mm_access(task, mode | PTRACE_MODE_FSCREDS); - put_task_struct(task); + if (!task) + return ERR_PTR(-ESRCH); - if (!IS_ERR_OR_NULL(mm)) { - /* ensure this mm_struct can't be freed */ - mmgrab(mm); - /* but do not pin its memory */ - mmput(mm); - } - } + mm = mm_access(task, mode | PTRACE_MODE_FSCREDS); + put_task_struct(task); + + if (IS_ERR(mm)) + return mm == ERR_PTR(-ESRCH) ? NULL : mm; + + /* ensure this mm_struct can't be freed */ + mmgrab(mm); + /* but do not pin its memory */ + mmput(mm); return mm; } @@ -2205,7 +2207,7 @@ static int map_files_d_revalidate(struct dentry *dentry, unsigned int flags) goto out_notask; mm = mm_access(task, PTRACE_MODE_READ_FSCREDS); - if (IS_ERR_OR_NULL(mm)) + if (IS_ERR(mm)) goto out; if (!dname_to_vma_addr(dentry, &vm_start, &vm_end)) { diff --git a/kernel/fork.c b/kernel/fork.c index e92ddc0a0c66..7f188d166f35 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1676,8 +1676,9 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode) return ERR_PTR(err); mm = get_task_mm(task); - if (mm && mm != current->mm && - !ptrace_may_access(task, mode)) { + if (!mm) { + mm = ERR_PTR(-ESRCH); + } else if (mm != current->mm && !ptrace_may_access(task, mode)) { mmput(mm); mm = ERR_PTR(-EACCES); } diff --git a/mm/madvise.c b/mm/madvise.c index 4b7956dd6357..7fb856fc7eec 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -1846,8 +1846,8 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec, /* Require PTRACE_MODE_READ to avoid leaking ASLR metadata. */ mm = mm_access(task, PTRACE_MODE_READ_FSCREDS); - if (IS_ERR_OR_NULL(mm)) { - ret = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH; + if (IS_ERR(mm)) { + ret = PTR_ERR(mm); goto release_task; } diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c index 0523edab03a6..5be8e91aa872 100644 --- a/mm/process_vm_access.c +++ b/mm/process_vm_access.c @@ -200,8 +200,8 @@ static ssize_t process_vm_rw_core(pid_t pid, struct iov_iter *iter, } mm = mm_access(task, PTRACE_MODE_ATTACH_REALCREDS); - if (!mm || IS_ERR(mm)) { - rc = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH; + if (IS_ERR(mm)) { + rc = PTR_ERR(mm); /* * Explicitly map EACCES to EPERM as EPERM is a more * appropriate error code for process_vw_readv/writev -- 2.34.1

1 0

[PATCH OLK-6.6] erofs: fix stack-out-of-bounds in erofs_put_metabuf
by Liu Mingrui 08 Aug '26

08 Aug '26

From: Mingrui Liu <liumingrui(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16872 -------------------------------- Commit 1d4b040dd8ee moved erofs_put_metabuf() to out_unlock, but some error paths jump there before buf is initialized, unlike mainline where buf is always set. This triggers : BUG: KASAN: stack-out-of-bounds in erofs_put_metabuf+0x54/0x158 [erofs] Call Trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x78/0xc8 print_address_description.constprop.0+0x84/0x3c8 print_report+0xb0/0x280 kasan_report+0x84/0xd0 __asan_load8+0x9c/0xc0 erofs_put_metabuf+0x54/0x158 [erofs] erofs_init_inode_xattrs+0x194/0x560 [erofs] erofs_getxattr+0xc8/0x238 [erofs] erofs_get_acl+0x6c/0x150 [erofs] __get_acl.part.0+0x218/0x390 vfs_get_acl+0xd0/0x150 do_get_acl+0x38/0x2a0 do_getxattr+0x9c/0x250 getxattr+0xe0/0x148 path_getxattr+0xdc/0x150 __arm64_sys_getxattr+0x60/0x80 invoke_syscall+0x64/0x178 el0_svc_common.constprop.0+0x11c/0x150 do_el0_svc+0x38/0x50 el0_svc+0x44/0x228 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix by zero-initializing buf at declaration so erofs_put_metabuf() can safely handle it. Fixes: 6a89c63750cb ("erofs: fix metabuf leak in inode xattr initialization") Signed-off-by: Mingrui Liu <liumingrui(a)huawei.com> --- fs/erofs/xattr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/erofs/xattr.c b/fs/erofs/xattr.c index b270226be379..abd23e990a3a 100644 --- a/fs/erofs/xattr.c +++ b/fs/erofs/xattr.c @@ -34,6 +34,8 @@ static int erofs_init_inode_xattrs(struct inode *inode) struct super_block *sb = inode->i_sb; int ret = 0; + it.buf = __EROFS_BUF_INITIALIZER; + /* the most case is that xattrs of this inode are initialized. */ if (test_bit(EROFS_I_EA_INITED_BIT, &vi->flags)) { /* @@ -76,7 +78,6 @@ static int erofs_init_inode_xattrs(struct inode *inode) goto out_unlock; } - it.buf = __EROFS_BUF_INITIALIZER; erofs_init_metabuf(&it.buf, sb); it.pos = erofs_iloc(inode) + vi->inode_isize; -- 2.34.1

2 1

[PATCH OLK-6.6] x86/bugs: Enable IBPB flush on BPF JIT allocation
by Zhang Kunbo 08 Aug '26

08 Aug '26

From: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> stable inclusion from stable-v6.6.145 commit cb27f3bf915cc0f20fc0c48da9059304e39ebd35 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16808 CVE: CVE-2026-64507 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a3af84b0fa00ead01fcd0e28b5d773ff25990a0d upstream. Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence. This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n. [ pawan: Use entry_ibpb() instead of write_ibpb(). JIT hardening enable moved to spectre_v2_select_mitigation() because there is no spectre_v2_apply_mitigation()] Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/cpu/bugs.c arch/x86/include/asm/nospec-branch.h [context conflicts and use `write_ibpb` instead of `entry_ibpb` due to 13235d6d50bb ("x86/bugs: Rename entry_ibpb() to write_ibpb()") ] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/include/asm/nospec-branch.h | 4 +++ arch/x86/kernel/cpu/bugs.c | 50 +++++++++++++++++++++++++--- 2 files changed, 49 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index 58dda23aee1b..d4eae71b2ab7 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -408,6 +408,10 @@ extern void srso_alias_untrain_ret(void); extern void entry_untrain_ret(void); extern void write_ibpb(void); +#ifdef CONFIG_BPF_JIT +extern void bpf_arch_ibpb(void); +#endif + #ifdef CONFIG_X86_64 extern void clear_bhb_loop(void); #endif diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 212408f6de11..d5dd360ee330 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -16,6 +16,7 @@ #include <linux/sched/smt.h> #include <linux/pgtable.h> #include <linux/bpf.h> +#include <linux/filter.h> #include <asm/spec-ctrl.h> #include <asm/cmdline.h> @@ -1312,8 +1313,21 @@ static inline const char *spectre_v2_module_string(void) { return spectre_v2_bad_module ? " - vulnerable module loaded" : ""; } + +/* + * The "retpoline sequence" is the "call;mov;ret" sequence that + * replaces normal indirect branch instructions. Differentiate + * *the* retpoline sequence from the LFENCE-prefixed indirect + * branches that simply use the retpoline infrastructure. + */ +static inline bool retpoline_seq_enabled(void) +{ + return boot_cpu_has(X86_FEATURE_RETPOLINE) && !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE); +} + #else static inline const char *spectre_v2_module_string(void) { return ""; } +static inline bool retpoline_seq_enabled(void) { return false; } #endif #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n" @@ -1787,8 +1801,7 @@ static void __init bhi_select_mitigation(void) return; /* Retpoline mitigates against BHI unless the CPU has RRSBA behavior */ - if (boot_cpu_has(X86_FEATURE_RETPOLINE) && - !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE)) { + if (retpoline_seq_enabled()) { spec_ctrl_disable_kernel_rrsba(); if (rrsba_disabled) return; @@ -1810,6 +1823,27 @@ static void __init bhi_select_mitigation(void) pr_info("Spectre BHI mitigation: SW BHB clearing on syscall\n"); } +#ifdef CONFIG_BPF_JIT +static void __bpf_arch_ibpb(void *unused) +{ + write_ibpb(); +} + +void bpf_arch_ibpb(void) +{ + on_each_cpu(__bpf_arch_ibpb, NULL, 1); +} + +static bool __init cpu_wants_ibpb_bpf(void) +{ + /* A genuine retpoline already neutralizes ring0 indirect predictions */ + if (retpoline_seq_enabled()) + return false; + + return boot_cpu_has(X86_FEATURE_IBPB); +} +#endif + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline(); @@ -1955,6 +1989,14 @@ static void __init spectre_v2_select_mitigation(void) pr_info("Enabling Restricted Speculation for firmware calls\n"); } +#ifdef CONFIG_BPF_JIT + if (cpu_wants_ibpb_bpf()) { + static_call_update(bpf_arch_pred_flush, bpf_arch_ibpb); + static_branch_enable(&bpf_pred_flush_enabled); + pr_info("Enabling IBPB for BPF\n"); + } +#endif + /* Set up IBPB and STIBP depending on the general spectre V2 command */ spectre_v2_cmd = cmd; } @@ -3113,9 +3155,7 @@ static const char *spectre_bhi_state(void) return "; BHI: BHI_DIS_S"; else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP)) return "; BHI: SW loop, KVM: SW loop"; - else if (boot_cpu_has(X86_FEATURE_RETPOLINE) && - !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE) && - rrsba_disabled) + else if (retpoline_seq_enabled() && rrsba_disabled) return "; BHI: Retpoline"; else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT)) return "; BHI: Vulnerable, KVM: SW loop"; -- 2.34.1

2 1

[PATCH OLK-5.10] USB: serial: mct_u232: fix memory corruption with small endpoint
by Zhang Kunbo 08 Aug '26

08 Aug '26

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v5.10.259 commit 94edbbc5fe00d03cfe1d4e690d7d2cd36317a935 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16226 CVE: CVE-2026-63898 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 915b36d701950503c4ea0f6e314b10868e59fce3 upstream. The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- drivers/usb/serial/mct_u232.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c index 04f16d4a0a68..8842a1db72b3 100644 --- a/drivers/usb/serial/mct_u232.c +++ b/drivers/usb/serial/mct_u232.c @@ -378,6 +378,7 @@ static int mct_u232_port_probe(struct usb_serial_port *port) { struct usb_serial *serial = port->serial; struct mct_u232_private *priv; + u16 pid; /* check first to simplify error handling */ if (!serial->port[1] || !serial->port[1]->interrupt_in_urb) { @@ -385,6 +386,16 @@ static int mct_u232_port_probe(struct usb_serial_port *port) return -ENODEV; } + /* + * Compensate for a hardware bug: although the Sitecom U232-P25 + * device reports a maximum output packet size of 32 bytes, + * it seems to be able to accept only 16 bytes (and that's what + * SniffUSB says too...) + */ + pid = le16_to_cpu(serial->dev->descriptor.idProduct); + if (pid == MCT_U232_SITECOM_PID) + port->bulk_out_size = min(16, port->bulk_out_size); + priv = kzalloc(sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; @@ -412,7 +423,6 @@ static int mct_u232_port_remove(struct usb_serial_port *port) static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port *port) { - struct usb_serial *serial = port->serial; struct mct_u232_private *priv = usb_get_serial_port_data(port); int retval = 0; unsigned int control_state; @@ -420,15 +430,6 @@ static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port *port) unsigned char last_lcr; unsigned char last_msr; - /* Compensate for a hardware bug: although the Sitecom U232-P25 - * device reports a maximum output packet size of 32 bytes, - * it seems to be able to accept only 16 bytes (and that's what - * SniffUSB says too...) - */ - if (le16_to_cpu(serial->dev->descriptor.idProduct) - == MCT_U232_SITECOM_PID) - port->bulk_out_size = 16; - /* Do a defined restart: the normal serial device seems to * always turn on DTR and RTS here, so do the same. I'm not * sure if this is really necessary. But it should not harm -- 2.34.1

2 1

[PATCH OLK-5.10] USB: serial: mct_u232: fix memory corruption with small endpoint
by Zhang Kunbo 08 Aug '26

08 Aug '26

From: Johan Hovold <johan(a)kernel.org> commit 915b36d701950503c4ea0f6e314b10868e59fce3 upstream. The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/usb/serial/mct_u232.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c index 04f16d4a0a68..8842a1db72b3 100644 --- a/drivers/usb/serial/mct_u232.c +++ b/drivers/usb/serial/mct_u232.c @@ -378,6 +378,7 @@ static int mct_u232_port_probe(struct usb_serial_port *port) { struct usb_serial *serial = port->serial; struct mct_u232_private *priv; + u16 pid; /* check first to simplify error handling */ if (!serial->port[1] || !serial->port[1]->interrupt_in_urb) { @@ -385,6 +386,16 @@ static int mct_u232_port_probe(struct usb_serial_port *port) return -ENODEV; } + /* + * Compensate for a hardware bug: although the Sitecom U232-P25 + * device reports a maximum output packet size of 32 bytes, + * it seems to be able to accept only 16 bytes (and that's what + * SniffUSB says too...) + */ + pid = le16_to_cpu(serial->dev->descriptor.idProduct); + if (pid == MCT_U232_SITECOM_PID) + port->bulk_out_size = min(16, port->bulk_out_size); + priv = kzalloc(sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; @@ -412,7 +423,6 @@ static int mct_u232_port_remove(struct usb_serial_port *port) static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port *port) { - struct usb_serial *serial = port->serial; struct mct_u232_private *priv = usb_get_serial_port_data(port); int retval = 0; unsigned int control_state; @@ -420,15 +430,6 @@ static int mct_u232_open(struct tty_struct *tty, struct usb_serial_port *port) unsigned char last_lcr; unsigned char last_msr; - /* Compensate for a hardware bug: although the Sitecom U232-P25 - * device reports a maximum output packet size of 32 bytes, - * it seems to be able to accept only 16 bytes (and that's what - * SniffUSB says too...) - */ - if (le16_to_cpu(serial->dev->descriptor.idProduct) - == MCT_U232_SITECOM_PID) - port->bulk_out_size = 16; - /* Do a defined restart: the normal serial device seems to * always turn on DTR and RTS here, so do the same. I'm not * sure if this is really necessary. But it should not harm -- 2.34.1

2 1