- Kernel - mailweb.openeuler.org

[PATCH v2 OLK-6.6 0/5] arm64/ras: Firmware-first SEI error handling with ESB synchronization
by Wupeng Ma 15 Apr '26

15 Apr '26

This series introduces firmware-first RAS (Reliability, Availability, and Serviceability) error handling for ARM64 SEI (Synchronous External Interrupt) errors, with support for ESB (Error Synchronization Barrier) synchronization. The implementation includes: - Boot parameter to enable/disable ESB synchronization for SEI - Entry code patching to use ESB instruction for SEI handling - Vendor-specific SEI error handling via APEI/GHES - Sysctl interface for runtime control of vendor SEI handling Change log since v1: - Fix memory leaks in err_pool_alloc and err_pa=0 paths in hisi_sei_kill_task Liao Chang (1): arm64/entry: Add support to synchronize SEI at the exception boundary Wupeng Ma (3): ACPI/APEI/arm64: add vendor SEI handling for firmware-first RAS ACPI: APEI: add runtime switch for HiSilicon vendor SEI handling arm64: openeuler_defconfig: enable CONFIG_ARM64_SYNC_SEI by default Zheng Chuan (1): arm64: Add boot parameter to control ESB for SEI synchronization .../admin-guide/kernel-parameters.txt | 8 + Documentation/admin-guide/sysctl/kernel.rst | 27 +++ arch/arm64/Kconfig | 14 ++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/acpi.h | 2 + arch/arm64/include/asm/setup.h | 9 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/arm64_sync_sei.c | 45 +++++ arch/arm64/kernel/entry.S | 44 +++++ arch/arm64/kernel/traps.c | 15 ++ arch/arm64/kernel/xcall/entry.S | 2 + drivers/acpi/apei/apei-internal.h | 2 + drivers/acpi/apei/ghes-vendor-info.c | 187 +++++++++++++++++- drivers/acpi/apei/ghes.c | 5 + 14 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/kernel/arm64_sync_sei.c -- 2.43.0

2 6

[PATCH OLK-5.10 0/2] Fix CVE-2026-23271
by Luo Gengkun 15 Apr '26

15 Apr '26

Luo Gengkun (1): perf: Fix Wdeclaration-after-statement Peter Zijlstra (1): perf: Fix __perf_event_overflow() vs perf_remove_from_context() race kernel/events/core.c | 57 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 00/28] ext4 hardware atomic write support
by Long Li 15 Apr '26

15 Apr '26

This patch set support ext4 hardware atomic write. Alan Adamson (1): nvme: Atomic write support John Garry (10): block: Pass blk_queue_get_max_sectors() a request pointer block: Generalize chunk_sectors support as boundary support block: Add core atomic write support block: Call blkdev_dio_unaligned() from blkdev_direct_IO() block: Add fops atomic write support block/fs: Pass an iocb to generic_atomic_write_valid() fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid() block: Add bdev atomic write limits helpers fs: Export generic_atomic_write_valid() fs: iomap: Atomic write support Long Li (3): block: fix kabi broken in struct queue_limits fs: fix kabi broken in struct kstat block: fix kabi broken in enum req_flag_bits Prasad Singamsetty (2): fs: Initial atomic write support fs: Add initial atomic write support info to statx Ritesh Harjani (IBM) (12): ext4: Add statx support for atomic writes ext4: Check for atomic writes support in write iter ext4: Support setting FMODE_CAN_ATOMIC_WRITE ext4: Do not fallback to buffered-io for DIO atomic write ext4: Document an edge case for overwrites ext4: Check if inode uses extents in ext4_inode_can_atomic_write() ext4: Make ext4_meta_trans_blocks() non-static for later use ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS ext4: Add multi-fsblock atomic write support with bigalloc ext4: Enable support for ext4 multi-fsblock atomic write using bigalloc ext4: Add atomic block write documentation iomap: Lift blocksize restriction on atomic writes Documentation/ABI/stable/sysfs-block | 53 +++ .../filesystems/ext4/atomic_writes.rst | 225 ++++++++++++ Documentation/filesystems/ext4/overview.rst | 1 + block/blk-core.c | 19 + block/blk-merge.c | 67 +++- block/blk-mq.c | 2 +- block/blk-settings.c | 87 +++++ block/blk-sysfs.c | 33 ++ block/blk.h | 9 +- block/fops.c | 51 ++- drivers/md/dm.c | 2 +- drivers/nvme/host/core.c | 54 ++- fs/aio.c | 8 +- fs/btrfs/ioctl.c | 2 +- fs/ext4/ext4.h | 35 +- fs/ext4/extents.c | 99 +++++ fs/ext4/file.c | 31 +- fs/ext4/inode.c | 346 ++++++++++++++++-- fs/ext4/super.c | 34 ++ fs/iomap/direct-io.c | 38 +- fs/iomap/trace.h | 3 +- fs/read_write.c | 22 +- fs/stat.c | 34 ++ include/linux/blk_types.h | 8 +- include/linux/blkdev.h | 84 ++++- include/linux/fs.h | 18 +- include/linux/iomap.h | 1 + include/linux/stat.h | 5 +- include/uapi/linux/fs.h | 5 +- include/uapi/linux/stat.h | 11 +- io_uring/rw.c | 8 +- 31 files changed, 1308 insertions(+), 87 deletions(-) create mode 100644 Documentation/filesystems/ext4/atomic_writes.rst -- 2.39.2

