An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2348 Final 1.0 1.0 2025-09-26 Initial 2025-09-26 2025-09-26 openEuler SA Tool V1.0 2025-09-26 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel's JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312) In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible name leaks when rio_add_device() fails Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev().(CVE-2022-50343) In the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389) In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.(CVE-2023-53149) In the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332) In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix soft lockup in br_multicast_query_expired() When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.(CVE-2025-39773) An update for kernel is now available for openEuler-20.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-2348 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50312 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50343 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-50389 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53149 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-53332 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39773 https://nvd.nist.gov/vuln/detail/CVE-2022-50312 https://nvd.nist.gov/vuln/detail/CVE-2022-50343 https://nvd.nist.gov/vuln/detail/CVE-2022-50389 https://nvd.nist.gov/vuln/detail/CVE-2023-53149 https://nvd.nist.gov/vuln/detail/CVE-2023-53332 https://nvd.nist.gov/vuln/detail/CVE-2025-39773 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm bpftool-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm kernel-4.19.90-2509.6.0.0345.oe2003sp4.src.rpm In the Linux kernel's JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues. 2025-09-26 CVE-2022-50312 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348 In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible name leaks when rio_add_device() fails Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev(). 2025-09-26 CVE-2022-50343 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348 In the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks. 2025-09-26 CVE-2022-50389 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348 In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock. 2025-09-26 CVE-2023-53149 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348 In the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. 2025-09-26 CVE-2023-53332 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348 In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix soft lockup in br_multicast_query_expired() When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue. 2025-09-26 CVE-2025-39773 openEuler-20.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-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348