An update for kernel is now available for openEuler-22.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-1728 Final 1.0 1.0 2025-07-04 Initial 2025-07-04 2025-07-04 openEuler SA Tool V1.0 2025-07-04 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL. Code should check this ptr before dereferencing. Syzbot hit this issue via passing wrong mount param as can be seen from log below Fail log: ntfs3: Unknown parameter 'iochvrset' general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0 ... Call Trace: <TASK> put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463 ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363 put_fs_context+0x119/0x7a0 fs/fs_context.c:469 do_new_mount+0x2b4/0xad0 fs/namespace.c:3044 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline](CVE-2022-50057) In the Linux kernel, the following vulnerability has been resolved: bpf: fix potential 32-bit overflow when accessing ARRAY map element If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places. Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places.(CVE-2022-50167) Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel. This vulnerability originates from arm64 not setting UXN in swapper page table, which may cause access to be denied.(CVE-2022-50230) In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)(CVE-2024-26798) In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest. Fix this by rejecting packets with an unexpected header length.(CVE-2025-21927) In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026) In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30(CVE-2025-38031) In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078) An update for kernel is now available for openEuler-22.03-LTS-SP3/openEuler-22.03-LTS-SP4/openEuler-22.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50057 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50167 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50230 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-26798 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-21927 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-22026 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38031 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38078 https://nvd.nist.gov/vuln/detail/CVE-2022-50057 https://nvd.nist.gov/vuln/detail/CVE-2022-50167 https://nvd.nist.gov/vuln/detail/CVE-2022-50230 https://nvd.nist.gov/vuln/detail/CVE-2024-26798 https://nvd.nist.gov/vuln/detail/CVE-2025-21927 https://nvd.nist.gov/vuln/detail/CVE-2025-22026 https://nvd.nist.gov/vuln/detail/CVE-2025-38031 https://nvd.nist.gov/vuln/detail/CVE-2025-38078 openEuler-22.03-LTS-SP4 kernel-5.10.0-270.0.0.173.oe2203sp4.src.rpm bpftool-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm bpftool-debuginfo-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-debuginfo-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-debugsource-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-devel-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-headers-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-source-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-tools-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-tools-debuginfo-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm kernel-tools-devel-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm perf-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm perf-debuginfo-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm python3-perf-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm python3-perf-debuginfo-5.10.0-270.0.0.173.oe2203sp4.aarch64.rpm bpftool-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm bpftool-debuginfo-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-debuginfo-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-debugsource-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-devel-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-headers-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-source-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-tools-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-tools-debuginfo-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm kernel-tools-devel-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm perf-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm perf-debuginfo-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm python3-perf-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm python3-perf-debuginfo-5.10.0-270.0.0.173.oe2203sp4.x86_64.rpm In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL. Code should check this ptr before dereferencing. Syzbot hit this issue via passing wrong mount param as can be seen from log below Fail log: ntfs3: Unknown parameter 'iochvrset' general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0 ... Call Trace: <TASK> put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463 ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363 put_fs_context+0x119/0x7a0 fs/fs_context.c:469 do_new_mount+0x2b4/0xad0 fs/namespace.c:3044 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] 2025-07-04 CVE-2022-50057 openEuler-22.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: bpf: fix potential 32-bit overflow when accessing ARRAY map element If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places. Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places. 2025-07-04 CVE-2022-50167 openEuler-22.03-LTS-SP4 High 7.0 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel. This vulnerability originates from arm64 not setting UXN in swapper page table, which may cause access to be denied. 2025-07-04 CVE-2022-50230 openEuler-22.03-LTS-SP4 Medium 5.7 AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.) 2025-07-04 CVE-2024-26798 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest. Fix this by rejecting packets with an unexpected header length. 2025-07-04 CVE-2025-21927 openEuler-22.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM. 2025-07-04 CVE-2025-22026 openEuler-22.03-LTS-SP4 High 7.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 2025-07-04 CVE-2025-38031 openEuler-22.03-LTS-SP4 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728 In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. 2025-07-04 CVE-2025-38078 openEuler-22.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-07-04 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1728