2 29

[PATCH OLK-5.10] nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
by Li Lingfeng 14 Apr '26

14 Apr '26

From: Jeff Layton <jlayton(a)kernel.org> mainline inclusion from mainline-v7.0-rc5 commit 5133b61aaf437e5f25b1b396b14242a6bb0508e2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14128 CVE: CVE-2026-31402 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)kernel.org Reported-by: Nicholas Carlini <npc(a)anthropic.com> Tested-by: Nicholas Carlini <npc(a)anthropic.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/nfs4xdr.c [Commit 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.") add mapping for status.] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 9 +++++++-- fs/nfsd/state.h | 17 ++++++++++++----- 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 821c0ad5baa0..b8976c2f17fe 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -5233,9 +5233,14 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) int len = xdr->buf->len - post_err_offset; so->so_replay.rp_status = op->status; - so->so_replay.rp_buflen = len; - read_bytes_from_xdr_buf(xdr->buf, post_err_offset, + if (len <= NFSD4_REPLAY_ISIZE) { + so->so_replay.rp_buflen = len; + read_bytes_from_xdr_buf(xdr->buf, + post_err_offset, so->so_replay.rp_buf, len); + } else { + so->so_replay.rp_buflen = 0; + } } status: /* Note that op->status is already in network byte order: */ diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h index 0e4f98b41364..f398effabeef 100644 --- a/fs/nfsd/state.h +++ b/fs/nfsd/state.h @@ -395,11 +395,18 @@ struct nfs4_client_reclaim { struct xdr_netobj cr_princhash; }; -/* A reasonable value for REPLAY_ISIZE was estimated as follows: - * The OPEN response, typically the largest, requires - * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + 8(verifier) + - * 4(deleg. type) + 8(deleg. stateid) + 4(deleg. recall flag) + - * 20(deleg. space limit) + ~32(deleg. ace) = 112 bytes +/* + * REPLAY_ISIZE is sized for an OPEN response with delegation: + * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + + * 8(verifier) + 4(deleg. type) + 8(deleg. stateid) + + * 4(deleg. recall flag) + 20(deleg. space limit) + + * ~32(deleg. ace) = 112 bytes + * + * Some responses can exceed this. A LOCK denial includes the conflicting + * lock owner, which can be up to 1024 bytes (NFS4_OPAQUE_LIMIT). Responses + * larger than REPLAY_ISIZE are not cached in rp_ibuf; only rp_status is + * saved. Enlarging this constant increases the size of every + * nfs4_stateowner. */ #define NFSD4_REPLAY_ISIZE 112 -- 2.52.0

2 1

[PATCH OLK-5.10 0/2] Fix CVE-2026-23271
by Luo Gengkun 14 Apr '26

14 Apr '26

Luo Gengkun (1): perf: Fix Wdeclaration-after-statement Peter Zijlstra (1): perf: Fix __perf_event_overflow() vs perf_remove_from_context() race kernel/events/core.c | 57 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/5] arm64/ras: Firmware-first SEI error handling with ESB synchronization
by Wupeng Ma 14 Apr '26

