An update for kernel is now available for openEuler-24.03-LTS Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-2351 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-24.03-LTS The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format().(CVE-2025-38680) In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb() In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")(CVE-2025-38694) In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization.(CVE-2025-38695) In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put().(CVE-2025-39718) 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) In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.(CVE-2025-39813) In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: <TASK> blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path.(CVE-2025-39829) An update for kernel is now available for openEuler-24.03-LTS. 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-2351 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38680 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38694 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-38695 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39718 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39773 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39813 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-39829 https://nvd.nist.gov/vuln/detail/CVE-2025-38680 https://nvd.nist.gov/vuln/detail/CVE-2025-38694 https://nvd.nist.gov/vuln/detail/CVE-2025-38695 https://nvd.nist.gov/vuln/detail/CVE-2025-39718 https://nvd.nist.gov/vuln/detail/CVE-2025-39773 https://nvd.nist.gov/vuln/detail/CVE-2025-39813 https://nvd.nist.gov/vuln/detail/CVE-2025-39829 openEuler-24.03-LTS bpftool-6.6.0-111.0.0.103.oe2403.aarch64.rpm bpftool-debuginfo-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-debuginfo-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-debugsource-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-devel-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-headers-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-source-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-tools-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-tools-debuginfo-6.6.0-111.0.0.103.oe2403.aarch64.rpm kernel-tools-devel-6.6.0-111.0.0.103.oe2403.aarch64.rpm perf-6.6.0-111.0.0.103.oe2403.aarch64.rpm perf-debuginfo-6.6.0-111.0.0.103.oe2403.aarch64.rpm python3-perf-6.6.0-111.0.0.103.oe2403.aarch64.rpm python3-perf-debuginfo-6.6.0-111.0.0.103.oe2403.aarch64.rpm bpftool-6.6.0-111.0.0.103.oe2403.x86_64.rpm bpftool-debuginfo-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-debuginfo-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-debugsource-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-devel-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-headers-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-source-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-tools-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-tools-debuginfo-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-tools-devel-6.6.0-111.0.0.103.oe2403.x86_64.rpm perf-6.6.0-111.0.0.103.oe2403.x86_64.rpm perf-debuginfo-6.6.0-111.0.0.103.oe2403.x86_64.rpm python3-perf-6.6.0-111.0.0.103.oe2403.x86_64.rpm python3-perf-debuginfo-6.6.0-111.0.0.103.oe2403.x86_64.rpm kernel-6.6.0-111.0.0.103.oe2403.src.rpm In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format(). 2025-09-26 CVE-2025-38680 openEuler-24.03-LTS 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-2351 In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb() In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") 2025-09-26 CVE-2025-38694 openEuler-24.03-LTS 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-2351 In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization. 2025-09-26 CVE-2025-38695 openEuler-24.03-LTS Medium 4.7 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H kernel security update 2025-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2351 In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). 2025-09-26 CVE-2025-39718 openEuler-24.03-LTS High 7.6 AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H kernel security update 2025-09-26 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2351 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-24.03-LTS 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-2351 In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations. 2025-09-26 CVE-2025-39813 openEuler-24.03-LTS 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-2351 In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: <TASK> blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path. 2025-09-26 CVE-2025-39829 openEuler-24.03-LTS 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-2351