- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] mm/numa_remote: set default distance between remote nodes to 255
by Jinjiang Tu 20 Apr '26

20 Apr '26

hulk inclusion category: other bugzilla: https://atomgit.com/openeuler/kernel/issues/8974 ---------------------------------------- Set default distance between remote nodes to 255, indicating unreachable. Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/base/numa_remote.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/numa_remote.c b/drivers/base/numa_remote.c index 19f16d265820..74eb87ac8b26 100644 --- a/drivers/base/numa_remote.c +++ b/drivers/base/numa_remote.c @@ -16,8 +16,8 @@ /* The default distance between local node and remote node */ #define REMOTE_TO_LOCAL_DISTANCE 100 -/* The default distance between two remtoe node */ -#define REMOTE_TO_REMOTE_DISTANCE 254 +/* The default distance between two remote node */ +#define REMOTE_TO_REMOTE_DISTANCE 255 bool numa_remote_enabled __ro_after_init; static bool numa_remote_nofallback_mode __ro_after_init; -- 2.43.0

2 1

[PATCH OLK-6.6 v8 0/2] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 20 Apr '26

20 Apr '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. liqiqi (2): kvm: arm64: Add MIDR definitions and use MIDR to determine whether features are 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 | 110 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 14 insertions(+), 113 deletions(-) -- 2.43.0

2 3

[PATCH OLK-5.10] ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
by Xinyu Zheng 20 Apr '26

20 Apr '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v6.6.131 commit 9c886e63b69658959633937e3acb7ca8addf7499 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14159 CVE: CVE-2026-31426 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK> Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC Fixes: 03e9a0e05739 ("ACPI: EC: Consolidate event handler installation code") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Link: https://patch.msgid.link/20260324165458.1337233-2-bestswngs@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Conflicts: drivers/acpi/ec.c [context conflict] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/acpi/ec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index b20206316fbe..79b4dd9b733b 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1618,8 +1618,10 @@ static int acpi_ec_setup(struct acpi_ec *ec, struct acpi_device *device) int ret; ret = ec_install_handlers(ec, device); - if (ret) + if (ret) { + ec_remove_handlers(ec); return ret; + } /* First EC capable of handling transactions */ if (!first_ec) -- 2.34.1

2 1

[OLK-5.10] [Backport] ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
by Xinyu Zheng 20 Apr '26

20 Apr '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v6.6.131 commit 9c886e63b69658959633937e3acb7ca8addf7499 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14159 CVE: CVE-2026-31426 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK> Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC Fixes: 03e9a0e05739 ("ACPI: EC: Consolidate event handler installation code") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Link: https://patch.msgid.link/20260324165458.1337233-2-bestswngs@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Conflicts: drivers/acpi/ec.c [context conflict] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/acpi/ec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index b20206316fbe..79b4dd9b733b 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1618,8 +1618,10 @@ static int acpi_ec_setup(struct acpi_ec *ec, struct acpi_device *device) int ret; ret = ec_install_handlers(ec, device); - if (ret) + if (ret) { + ec_remove_handlers(ec); return ret; + } /* First EC capable of handling transactions */ if (!first_ec) -- 2.34.1

1 0

[PATCH OLK-6.6] jfs: add dmapctl integrity check to prevent invalid operations
by Li Lingfeng 20 Apr '26

20 Apr '26