14 Apr '26

This series introduces firmware-first RAS (Reliability, Availability, and Serviceability) error handling for ARM64 SEI (Synchronous External Interrupt) errors, with support for ESB (Error Synchronization Barrier) synchronization. The implementation includes: - Boot parameter to enable/disable ESB synchronization for SEI - Entry code patching to use ESB instruction for SEI handling - Vendor-specific SEI error handling via APEI/GHES - Sysctl interface for runtime control of vendor SEI handling Liao Chang (1): arm64/entry: Add support to synchronize SEI at the exception boundary Wupeng Ma (3): ACPI/APEI/arm64: add vendor SEI handling for firmware-first RAS ACPI: APEI: add runtime switch for HiSilicon vendor SEI handling arm64: openeuler_defconfig: enable CONFIG_ARM64_SYNC_SEI by default Zheng Chuan (1): arm64: Add boot parameter to control ESB for SEI synchronization .../admin-guide/kernel-parameters.txt | 8 + Documentation/admin-guide/sysctl/kernel.rst | 27 +++ arch/arm64/Kconfig | 14 ++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/acpi.h | 2 + arch/arm64/include/asm/setup.h | 9 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/arm64_sync_sei.c | 45 +++++ arch/arm64/kernel/entry.S | 44 +++++ arch/arm64/kernel/traps.c | 15 ++ arch/arm64/kernel/xcall/entry.S | 2 + drivers/acpi/apei/apei-internal.h | 2 + drivers/acpi/apei/ghes-vendor-info.c | 186 +++++++++++++++++- drivers/acpi/apei/ghes.c | 5 + 14 files changed, 360 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/kernel/arm64_sync_sei.c -- 2.43.0

2 6

[PATCH OLK-6.6 0/4] Introduce xSched dmem
by Liu Kai 14 Apr '26

14 Apr '26

Introduce xSched dmem Alexander Pavlenko (2): xSched/dmem: introduce xsched_dmem_alloc() xSched/dmem: introduce xsched_dmem_free() Liu Kai (2): xSched/dmem: add support for XPU devices to register/unregister dmem regions xSched/dmem: introduce xsched_dmem_cleanup() include/linux/cgroup_dmem.h | 2 - include/linux/xsched.h | 14 ++ include/uapi/linux/xsched/xcu_vstream.h | 9 + kernel/xsched/Makefile | 1 + kernel/xsched/core.c | 3 + kernel/xsched/dmem.c | 226 ++++++++++++++++++++++++ kernel/xsched/vstream.c | 99 +++++++++++ 7 files changed, 352 insertions(+), 2 deletions(-) create mode 100644 kernel/xsched/dmem.c -- 2.34.1

2 5

[PATCH OLK-6.6] fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error
by Zizhi Wo 14 Apr '26

