- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 15 Jun '26

15 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Fixes: 36fc586982d7 ("irqchip/gicv3-its: Add workaround for HIP09/HIP10/HIP10C/HIP12 erratum 162100803/162200807/162400807/165010802") Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..e3abbf0d9a4d 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,10 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time required to clear the cache once is approximately 100 + * nanoseconds. Based on a timeout period of 1 second, we set the + * number of timeout attempts to 1,000,000. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] hugetlbfs: prevent filesystem stacking of hugetlbfs
by Zeng Heng 15 Jun '26

15 Jun '26

From: Mike Kravetz <mike.kravetz(a)oracle.com> mainline inclusion from mainline-v5.9-rc1 commit 15568299b7d9988063afce60731df605ab236e2a category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9351 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot found issues with having hugetlbfs on a union/overlay as reported in [1]. Due to the limitations (no write) and special functionality of hugetlbfs, it does not work well in filesystem stacking. There are no know use cases for hugetlbfs stacking. Rather than making modifications to get hugetlbfs working in such environments, simply prevent stacking. [1] https://lore.kernel.org/linux-mm/000000000000b4684e05a2968ca6@google.com/ Reported-by: syzbot+d6ec23007e951dadf3de(a)syzkaller.appspotmail.com Suggested-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Miklos Szeredi <mszeredi(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Colin Walters <walters(a)verbum.org> Link: http://lkml.kernel.org/r/80f869aa-810d-ef6c-8888-b46cee135907@oracle.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: fs/hugetlbfs/inode.c [Fix context conflicts.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- fs/hugetlbfs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 39a4d1f820d2..6825c870d0b5 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1452,6 +1452,12 @@ hugetlbfs_fill_super(struct super_block *sb, void *data, int silent) sb->s_magic = HUGETLBFS_MAGIC; sb->s_op = &hugetlbfs_ops; sb->s_time_gran = 1; + + /* + * Due to the special and limited functionality of hugetlbfs, it does + * not work well as a stacking filesystem. + */ + sb->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; sb->s_root = d_make_root(hugetlbfs_get_root(sb, &config)); if (!sb->s_root) goto out_free; -- 2.43.0

2 1

[PATCH OLK-6.6 0/1] KVM: arm64: Reject HDBSS enable when dirty ring is active
by Tian Zheng 15 Jun '26

15 Jun '26

Enabling HDBSS alongside the dirty ring leads to a guest hang after live migration. This occurs because HDBSS currently lacks support for the dirty ring data structures, preventing proper dirty page tracking and synchronization during migration. Add a check in kvm_cap_arm_enable_hdbss() to return -EINVAL if the dirty ring is already in use to prevent this conflicting and unsafe configuration. patchapply (1): KVM: arm64: Reject HDBSS enable when dirty ring is active arch/arm64/kvm/arm.c | 5 +++++ 1 file changed, 5 insertions(+) -- 2.33.0

1 0

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

2 1

[PATCH OLK-6.6] net:yt6801: fix the panic of call fxgmac_shutdown after ndo_stop (fxgmac_close)
by Frank_Sae 12 Jun '26

12 Jun '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9393 -------------------------------- If NetworkManager let nic down, it call ndo_stop (fxgmac_close). Then do "kexec -l /boot/vmlinuz-6.6.0-156.0.0.146.oe2403sp4.loongarch64 --initrd=/boot/initramfs-6.6.0-156.0.0.146.oe2403sp4.loongarch64.img kexec -e", it will call the fxgmac_disable_rx in fxgmac_shutdown, cause a panic: Unable to handle kernel paging request at virtual address 0000000000000398 Fixes: 6460d9d3c42d ("yt6801: Add Motorcomm yt6801 PCIe driver") Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace3c6..1216450538db 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -1417,6 +1417,10 @@ static int fxgmac_net_powerdown(struct fxgmac_pdata *priv) return 0; /* do nothing if already down */ __clear_bit(FXGMAC_POWER_STATE_UP, &priv->power_state); + + if (priv->dev_state == FXGMAC_DEV_CLOSE) + return 0; /* do nothing if already close */ + netif_tx_stop_all_queues(ndev); /* Shut off incoming Tx traffic */ /* Call carrier off first to avoid false dev_watchdog timeouts */ -- 2.30.2

2 1

[PATCH OLK-6.6] x86/kexec: Disable KCOV instrumentation after load_segments()
by Jinjie Ruan 12 Jun '26

12 Jun '26

