- Kernel - mailweb.openeuler.org

[PATCH 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[PATCH OLK-6.6] arm64: fix compile error if CONFIG_ARCH_HAS_COPY_MC not enabled
by Wupeng Ma 24 Mar '26

24 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8386 ------------------------------------------ If CONFIG_ARCH_HAS_COPY_MC is not enabled, kernel can not be compiled with the following error: aarch64-linux-gnu-ld: arch/arm64/mm/flush.o: in function `copy_mc_to_user_page': arch/arm64/mm/flush.c:56:(.text+0x3a4): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/memory.o: in function `__access_remote_vm': mm/memory.c:6674:(.text+0xe138): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/kasan/shadow.o: in function `memcpy_mc': mm/kasan/shadow.c:90:(.text+0xa94): undefined reference to `__memcpy_mc' Fix this by add stub function of memcpy_mc which just call memcpy. Fixes: d51d1b114c86 ("arm64: mm: support recovery from copy_{from/to}_user_page()") Fixes: b991780c836c ("arm64: introduce copy_mc_to_kernel() implementation") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- arch/arm64/include/asm/string.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h index 23eca4fb24fa6..97844a8e3ed3a 100644 --- a/arch/arm64/include/asm/string.h +++ b/arch/arm64/include/asm/string.h @@ -36,8 +36,13 @@ extern void *memcpy(void *, const void *, __kernel_size_t); extern void *__memcpy(void *, const void *, __kernel_size_t); #define __HAVE_ARCH_MEMCPY_MC +#ifdef CONFIG_ARCH_HAS_COPY_MC extern int memcpy_mc(void *, const void *, __kernel_size_t); extern int __memcpy_mc(void *, const void *, __kernel_size_t); +#else +#define memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#define __memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#endif #define __HAVE_ARCH_MEMMOVE extern void *memmove(void *, const void *, __kernel_size_t); @@ -61,7 +66,9 @@ void memcpy_flushcache(void *dst, const void *src, size_t cnt); */ #define memcpy(dst, src, len) __memcpy(dst, src, len) +#ifndef memcpy_mc #define memcpy_mc(dst, src, len) __memcpy_mc(dst, src, len) +#endif #define memmove(dst, src, len) __memmove(dst, src, len) #define memset(s, c, n) __memset(s, c, n) -- 2.43.0

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for
by liqiqi 24 Mar '26

24 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[openEuler-25.03, 0/1] mm: arm64: Add user replication feature with control policies.
by Gadeev Dmitry 24 Mar '26

24 Mar '26

This patchset implements support of userspace translation tables and private read-only data replication for AArch64 and is going to improve latency and memory bandwidth by reducing cross-NUMA memory accesses. openEuler 25.03 is used as a baseline. Current implementation supports next functionality: 1. Per-NUMA node replication of userspace translation tables and private read-only data. We replicate only __private read-only__ data to avoid dealing with replicas coherence and consistency support. Translation tables, in turn, are able to replicate for any kind of underlying data. 2. Ability to enable userspace replication for a certain process via procfs or for a group of processes via memory cgroup. 3. 4K and 64K pages are supported. 4. Several table replication policies supported: 0 - table replication disabled; 1 - table replication enabled only for data might be replicated, e.g. private read-only data; 2 - table replication enabled for any data; Tables are getting replicated during page faults. Several data replication policies supported as well: 0 - data replication disabled; 1 - appropriate data getting replicated on NUMA faults via NUMA balancer; 2 - appropriate data that has been already faulted in are getting replicated immediately, further data will be replicated on NUMA faults. That is no difference between 1 and 2 policies if it is enabled at the start of a process. 3 - appropriate data (with related page tables) are getting replicated immediately after populating either on page faults or somehow else. Data replication might be enabled (!= 0) only with table replication enabled (!= 0). 5. Replicated data pages can't be a ksm, migration or swap/reclaim candidates by design. But for other pages these work as well with replicated translation tables support. Known problems: 1. Current implementation doesn't support huge pages, so you have to build the kernel with huge pages disabled for user replication to work. Huge pages support will be added in the nearest future. 2. mremap syscall doesn't work with replicated memory yet. 3. page_idle, uprobes and userfaultfd support replicated translation tables, but not replicated data. Be responsible using these features with userspace replication enabled. 4. When replicating translation tables during page faults, there should be enough space on __each__ NUMA node for table allocations. Otherwise it will cause OOM-killer. Despite the problems above, they are mostly not related to workloads assumed to benefit from user replication feature, and such workloads will work properly with the feature enabled. Gadeev Dmitry (1): mm: Support NUMA-aware replication of read-only data and translation tables of user space applications with different policies arch/arm64/include/asm/numa_replication.h | 3 + arch/arm64/mm/init.c | 2 +- arch/arm64/mm/pgd.c | 13 +- fs/exec.c | 7 + fs/proc/base.c | 149 ++ fs/proc/task_mmu.c | 112 +- include/asm-generic/pgalloc.h | 19 +- include/asm-generic/tlb.h | 22 + include/linux/cgroup.h | 1 + include/linux/gfp_types.h | 12 +- include/linux/memcontrol.h | 4 + include/linux/mm.h | 77 +- include/linux/mm_inline.h | 5 + include/linux/mm_types.h | 70 +- include/linux/numa_kernel_replication.h | 237 ++- include/linux/numa_user_replication.h | 827 ++++++++ include/linux/page-flags.h | 18 +- include/trace/events/mmflags.h | 10 +- include/uapi/asm-generic/mman-common.h | 3 + kernel/cgroup/cgroup.c | 2 +- kernel/events/uprobes.c | 5 +- kernel/fork.c | 18 + kernel/sched/fair.c | 8 +- mm/Kconfig | 13 + mm/Makefile | 1 + mm/gup.c | 15 +- mm/ksm.c | 15 +- mm/madvise.c | 19 +- mm/memcontrol.c | 181 +- mm/memory.c | 566 +++++- mm/mempolicy.c | 5 + mm/migrate.c | 11 +- mm/migrate_device.c | 17 +- mm/mlock.c | 22 + mm/mmap.c | 26 + mm/mmu_gather.c | 55 +- mm/mprotect.c | 424 ++-- mm/mremap.c | 97 +- mm/numa_kernel_replication.c | 5 +- mm/numa_user_replication.c | 2242 +++++++++++++++++++++ mm/page_alloc.c | 8 +- mm/page_idle.c | 3 +- mm/page_vma_mapped.c | 3 +- mm/rmap.c | 41 +- mm/swap.c | 7 +- mm/swapfile.c | 3 +- mm/userfaultfd.c | 7 +- mm/userswap.c | 11 +- 48 files changed, 4979 insertions(+), 442 deletions(-) create mode 100644 include/linux/numa_user_replication.h create mode 100644 mm/numa_user_replication.c -- 2.53.0

2 3

[PATCH OLK-5.10] arm64/mpam: Add nrdy latency to mbw_rdmon.
by Quanmin Yan 24 Mar '26

24 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8421 Reference: https://atomgit.com/openeuler/kernel/pull/15200 -------------------------------- On some platforms, when configuring a new partid, the NRDY bit remains 0, we need to re-read the statistics result to ensure accurate data. However, due to the statistical mechanism, this re-reading needs to have a certain nrdy delay; otherwise, statistical errors may occur. Fix it by adding nrdy latency to mbw_rdmon. Fixes: da1960a8d3b4 ("arm64/mpam: Add quirk for MPAM MSMON_MBWU monitor NRDY bit") Signed-off-by: Quanmin Yan <yanquanmin1(a)huawei.com> --- arch/arm64/kernel/mpam/mpam_resctrl.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/mpam/mpam_resctrl.c b/arch/arm64/kernel/mpam/mpam_resctrl.c index 4cc18c90a601..51b4edb1b1bb 100644 --- a/arch/arm64/kernel/mpam/mpam_resctrl.c +++ b/arch/arm64/kernel/mpam/mpam_resctrl.c @@ -490,7 +490,7 @@ static u64 cache_rdmon(struct rdt_domain *d, void *md_priv) static u64 mbw_rdmon(struct rdt_domain *d, void *md_priv) { int err; - u64 result; + u64 result, wait_jiffies; union mon_data_bits md; struct sync_args args; struct mpam_resctrl_dom *dom; @@ -520,7 +520,19 @@ static u64 mbw_rdmon(struct rdt_domain *d, void *md_priv) err = mpam_component_mon(dom->comp, &args, &result); /* Currently just report it */ WARN_ON(err && (err != -EBUSY)); - } while (err == -EBUSY); + + if (err != -EBUSY) + break; + + /* + * The "nrdy_usec" needs to be waited. Since there is + * currently no way to obtain "arm,not-ready-us", + * only a hardcoded value is written. + */ + wait_jiffies = usecs_to_jiffies(1000); + while (wait_jiffies) + wait_jiffies = schedule_timeout_uninterruptible(wait_jiffies); + } while (1); return result; } -- 2.43.0

2 1

[PATCH OLK-6.6 0/9] prevent SEA storms on critical RAS
by Wupeng Ma 23 Mar '26

23 Mar '26

After a critical RAS event is triggered, user data for this task becomes inaccessible. To prevents wider system impact, following step will be done: - sending SIGBUS to threads belong to this task - skip memory access during __access_remote_vm - skip memory access during exit_ruobus_list - skip memory access during rseq_get_rseq_cs - skip memory access during do_coredump Jiacheng Yu (1): futex: avoid memory access during exit_robust_list if task facing critical RAS Wupeng Ma (5): mm: memory_failure: fix UAF in memory_failure_cb ACPI: APEI: Add MMF_RAS_CRITICAL to mark critical RAS scenarios in mm struct coredump: skip coredump during critical error if task facing critical RAS mm: avoid memory access during __access_remote_vm if task facing critical RAS arm64: openeuler_defconfig: enable ras critical related configs by default Xiaofei Tan (1): ACPI: APEI: Add vendor specific error info handling for ARM Processor Zhang Qiao (2): exit: terminate process on critical RAS events to prevent further damage rseq: avoid memory access during rseq_get_rseq_cs if task facing critical RAS arch/arm64/configs/openeuler_defconfig | 2 + drivers/acpi/apei/Kconfig | 14 ++++ drivers/acpi/apei/Makefile | 1 + drivers/acpi/apei/apei-internal.h | 11 ++++ drivers/acpi/apei/ghes-vendor-info.c | 90 ++++++++++++++++++++++++++ drivers/acpi/apei/ghes.c | 60 +++++++++++++++-- fs/coredump.c | 15 +++++ include/linux/mm.h | 12 ++++ include/linux/sched/coredump.h | 6 ++ kernel/futex/core.c | 3 + kernel/rseq.c | 3 + mm/memory.c | 5 ++ 12 files changed, 217 insertions(+), 5 deletions(-) create mode 100644 drivers/acpi/apei/ghes-vendor-info.c -- 2.43.0

2 10

[PATCH v4 OLK-6.6] hugetlb: drain pcp for movable zone before alloc
by Wupeng Ma 23 Mar '26

23 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8761 -------------------------------- Memory retained in Per-CPU Pages (PCP) caches can prevent hugepage allocations from succeeding despite sufficient free system memory. This occurs because hugepage allocations don't actively trigger PCP draining. Reproduction: - Alloc page and free the page via put_page to release to pcp - Observe hugepage reservation failure Solution: Actively drain PCP during hugetlb memory allocation for movable node. Verification: This issue can be reproduce easily in zone movable with the following step: w/o this patch # numactl -m 2 dd if=/dev/urandom of=/dev/shm/testfile bs=4k count=64 # rm -f /dev/shm/testfile # sync # echo 3 > /proc/sys/vm/drop_caches # echo 2048 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages # cat /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages 2029 w/ this patch # numactl -m 2 dd if=/dev/urandom of=/dev/shm/testfile bs=4k count=64 # rm -f /dev/shm/testfile # sync # echo 3 > /proc/sys/vm/drop_caches # echo 2048 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages # cat /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages 2044 Commit 3a1587ef612c ("mm/numa_remote: introduce hugetlb_nowatermark mode for remote node") already bring the basic mechanism and this patch extends it to movable_node_is_enabled(). Since param h is not used, remove it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/hugetlb.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index d8fe41a77cd2..c61232d4d582 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3835,22 +3835,26 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, return 1; } -#ifdef CONFIG_ZONE_EXTMEM -static void hugetlb_drain_remote_pcp(struct hstate *h, int nid) +static void hugetlb_drain_zone(struct zone *zone) { - pg_data_t *pgdat = NODE_DATA(nid); - struct zone *zone; - - zone = &pgdat->node_zones[ZONE_EXTMEM]; + if (!zone_managed_pages(zone)) + return; - if (zone_managed_pages(zone)) - drain_all_pages(zone); + drain_all_pages(zone); } -#else -static inline void hugetlb_drain_remote_pcp(struct hstate *h, int nid) + +static void hugetlb_drain_pcp(int nid) { -} + pg_data_t *pgdat = NODE_DATA(nid); + + if (movable_node_is_enabled()) + hugetlb_drain_zone(&pgdat->node_zones[ZONE_MOVABLE]); + +#ifdef CONFIG_ZONE_EXTMEM + if (numa_remote_hugetlb_nowatermark(nid)) + hugetlb_drain_zone(&pgdat->node_zones[ZONE_EXTMEM]); #endif +} #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages) static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, @@ -3947,8 +3951,8 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, /* yield cpu to avoid soft lockup */ cond_resched(); - if ((nid != NUMA_NO_NODE) && numa_remote_hugetlb_nowatermark(nid) && !drained) { - hugetlb_drain_remote_pcp(h, nid); + if ((nid != NUMA_NO_NODE) && !drained) { + hugetlb_drain_pcp(nid); drained = true; } -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] sched/cputime: Fix time overflow in cputime_adjust()
by Xia Fukun 23 Mar '26

23 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8331 CVE: NA ------------------ When a process has hundreds of threads and runs for an extended period, the aggregated stime or utime of its thread group can become extremely large. Accessing /proc/xx/stat then triggers a divide error like the following: divide error: 0000 [#1] SMP NOPTI CPU: 273 PID: 4619 Comm: ... Tainted: 5.10.0 x86_64 RIP: 0010:cputime_adjust+0x55/0xb0 RSP: 0018:ffffae408e07bbc8 EFLAGS: 00010807 ... Call Trace: thread_group_cputime_adjusted+0x4b/0x70 do_task_stat+0x2d8/0xdc0 This issue is caused by an overflow in stime + utime. In older kernel versions, this overflow could lead to a division-by-zero error in scale_stime(). Although the scale_stime() function itself might exhibit issues under certain specially crafted inputs, the actual arguments passed to it are constrained by the context at its call sites within the kernel. Given that this interface is no longer used in newer kernel versions, only this minimal fix is applied. Add overflow detection logic and, upon overflow, right-shift the values before computation. This fixes the issue while preserving the original calculation semantics. Fixes: 9d7fb0427648 ("sched/cputime: Guarantee stime + utime == rtime") Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- kernel/sched/cputime.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index 4055f2008cc6..e2077ee4c710 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -692,6 +692,7 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev, u64 *ut, u64 *st) { u64 rtime, stime, utime; + u64 s, u, sum; unsigned long flags; /* Serialize concurrent callers such that we can honour our guarantees */ @@ -727,7 +728,23 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev, goto update; } - stime = scale_stime(stime, rtime, stime + utime); + s = stime; + u = utime; + sum = s + u; + + /* + * Detect unsigned overflow: if sum < either operand, + * overflow occurred. A single right shift is sufficient + * to guarantee that the new sum won't overflow. + */ + if (unlikely(sum < s)) { + s >>= 1; + u >>= 1; + sum = s + u; + stime = scale_stime(s, rtime, sum); + } else { + stime = scale_stime(stime, rtime, stime + utime); + } /* * Because mul_u64_u64_div_u64() can approximate on some * achitectures; enforce the constraint that: a*b/(b+c) <= a. -- 2.34.1

2 2