- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/3] Sidecarless
by Xiaomeng Zhang 26 Mar '25

26 Mar '25

Andrii Nakryiko (1): bpf: make uniform use of array->elem_size everywhere in arraymap.c Rhys Rustad-Elliott (2): bpf: Fix elem_size not being set for inner maps selftests/bpf: Add access_inner_map selftest kernel/bpf/arraymap.c | 14 +++--- kernel/bpf/map_in_map.c | 8 +++- .../bpf/prog_tests/inner_array_lookup.c | 31 +++++++++++++ .../selftests/bpf/progs/inner_array_lookup.c | 45 +++++++++++++++++++ 4 files changed, 90 insertions(+), 8 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/inner_array_lookup.c create mode 100644 tools/testing/selftests/bpf/progs/inner_array_lookup.c -- 2.34.1

2 4

[PATCH OLK-6.6] block: don't revert iter for -EIOCBQUEUED
by Zheng Qixing 26 Mar '25

26 Mar '25

From: Jens Axboe <axboe(a)kernel.dk> stable inclusion from stable-v6.6.78 commit 84671b0630ccb46ae9f1f99a45c7d63ffcd6a474 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBRECT CVE: CVE-2025-21832 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ commit b13ee668e8280ca5b07f8ce2846b9957a8a10853 upstream. blkdev_read_iter() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdev_direct_IO() before doing an iov_iter_revert(). The latter can lead to attempting to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT. Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots. Cc: stable(a)vger.kernel.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/fops.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/block/fops.c b/block/fops.c index 33b724b1d963..cda9978ebf67 100644 --- a/block/fops.c +++ b/block/fops.c @@ -730,11 +730,12 @@ static ssize_t blkdev_read_iter(struct kiocb *iocb, struct iov_iter *to) file_accessed(iocb->ki_filp); ret = blkdev_direct_IO(iocb, to); - if (ret >= 0) { + if (ret > 0) { iocb->ki_pos += ret; count -= ret; } - iov_iter_revert(to, count - iov_iter_count(to)); + if (ret != -EIOCBQUEUED) + iov_iter_revert(to, count - iov_iter_count(to)); if (ret < 0 || !count) goto reexpand; } -- 2.39.2

2 1

[PATCH OLK-5.10 0/3] Sidecarless
by Xiaomeng Zhang 26 Mar '25

26 Mar '25

Andrii Nakryiko (1): bpf: make uniform use of array->elem_size everywhere in arraymap.c Rhys Rustad-Elliott (2): bpf: Fix elem_size not being set for inner maps selftests/bpf: Add access_inner_map selftest kernel/bpf/arraymap.c | 14 +++--- kernel/bpf/map_in_map.c | 8 +++- .../bpf/prog_tests/inner_array_lookup.c | 31 +++++++++++++ .../selftests/bpf/progs/inner_array_lookup.c | 45 +++++++++++++++++++ 4 files changed, 90 insertions(+), 8 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/inner_array_lookup.c create mode 100644 tools/testing/selftests/bpf/progs/inner_array_lookup.c -- 2.34.1

2 4

[openeuler:OLK-5.10 2821/2821] block/bio.o: warning: objtool: bvec_alloc()+0xf5: unreachable instruction
by kernel test robot 26 Mar '25

26 Mar '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 0d616a77cb5f7198cca524a24f717f59ad51b41b commit: 958384da6a734ebe7a49d0fafcea86968390e9d9 [2821/2821] block: use bi_max_vecs to find the bvec pool config: x86_64-buildonly-randconfig-005-20250325 (https://download.01.org/0day-ci/archive/20250326/202503260949.1ZCW1y7H-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250326/202503260949.1ZCW1y7H-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202503260949.1ZCW1y7H-lkp@intel.com/ All warnings (new ones prefixed by >>): >> block/bio.o: warning: objtool: bvec_alloc()+0xf5: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS 0/2] CVE-2022-49374
by Wang Liang 26 Mar '25

26 Mar '25

Hoang Le (2): tipc: add extack messages for bearer/media failure tipc: check attribute length for bearer name net/tipc/bearer.c | 53 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 41 insertions(+), 12 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] net_sched: sch_sfq: don't allow 1 packet limit
by Wang Liang 26 Mar '25

26 Mar '25