14 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8926 -------------------------------- [BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 [ 51.115408] handle_mm_fault+0x24c/0x570 [ 51.115958] do_user_addr_fault+0x226/0xa50 ... Crash analysis showed the file involved was an AIO ring file. [CAUSE] PARENT process CHILD process t=0 io_setup(1, &ctx) [access ctx addr] fork() io_destroy vm_munmap // not affect child vma percpu_ref_put ... put_aio_ring_file t=1 [access ctx addr] // pagefault ... __do_fault filemap_fault max_idx = DIV_ROUND_UP t=2 truncate_setsize truncate_pagecache t=3 filemap_get_folio // no folio __filemap_get_folio(FGP_CREAT, ...) filemap_read_folio(xxx->read_folio) At t=0, the parent process calls io_setup and then fork. The child process gets its own VMA but without any PTEs. The parent then calls io_destroy. Before i_size is truncated to 0, at t=1 the child process accesses this AIO ctx address and triggers a pagefault. After the max_idx check passes, at t=2 the parent calls truncate_setsize and truncate_pagecache. At t=3 the child fails to obtain the folio, falls into the "page_not_uptodate" path, and hits this problem because AIO does not implement "read_folio". [Fix] Fix this by marking the AIO ring buffer VMA with VM_DONTCOPY so that fork()'s dup_mmap() skips it entirely. This is the correct semantic because: 1) The child's ioctx_table is already reset to NULL by mm_init_aio() during fork(), so the child has no AIO context and no way to perform any AIO operations on this mapping. 2) The AIO ring VMA is only meaningful in conjunction with its associated kioctx, which is never inherited across fork(). So child process with no AIO context has no legitimate reason to access the ring buffer. Delivering SIGSEGV on such an erroneous access is preferable to a kernel crash. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index c3614193d749..8b27c02db8a6 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -392,11 +392,11 @@ static const struct vm_operations_struct aio_ring_vm_ops = { #endif }; static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma) { - vm_flags_set(vma, VM_DONTEXPAND); + vm_flags_set(vma, VM_DONTEXPAND | VM_DONTCOPY); vma->vm_ops = &aio_ring_vm_ops; return 0; } static const struct file_operations aio_ring_fops = { -- 2.39.2

2 1

[PATCH OLK-5.10] fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error
by Zizhi Wo 14 Apr '26

14 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8927 -------------------------------- [BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 [ 51.115408] handle_mm_fault+0x24c/0x570 [ 51.115958] do_user_addr_fault+0x226/0xa50 ... Crash analysis showed the file involved was an AIO ring file. [CAUSE] PARENT process CHILD process t=0 io_setup(1, &ctx) [access ctx addr] fork() io_destroy vm_munmap // not affect child vma percpu_ref_put ... put_aio_ring_file t=1 [access ctx addr] // pagefault ... __do_fault filemap_fault max_idx = DIV_ROUND_UP t=2 truncate_setsize truncate_pagecache t=3 filemap_get_folio // no folio __filemap_get_folio(FGP_CREAT, ...) filemap_read_folio(xxx->read_folio) At t=0, the parent process calls io_setup and then fork. The child process gets its own VMA but without any PTEs. The parent then calls io_destroy. Before i_size is truncated to 0, at t=1 the child process accesses this AIO ctx address and triggers a pagefault. After the max_idx check passes, at t=2 the parent calls truncate_setsize and truncate_pagecache. At t=3 the child fails to obtain the folio, falls into the "page_not_uptodate" path, and hits this problem because AIO does not implement "read_folio". [Fix] Fix this by marking the AIO ring buffer VMA with VM_DONTCOPY so that fork()'s dup_mmap() skips it entirely. This is the correct semantic because: 1) The child's ioctx_table is already reset to NULL by mm_init_aio() during fork(), so the child has no AIO context and no way to perform any AIO operations on this mapping. 2) The AIO ring VMA is only meaningful in conjunction with its associated kioctx, which is never inherited across fork(). So child process with no AIO context has no legitimate reason to access the ring buffer. Delivering SIGSEGV on such an erroneous access is preferable to a kernel crash. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index 78aaeaf35436..4ab74699cd3d 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -366,11 +366,11 @@ static const struct vm_operations_struct aio_ring_vm_ops = { #endif }; static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma) { - vma->vm_flags |= VM_DONTEXPAND; + vma->vm_flags |= VM_DONTEXPAND | VM_DONTCOPY; vma->vm_ops = &aio_ring_vm_ops; return 0; } static const struct file_operations aio_ring_fops = { -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] *** Fix CVE-2026-23271 ***
by Luo Gengkun 14 Apr '26

14 Apr '26

Luo Gengkun (1): perf: Fix Wdeclaration-after-statement Peter Zijlstra (1): perf: Fix __perf_event_overflow() vs perf_remove_from_context() race kernel/events/core.c | 57 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) -- 2.34.1

2 3