From: Yun Zhou <yun.zhou(a)windriver.com> mainline inclusion from mainline-v7.1-rc1 commit cce219b203c4b9cb445e910c7090d1f58af847c5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Add check_dmapctl() to validate dmapctl structure integrity, focusing on preventing invalid operations caused by on-disk corruption. Key checks: - nleafs bounded by [0, LPERCTL] (maximum leaf nodes per dmapctl). - l2nleafs bounded by [0, L2LPERCTL] and consistent with nleafs (nleafs must be 2^l2nleafs). - leafidx must be exactly CTLLEAFIND (expected leaf index position). - height bounded by [0, L2LPERCTL >> 1] (valid tree height range). - budmin validity: NOFREE only if nleafs=0; otherwise >= BUDMIN. - Leaf nodes fit within stree array (leafidx + nleafs <= CTLTREESIZE). - Leaf node values are either non-negative or NOFREE. Invoked in dbAllocAG(), dbFindCtl(), dbAdjCtl() and dbExtendFS() when accessing dmapctl pages, catching corruption early before dmap operations trigger invalid memory access or logic errors. This fixes the following UBSAN warning. [58245.668090][T14017] ------------[ cut here ]------------ [58245.668103][T14017] UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:2641:11 [58245.668119][T14017] shift exponent 110 is too large for 32-bit type 'int' [58245.668137][T14017] CPU: 0 UID: 0 PID: 14017 Comm: 4c1966e88c28fa9 Tainted: G E 6.18.0-rc4-00253-g21ce5d4ba045-dirty #124 PREEMPT_{RT,(full)} [58245.668174][T14017] Tainted: [E]=UNSIGNED_MODULE [58245.668176][T14017] Hardware name: QEMU Ubuntu 25.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [58245.668184][T14017] Call Trace: [58245.668200][T14017] <TASK> [58245.668208][T14017] dump_stack_lvl+0x189/0x250 [58245.668288][T14017] ? __pfx_dump_stack_lvl+0x10/0x10 [58245.668301][T14017] ? __pfx__printk+0x10/0x10 [58245.668315][T14017] ? lock_metapage+0x303/0x400 [jfs] [58245.668406][T14017] ubsan_epilogue+0xa/0x40 [58245.668422][T14017] __ubsan_handle_shift_out_of_bounds+0x386/0x410 [58245.668462][T14017] dbSplit+0x1f8/0x200 [jfs] [58245.668543][T14017] dbAdjCtl+0x34c/0xa20 [jfs] [58245.668628][T14017] dbAllocNear+0x2ee/0x3d0 [jfs] [58245.668710][T14017] dbAlloc+0x933/0xba0 [jfs] [58245.668797][T14017] ea_write+0x374/0xdd0 [jfs] [58245.668888][T14017] ? __pfx_ea_write+0x10/0x10 [jfs] [58245.668966][T14017] ? __jfs_setxattr+0x76e/0x1120 [jfs] [58245.669046][T14017] __jfs_setxattr+0xa01/0x1120 [jfs] [58245.669135][T14017] ? __pfx___jfs_setxattr+0x10/0x10 [jfs] [58245.669216][T14017] ? mutex_lock_nested+0x154/0x1d0 [58245.669252][T14017] ? __jfs_xattr_set+0xb9/0x170 [jfs] [58245.669333][T14017] __jfs_xattr_set+0xda/0x170 [jfs] [58245.669430][T14017] ? __pfx___jfs_xattr_set+0x10/0x10 [jfs] [58245.669509][T14017] ? xattr_full_name+0x6f/0x90 [58245.669546][T14017] ? jfs_xattr_set+0x33/0x60 [jfs] [58245.669636][T14017] ? __pfx_jfs_xattr_set+0x10/0x10 [jfs] [58245.669726][T14017] __vfs_setxattr+0x43c/0x480 [58245.669743][T14017] __vfs_setxattr_noperm+0x12d/0x660 [58245.669756][T14017] vfs_setxattr+0x16b/0x2f0 [58245.669768][T14017] ? __pfx_vfs_setxattr+0x10/0x10 [58245.669782][T14017] filename_setxattr+0x274/0x600 [58245.669795][T14017] ? __pfx_filename_setxattr+0x10/0x10 [58245.669806][T14017] ? getname_flags+0x1e5/0x540 [58245.669829][T14017] path_setxattrat+0x364/0x3a0 [58245.669840][T14017] ? __pfx_path_setxattrat+0x10/0x10 [58245.669859][T14017] ? __se_sys_chdir+0x1b9/0x280 [58245.669876][T14017] __x64_sys_lsetxattr+0xbf/0xe0 [58245.669888][T14017] do_syscall_64+0xfa/0xfa0 [58245.669901][T14017] ? lockdep_hardirqs_on+0x9c/0x150 [58245.669913][T14017] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [58245.669927][T14017] ? exc_page_fault+0xab/0x100 [58245.669937][T14017] entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: syzbot+4c1966e88c28fa96e053(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4c1966e88c28fa96e053 Signed-off-by: Yun Zhou <yun.zhou(a)windriver.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/jfs/jfs_dmap.c | 114 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 111 insertions(+), 3 deletions(-) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 7c010ef6edb0..3369b951bcc9 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -133,6 +133,93 @@ static const s8 budtab[256] = { 2, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, -1 }; +/* + * check_dmapctl - Validate integrity of a dmapctl structure + * @dcp: Pointer to the dmapctl structure to check + * + * Return: true if valid, false if corrupted + */ +static bool check_dmapctl(struct dmapctl *dcp) +{ + s8 budmin = dcp->budmin; + u32 nleafs, l2nleafs, leafidx, height; + int i; + + nleafs = le32_to_cpu(dcp->nleafs); + /* Check basic field ranges */ + if (unlikely(nleafs > LPERCTL)) { + jfs_err("dmapctl: invalid nleafs %u (max %u)", + nleafs, LPERCTL); + return false; + } + + l2nleafs = le32_to_cpu(dcp->l2nleafs); + if (unlikely(l2nleafs > L2LPERCTL)) { + jfs_err("dmapctl: invalid l2nleafs %u (max %u)", + l2nleafs, L2LPERCTL); + return false; + } + + /* Verify nleafs matches l2nleafs (must be power of two) */ + if (unlikely((1U << l2nleafs) != nleafs)) { + jfs_err("dmapctl: nleafs %u != 2^%u", + nleafs, l2nleafs); + return false; + } + + leafidx = le32_to_cpu(dcp->leafidx); + /* Check leaf index matches expected position */ + if (unlikely(leafidx != CTLLEAFIND)) { + jfs_err("dmapctl: invalid leafidx %u (expected %u)", + leafidx, CTLLEAFIND); + return false; + } + + height = le32_to_cpu(dcp->height); + /* Check tree height is within valid range */ + if (unlikely(height > (L2LPERCTL >> 1))) { + jfs_err("dmapctl: invalid height %u (max %u)", + height, L2LPERCTL >> 1); + return false; + } + + /* Check budmin is valid (cannot be NOFREE for non-empty tree) */ + if (budmin == NOFREE) { + if (unlikely(nleafs > 0)) { + jfs_err("dmapctl: budmin is NOFREE but nleafs %u", + nleafs); + return false; + } + } else if (unlikely(budmin < BUDMIN)) { + jfs_err("dmapctl: invalid budmin %d (min %d)", + budmin, BUDMIN); + return false; + } + + /* Check leaf nodes fit within stree array */ + if (unlikely(leafidx + nleafs > CTLTREESIZE)) { + jfs_err("dmapctl: leaf range exceeds stree size (end %u > %u)", + leafidx + nleafs, CTLTREESIZE); + return false; + } + + /* Check leaf nodes have valid values */ + for (i = leafidx; i < leafidx + nleafs; i++) { + s8 val = dcp->stree[i]; + + if (unlikely(val < NOFREE)) { + jfs_err("dmapctl: invalid leaf value %d at index %d", + val, i); + return false; + } else if (unlikely(val > 31)) { + jfs_err("dmapctl: leaf value %d too large at index %d", val, i); + return false; + } + } + + return true; +} + /* * NAME: dbMount() * @@ -1376,7 +1463,7 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results) dcp = (struct dmapctl *) mp->data; budmin = dcp->budmin; - if (dcp->leafidx != cpu_to_le32(CTLLEAFIND)) { + if (unlikely(!check_dmapctl(dcp))) { jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n"); release_metapage(mp); return -EIO; @@ -1706,7 +1793,7 @@ static int dbFindCtl(struct bmap * bmp, int l2nb, int level, s64 * blkno) dcp = (struct dmapctl *) mp->data; budmin = dcp->budmin; - if (dcp->leafidx != cpu_to_le32(CTLLEAFIND)) { + if (unlikely(!check_dmapctl(dcp))) { jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n"); release_metapage(mp); @@ -2489,7 +2576,7 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level) return -EIO; dcp = (struct dmapctl *) mp->data; - if (dcp->leafidx != cpu_to_le32(CTLLEAFIND)) { + if (unlikely(!check_dmapctl(dcp))) { jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n"); release_metapage(mp); return -EIO; @@ -3458,6 +3545,11 @@ int dbExtendFS(struct inode *ipbmap, s64 blkno, s64 nblocks) return -EIO; } l2dcp = (struct dmapctl *) l2mp->data; + if (unlikely(!check_dmapctl(l2dcp))) { + jfs_error(ipbmap->i_sb, "Corrupt dmapctl page\n"); + release_metapage(l2mp); + return -EIO; + } /* compute start L1 */ k = blkno >> L2MAXL1SIZE; @@ -3475,6 +3567,10 @@ int dbExtendFS(struct inode *ipbmap, s64 blkno, s64 nblocks) if (l1mp == NULL) goto errout; l1dcp = (struct dmapctl *) l1mp->data; + if (unlikely(!check_dmapctl(l1dcp))) { + jfs_error(ipbmap->i_sb, "Corrupt dmapctl page\n"); + goto errout; + } /* compute start L0 */ j = (blkno & (MAXL1SIZE - 1)) >> L2MAXL0SIZE; @@ -3488,6 +3584,10 @@ int dbExtendFS(struct inode *ipbmap, s64 blkno, s64 nblocks) goto errout; l1dcp = (struct dmapctl *) l1mp->data; + if (unlikely(!check_dmapctl(l1dcp))) { + jfs_error(ipbmap->i_sb, "Corrupt dmapctl page\n"); + goto errout; + } /* compute start L0 */ j = 0; @@ -3507,6 +3607,10 @@ int dbExtendFS(struct inode *ipbmap, s64 blkno, s64 nblocks) if (l0mp == NULL) goto errout; l0dcp = (struct dmapctl *) l0mp->data; + if (unlikely(!check_dmapctl(l0dcp))) { + jfs_error(ipbmap->i_sb, "Corrupt dmapctl page\n"); + goto errout; + } /* compute start dmap */ i = (blkno & (MAXL0SIZE - 1)) >> @@ -3522,6 +3626,10 @@ int dbExtendFS(struct inode *ipbmap, s64 blkno, s64 nblocks) goto errout; l0dcp = (struct dmapctl *) l0mp->data; + if (unlikely(!check_dmapctl(l0dcp))) { + jfs_error(ipbmap->i_sb, "Corrupt dmapctl page\n"); + goto errout; + } /* compute start dmap */ i = 0; -- 2.52.0

