{"schema_version":"1.7.2","id":"OESA-2025-2352","modified":"2025-09-26T13:09:47Z","published":"2025-09-26T13:09:47Z","upstream":["CVE-2025-38680","CVE-2025-38694","CVE-2025-38695","CVE-2025-39718","CVE-2025-39773","CVE-2025-39813","CVE-2025-39829"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()\n\nThe buffer length check before calling uvc_parse_format() only ensured\nthat the buffer has at least 3 bytes (buflen > 2), buf the function\naccesses buffer[3], requiring at least 4 bytes.\n\nThis can lead to an out-of-bounds read if the buffer has exactly 3 bytes.\n\nFix it by checking that the buffer has at least 4 bytes in\nuvc_parse_format().(CVE-2025-38680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()\n\nIn dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and\nmsg[0].len is zero, former checks on msg[0].buf would be passed. If accessing\nmsg[0].buf[2] without sanity check, null pointer deref would happen. We add\ncheck on msg[0].len to prevent crash. Similar issue occurs when access\nmsg[1].buf[0] and msg[1].buf[1].\n\nSimilar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")(CVE-2025-38694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure\n\nIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the\nresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may\noccur before sli4_hba.hdwqs are allocated.  This may result in a null\npointer dereference when attempting to take the abts_io_buf_list_lock for\nthe first hardware queue.  Fix by adding a null ptr check on\nphba->sli4_hba.hdwq and early return because this situation means there\nmust have been an error during port initialization.(CVE-2025-38695)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: Validate length in packet header before skb_put()\n\nWhen receiving a vsock packet in the guest, only the virtqueue buffer\nsize is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,\nvirtio_vsock_skb_rx_put() uses the length from the packet header as the\nlength argument to skb_put(), potentially resulting in SKB overflow if\nthe host has gone wonky.\n\nValidate the length as advertised by the packet header before calling\nvirtio_vsock_skb_rx_put().(CVE-2025-39718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n'time' in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n  Call Trace:\n   <IRQ>\n   __netdev_alloc_skb+0x2e/0x3a0\n   br_ip6_multicast_alloc_query+0x212/0x1b70\n   __br_multicast_send_query+0x376/0xac0\n   br_multicast_send_query+0x299/0x510\n   br_multicast_query_expired.constprop.0+0x16d/0x1b0\n   call_timer_fn+0x3b/0x2a0\n   __run_timers+0x619/0x950\n   run_timer_softirq+0x11c/0x220\n   handle_softirqs+0x18e/0x560\n   __irq_exit_rcu+0x158/0x1a0\n   sysvec_apic_timer_interrupt+0x76/0x90\n   </IRQ>\n\nThis issue can be reproduced with:\n  ip link add br0 type bridge\n  echo 1 > /sys/class/net/br0/bridge/multicast_querier\n  echo 0xffffffffffffffff >\n  \t/sys/class/net/br0/bridge/multicast_query_interval\n  ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a ("net: bridge: mcast: add and enforce query\ninterval minimum"), add check for the query interval maximum to fix this\nissue.(CVE-2025-39773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix potential warning in trace_printk_seq during ftrace_dump\n\nWhen calling ftrace_dump_one() concurrently with reading trace_pipe,\na WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race\ncondition.\n\nThe issue occurs because:\n\nCPU0 (ftrace_dump)                              CPU1 (reader)\necho z > /proc/sysrq-trigger\n\n!trace_empty(&iter)\ntrace_iterator_reset(&iter) <- len = size = 0\n                                                cat /sys/kernel/tracing/trace_pipe\ntrace_find_next_entry_inc(&iter)\n  __find_next_entry\n    ring_buffer_empty_cpu <- all empty\n  return NULL\n\ntrace_printk_seq(&iter.seq)\n  WARN_ON_ONCE(s->seq.len >= s->seq.size)\n\nIn the context between trace_empty() and trace_find_next_entry_inc()\nduring ftrace_dump, the ring buffer data was consumed by other readers.\nThis caused trace_find_next_entry_inc to return NULL, failing to populate\n`iter.seq`. At this point, due to the prior trace_iterator_reset, both\n`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,\nthe WARN_ON_ONCE condition is triggered.\n\nMove the trace_printk_seq() into the if block that checks to make sure the\nreturn value of trace_find_next_entry_inc() is non-NULL in\nftrace_dump_one(), ensuring the 'iter.seq' is properly populated before\nsubsequent operations.(CVE-2025-39813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntrace/fgraph: Fix the warning caused by missing unregister notifier\n\nThis warning was triggered during testing on v6.16:\n\nnotifier callback ftrace_suspend_notifier_call already registered\nWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0\n...\nCall Trace:\n <TASK>\n blocking_notifier_chain_register+0x34/0x60\n register_ftrace_graph+0x330/0x410\n ftrace_profile_write+0x1e9/0x340\n vfs_write+0xf8/0x420\n ? filp_flush+0x8a/0xa0\n ? filp_close+0x1f/0x30\n ? do_dup2+0xaf/0x160\n ksys_write+0x65/0xe0\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen writing to the function_profile_enabled interface, the notifier was\nnot unregistered after start_graph_tracing failed, causing a warning the\nnext time function_profile_enabled was written.\n\nFixed by adding unregister_pm_notifier in the exception path.(CVE-2025-39829)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-111.0.0.114.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","perf-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-111.0.0.114.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-111.0.0.114.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","perf-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-111.0.0.114.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2352"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38694"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38695"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39718"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39773"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39813"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39829"}],"database_specific":{"severity":"High"}}