From: Aleksandr Nogikh <nogikh(a)google.com> stable inclusion from stable-v6.12.93 commit 593d67032544b9271094fc9b43e437e017cb2b2f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14889 CVE: CVE-2026-43331 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 917e3ad3321e75ca0223d5ccf26ceda116aa51e1 ] The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ] Fixes: 0d345996e4cb ("x86/kernel: increase kcov coverage under arch/x86/kernel folder") Signed-off-by: Aleksandr Nogikh <nogikh(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260325154825.551191-1-nogikh@google.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/Makefile [context conflict.] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/Makefile | 14 ++++++++++++++ arch/x86/mm/Makefile | 2 ++ 2 files changed, 16 insertions(+) diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 341422135d9d..767bbcfd4dc3 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -39,6 +39,20 @@ KMSAN_SANITIZE_nmi.o := n KCOV_INSTRUMENT_head$(BITS).o := n KCOV_INSTRUMENT_sev.o := n +# Disable KCOV to prevent crashes during kexec: load_segments() invalidates +# the GS base, which KCOV relies on for per-CPU data. +# +# As KCOV and KEXEC compatibility should be preserved (e.g. syzkaller is +# using it to collect crash dumps during kernel fuzzing), disabling +# KCOV for KEXEC kernels is not an option. Selectively disabling KCOV +# instrumentation for individual affected functions can be fragile, while +# adding more checks to KCOV would slow it down. +# +# As a compromise solution, disable KCOV instrumentation for the whole +# source code file. If its coverage is ever needed, other approaches +# should be considered. +KCOV_INSTRUMENT_machine_kexec_64.o := n + CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace obj-y += head_$(BITS).o diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index c9d9bee63d7d..d8f01c0f717b 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -5,6 +5,8 @@ KCOV_INSTRUMENT_mem_encrypt.o := n KCOV_INSTRUMENT_mem_encrypt_amd.o := n KCOV_INSTRUMENT_mem_encrypt_identity.o := n KCOV_INSTRUMENT_pgprot.o := n +# See the "Disable KCOV" comment in arch/x86/kernel/Makefile. +KCOV_INSTRUMENT_physaddr.o := n KASAN_SANITIZE_mem_encrypt.o := n KASAN_SANITIZE_mem_encrypt_amd.o := n -- 2.34.1

2 1

[PATCH OLK-6.6] irqchip/gic-v3-its: Add DT cache clear count
by Jinqian Yang 12 Jun '26

12 Jun '26

virt inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9391 -------------------------------------------------------------------- If hundreds of virtual machines all have virtio devices and are repeatedly restarted, a large number of MAPD (v=0) entries will be generated in batches. In this scenario, it is possible that the DT cache cannot be cleared even after 100 attempts. The time required to clear the cache once is approximately 100 nanoseconds. Based on a timeout period of 1 second, we set the number of timeout attempts to 1,000,000. Signed-off-by: Jinqian Yang <yangjinqian1(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a79ee777571..e3abbf0d9a4d 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1044,7 +1044,7 @@ static struct its_collection u32 *dt_entry; void __iomem *its_func_en = its->sgir_base + 0x80; u32 tmp, tmp1, mask = 1 << 19; - int i = 100; + int i = 1000000; /* * The device table is flat. Modify v to 0 in the dt entry of devid, @@ -1062,6 +1062,10 @@ static struct its_collection * (offset is 0x20000), so address of GITS_FUNC_EN can be got by * sgir_base + 0x80. Bit 16 is used to clear DT cache, the flip of * bit 19 indicates that DT cache has been cleared. + * + * The time required to clear the cache once is approximately 100 + * nanoseconds. Based on a timeout period of 1 second, we set the + * number of timeout attempts to 1,000,000. */ while (--i) { tmp = readl_relaxed(its_func_en) & mask; -- 2.33.0

2 1

[PATCH OLK-5.10] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index ea519c4fa7b3..3bb9c0dced6e 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1205,10 +1205,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] dm: fix a buffer overflow in ioctl processing
by Lu Chentao 12 Jun '26

12 Jun '26

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.10.209 commit c8c5311237448f6ffeecc9aec2362e3692623668 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15577 CVE: CVE-2026-46294 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------------------------------------- commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson <tasleson(a)redhat.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: Bryn M. Reeves <bmr(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Chentao <luchentao1(a)huawei.com> --- drivers/md/dm-ioctl.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index 2b00359e4825..bf6251fa5c3d 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1169,10 +1169,14 @@ static void retrieve_status(struct dm_table *table, outptr += l; used = param->data_start + (outptr - outbuf); outptr = align_ptr(outptr); + if (!outptr || outptr > outbuf + len) { + param->flags |= DM_BUFFER_FULL_FLAG; + break; + } spec->next = outptr - outbuf; } if (used) param->data_size = used; -- 2.52.0

2 1

[PATCH OLK-6.6] netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
by superdcc97＠163.com 12 Jun '26

12 Jun '26

From: Qi Tang <tpluszz77(a)gmail.com> stable inclusion from stable-v6.6.134 commit 2898080c054ea4d6ddfaaf21bbedbc229a9a8376 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14558 CVE: CVE-2026-43026 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 35177c6877134a21315f37d57a5577846225623e ] ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Qi Tang <tpluszz77(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/netfilter/nf_conntrack_netlink.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index 67a0762915e3..90c32031bcf1 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -3571,6 +3571,12 @@ ctnetlink_alloc_expect(const struct nlattr * const cda[], struct nf_conn *ct, exp, nf_ct_l3num(ct)); if (err < 0) goto err_out; +#if IS_ENABLED(CONFIG_NF_NAT) + } else { + memset(&exp->saved_addr, 0, sizeof(exp->saved_addr)); + memset(&exp->saved_proto, 0, sizeof(exp->saved_proto)); + exp->dir = 0; +#endif } return exp; err_out: -- 2.43.0

2 1