2 1

[PATCH OLK-6.6] ACPI: APEI: GHES: Don't send SIGBUS to kernel threads on ARM HW errors
by Wupeng Ma 20 Apr '26

20 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8386 ------------------------------------------ On arm64, when a Synchronous External Abort (SEA) occurs in kernel context (e.g., during memory compaction via kcompactd), the error follows this path: do_sea() -> do_apei_claim_sea() -> apei_claim_sea() -> ghes_notify_sea() -> ghes_in_nmi_spool_from_list() -> irq_work_queue(&ghes_proc_irq_work) -> ghes_proc_in_irq() [IRQ context] -> ghes_do_proc() -> ghes_handle_arm_hw_error() When ghes_handle_arm_hw_error() returns false (error not recoverable), ghes_do_proc() sends SIGBUS to the current task via force_sig(SIGBUS). However, kernel threads (e.g., kcompactd) have current->mm == NULL. Sending SIGBUS to a kernel thread is meaningless and may cause unexpected behavior. The SIGBUS signal should only be delivered to user-space processes. Fix by adding a check for current->mm before sending the signal. This ensures that only tasks with a valid userspace memory mapping receive the SIGBUS signal when a hardware error cannot be recovered. Fixes: 9c72f69e011e ("arm64: add support for ARCH_HAS_COPY_MC") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- drivers/acpi/apei/ghes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 51cd04307ee4..faf521a45dbd 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -818,7 +818,7 @@ static void ghes_do_proc(struct ghes *ghes, * If no memory failure work is queued for abnormal synchronous * errors, do a force kill. */ - if (sync && !queued) { + if (sync && !queued && current->mm) { pr_err("Sending SIGBUS to current task due to memory error not recovered"); force_sig(SIGBUS); } -- 2.43.0

2 1

[PATCH OLK-6.6 1/2] xsk: introduce helper to determine rxq->frag_size
by Pan Taixi 20 Apr '26

20 Apr '26

From: Larysa Zaremba <larysa.zaremba(a)intel.com> stable inclusion from stable-v6.6.130 commit 183f940bdf9074f4fd7d32badeb0d73c93dc2070 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23377 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 16394d80539937d348dd3b9ea32415c54e67a81b ] rxq->frag_size is basically a step between consecutive strictly aligned frames. In ZC mode, chunk size fits exactly, but if chunks are unaligned, there is no safe way to determine accessible space to grow tailroom. Report frag_size to be zero, if chunks are unaligned, chunk_size otherwise. Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://patch.msgid.link/20260305111253.2317394-3-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- include/net/xdp_sock_drv.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h index 5425f7ad5ebd..e1e46de7a875 100644 --- a/include/net/xdp_sock_drv.h +++ b/include/net/xdp_sock_drv.h @@ -41,6 +41,11 @@ static inline u32 xsk_pool_get_rx_frame_size(struct xsk_buff_pool *pool) return xsk_pool_get_chunk_size(pool) - xsk_pool_get_headroom(pool); } +static inline u32 xsk_pool_get_rx_frag_step(struct xsk_buff_pool *pool) +{ + return pool->unaligned ? 0 : xsk_pool_get_chunk_size(pool); +} + static inline void xsk_pool_set_rxq_info(struct xsk_buff_pool *pool, struct xdp_rxq_info *rxq) { @@ -263,6 +268,11 @@ static inline u32 xsk_pool_get_rx_frame_size(struct xsk_buff_pool *pool) return 0; } +static inline u32 xsk_pool_get_rx_frag_step(struct xsk_buff_pool *pool) +{ + return 0; +} + static inline void xsk_pool_set_rxq_info(struct xsk_buff_pool *pool, struct xdp_rxq_info *rxq) { -- 2.34.1

2 1

[PATCH OLK-6.6 2/2] ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
by Pan Taixi 20 Apr '26

20 Apr '26

From: Larysa Zaremba <larysa.zaremba(a)intel.com> mainline inclusion from mainline-v7.0-rc3 commit e142dc4ef0f451b7ef99d09aaa84e9389af629d7 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23377 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom. This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100. Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not. Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper. Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://patch.msgid.link/20260305111253.2317394-5-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/intel/ice/ice_base.c [Adapted calculation of frag size. truesize is introduced into mainline in patch 93f53db9f9dc ("ice: switch to Page Pool"), which is not merged. Use frame_sz as the truesize of underlying buffer.] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_base.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_base.c b/drivers/net/ethernet/intel/ice/ice_base.c index 9a0682b05c4f..1408089a6549 100644 --- a/drivers/net/ethernet/intel/ice/ice_base.c +++ b/drivers/net/ethernet/intel/ice/ice_base.c @@ -557,7 +557,7 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + ice_get_frame_sz(ring)); if (err) return err; } @@ -568,10 +568,11 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) ring->rx_buf_len = xsk_pool_get_rx_frame_size(ring->xsk_pool); + u32 frag_size = xsk_pool_get_rx_frag_step(ring->xsk_pool); err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + frag_size); if (err) return err; err = xdp_rxq_info_reg_mem_model(&ring->xdp_rxq, @@ -588,7 +589,7 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + ice_get_frame_sz(ring)); if (err) return err; } -- 2.34.1

1 0

[PATCH OLK-6.6 0/2] FIX CVE-2026-23473
by Zizhi Wo 18 Apr '26

18 Apr '26

FIX CVE-2026-23473 Jens Axboe (2): io_uring/poll: improve readability of poll reference decrementing io_uring/poll: fix multishot recv missing EOF on wakeup race io_uring/poll.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6 0/2] ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
by Pan Taixi 18 Apr '26

18 Apr '26

Backport "ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz" to OLK-6.6 Include "xsk: introduce helper to determine rxq->frag_size" to introduce the helper function xsk_pool_get_rx_frag_step() Larysa Zaremba (2): xsk: introduce helper to determine rxq->frag_size ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz drivers/net/ethernet/intel/ice/ice_base.c | 7 ++++--- include/net/xdp_sock_drv.h | 10 ++++++++++ 2 files changed, 14 insertions(+), 3 deletions(-) -- 2.34.1

1 0