From: Octavian Purdila <tavip(a)google.com> mainline inclusion from mainline-v6.14-rc1 commit 10685681bafce6febb39770f3387621bf5d67d0b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBVH45 CVE: CVE-2024-57996 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. Reported-by: syzbot <syzkaller(a)googlegroups.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Octavian Purdila <tavip(a)google.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20241204030520.2084663-2-tavip@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/sched/sch_sfq.c [conflicts due to not merge e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets")] Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/sched/sch_sfq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c index 74f697c4a4d3..9fb5ee64834a 100644 --- a/net/sched/sch_sfq.c +++ b/net/sched/sch_sfq.c @@ -658,6 +658,9 @@ static int sfq_change(struct Qdisc *sch, struct nlattr *opt) if (!p) return -ENOMEM; } + if (ctl->limit == 1) + return -EINVAL; + sch_tree_lock(sch); if (ctl->quantum) { q->quantum = ctl->quantum; -- 2.34.1

2 1

[openeuler:OLK-5.10 2821/2821] io_uring/io_uring.o: warning: objtool: __io_uring_free()+0x69: unreachable instruction
by kernel test robot 26 Mar '25

26 Mar '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 0d616a77cb5f7198cca524a24f717f59ad51b41b commit: 2c4dc5d73facd120aab1305ec14eef4f9a524812 [2821/2821] io_uring/tctx: work around xa_store() allocation error issue config: x86_64-buildonly-randconfig-005-20250325 (https://download.01.org/0day-ci/archive/20250326/202503260613.Q2n0VF4Y-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250326/202503260613.Q2n0VF4Y-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202503260613.Q2n0VF4Y-lkp@intel.com/ All warnings (new ones prefixed by >>): >> io_uring/io_uring.o: warning: objtool: __io_uring_free()+0x69: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 2821/2821] kernel/rcu/tree.o: warning: objtool: rcu_iw_handler()+0x9e: unreachable instruction
by kernel test robot 26 Mar '25

26 Mar '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 0d616a77cb5f7198cca524a24f717f59ad51b41b commit: 44a47613c5cbb589453938cf7bf355d8043fa53f [2821/2821] irq_work: Cleanup config: x86_64-buildonly-randconfig-005-20250325 (https://download.01.org/0day-ci/archive/20250326/202503260202.467f83vo-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250326/202503260202.467f83vo-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202503260202.467f83vo-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/rcu/tree.o: warning: objtool: rcu_iw_handler()+0x9e: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1514/1514] mm/memory.c:4489:43: sparse: sparse: Using plain integer as NULL pointer
by kernel test robot 25 Mar '25

25 Mar '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a0f7a942ef42e73c8748687d469ed61f380bf0cf commit: ae0cd4d46ced733c522f2cc6da2d380d69123fc4 [1514/1514] mm: parallelize clear_gigantic_page config: x86_64-randconfig-121-20250325 (https://download.01.org/0day-ci/archive/20250325/202503252231.BsBQmABZ-lkp@…) compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250325/202503252231.BsBQmABZ-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202503252231.BsBQmABZ-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/memory.c:4489:43: sparse: sparse: Using plain integer as NULL pointer mm/memory.c:4560:22: sparse: sparse: cast removes address space '__user' of expression mm/memory.c:833:17: sparse: sparse: context imbalance in 'copy_pte_range' - different lock contexts for basic block mm/memory.c:1436:16: sparse: sparse: context imbalance in '__get_locked_pte' - different lock contexts for basic block mm/memory.c:1478:9: sparse: sparse: context imbalance in 'insert_page' - different lock contexts for basic block mm/memory.c:1579:9: sparse: sparse: context imbalance in 'insert_pfn' - different lock contexts for basic block mm/memory.c:1746:17: sparse: sparse: context imbalance in 'remap_pte_range' - different lock contexts for basic block mm/memory.c:1975:17: sparse: sparse: context imbalance in 'apply_to_pte_range' - unexpected unlock mm/memory.c:2422:17: sparse: sparse: context imbalance in 'wp_pfn_shared' - unexpected unlock mm/memory.c:2484:19: sparse: sparse: context imbalance in 'do_wp_page' - different lock contexts for basic block mm/memory.c:3055:19: sparse: sparse: context imbalance in 'pte_alloc_one_map' - different lock contexts for basic block mm/memory.c:3295:17: sparse: sparse: context imbalance in 'finish_fault' - unexpected unlock mm/memory.c:3409:9: sparse: sparse: context imbalance in 'do_fault_around' - unexpected unlock mm/memory.c:4062:12: sparse: sparse: context imbalance in '__follow_pte_pmd' - different lock contexts for basic block mm/memory.c:4146:16: sparse: sparse: context imbalance in 'follow_pte_pmd' - different lock contexts for basic block mm/memory.c:4206:9: sparse: sparse: context imbalance in 'follow_phys' - unexpected unlock In file included from mm/memory.c:72: mm/memory.c: In function 'clear_huge_page': include/linux/ktask.h:123:35: warning: cast between incompatible function types from 'int (*)(long unsigned int, long unsigned int, struct cgp_args *)' to 'int (*)(void *, void *, void *)' [-Wcast-function-type] 123 | .kc_thread_func = (ktask_thread_func)(thread_func), 22- | ^ include/linux/ktask.h:139:17: note: in expansion of macro 'KTASK_CTL_INITIALIZER' 139 | KTASK_CTL_INITIALIZER(thread_func, func_arg, min_chunk_size) 25- | ^~~~~~~~~~~~~~~~~~~~~ mm/memory.c:4491:17: note: in expansion of macro 'DEFINE_KTASK_CTL' 4491 | DEFINE_KTASK_CTL(ctl, clear_gigantic_page_chunk, &args, | ^~~~~~~~~~~~~~~~ vim +4489 mm/memory.c 4480 4481 void clear_huge_page(struct page *page, 4482 unsigned long addr_hint, unsigned int pages_per_huge_page) 4483 { 4484 unsigned long addr = addr_hint & 4485 ~(((unsigned long)pages_per_huge_page << PAGE_SHIFT) - 1); 4486 4487 if (unlikely(pages_per_huge_page > MAX_ORDER_NR_PAGES)) { 4488 struct cgp_args args = {page, addr}; > 4489 struct ktask_node node = {0, pages_per_huge_page, 4490 page_to_nid(page)}; 4491 DEFINE_KTASK_CTL(ctl, clear_gigantic_page_chunk, &args, 4492 KTASK_MEM_CHUNK); 4493 4494 ktask_run_numa(&node, 1, &ctl); 4495 return; 4496 } 4497 4498 process_huge_page(addr_hint, pages_per_huge_page, clear_subpage, page); 4499 } 4500 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1514/1514] include/linux/bpf-cgroup.h:274:41: sparse: sparse: Using plain integer as NULL pointer
by kernel test robot 25 Mar '25

25 Mar '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a0f7a942ef42e73c8748687d469ed61f380bf0cf commit: f42ee093be2980f2689ea7a170d580364820f48b [1514/1514] bpf/test_run: support cgroup local storage config: x86_64-randconfig-122-20250325 (https://download.01.org/0day-ci/archive/20250325/202503252213.JKA9UxCh-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250325/202503252213.JKA9UxCh-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202503252213.JKA9UxCh-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) net/bpf/test_run.c: note: in included file (through include/linux/cgroup-defs.h, include/linux/cgroup.h, include/net/netprio_cgroup.h, ...): >> include/linux/bpf-cgroup.h:274:41: sparse: sparse: Using plain integer as NULL pointer vim +274 include/linux/bpf-cgroup.h fdb5c4531c1e0e Sean Young 2018-06-19 267 aa0ad5b0391e26 Roman Gushchin 2018-08-02 268 static inline void bpf_cgroup_storage_set(struct bpf_cgroup_storage *storage) {} de9cbbaadba5ad Roman Gushchin 2018-08-02 269 static inline int bpf_cgroup_storage_assign(struct bpf_prog *prog, de9cbbaadba5ad Roman Gushchin 2018-08-02 270 struct bpf_map *map) { return 0; } de9cbbaadba5ad Roman Gushchin 2018-08-02 271 static inline void bpf_cgroup_storage_release(struct bpf_prog *prog, de9cbbaadba5ad Roman Gushchin 2018-08-02 272 struct bpf_map *map) {} de9cbbaadba5ad Roman Gushchin 2018-08-02 273 static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc( de9cbbaadba5ad Roman Gushchin 2018-08-02 @274 struct bpf_prog *prog) { return 0; } de9cbbaadba5ad Roman Gushchin 2018-08-02 275 static inline void bpf_cgroup_storage_free( de9cbbaadba5ad Roman Gushchin 2018-08-02 276 struct bpf_cgroup_storage *storage) {} de9cbbaadba5ad Roman Gushchin 2018-08-02 277 :::::: The code at line 274 was first introduced by commit :::::: de9cbbaadba5adf88a19e46df61f7054000838f6 bpf: introduce cgroup storage maps :::::: TO: Roman Gushchin <guro(a)fb.com> :::::: CC: Daniel Borkmann <daniel(a)iogearbox.net> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0