GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-2353 (CVE-2025-38680)

Vulnerability from osv_openeuler – Published: 2025-09-26 11:09 – Updated: 2026-08-06 11:09 – Source website
VLAI
Summary
kernel security update
Details

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)

Severity
7.6 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-debuginfo-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-debugsource-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-devel-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-extra-modules-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-headers-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-source-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-tools-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "kernel-tools-devel-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "perf-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "perf-debuginfo-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "python3-perf-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-111.0.0.117.oe2403sp2.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-111.0.0.117.oe2403sp2.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-debuginfo-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-debugsource-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-devel-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-extra-modules-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-headers-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-source-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-tools-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "kernel-tools-devel-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "perf-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "perf-debuginfo-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "python3-perf-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-111.0.0.117.oe2403sp2.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP2",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-111.0.0.117.oe2403sp2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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 \u0026gt; 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 (\u0026quot;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\u0026quot;)(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-\u0026gt;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\u0026apos;time\u0026apos; 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   \u0026lt;IRQ\u0026gt;\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   \u0026lt;/IRQ\u0026gt;\n\nThis issue can be reproduced with:\n  ip link add br0 type bridge\n  echo 1 \u0026gt; /sys/class/net/br0/bridge/multicast_querier\n  echo 0xffffffffffffffff \u0026gt;\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 (\u0026quot;net: bridge: mcast: add and enforce query\ninterval minimum\u0026quot;), 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 \u0026gt; /proc/sysrq-trigger\n\n!trace_empty(\u0026amp;iter)\ntrace_iterator_reset(\u0026amp;iter) \u0026lt;- len = size = 0\n                                                cat /sys/kernel/tracing/trace_pipe\ntrace_find_next_entry_inc(\u0026amp;iter)\n  __find_next_entry\n    ring_buffer_empty_cpu \u0026lt;- all empty\n  return NULL\n\ntrace_printk_seq(\u0026amp;iter.seq)\n  WARN_ON_ONCE(s-\u0026gt;seq.len \u0026gt;= s-\u0026gt;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 \u0026apos;iter.seq\u0026apos; 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 \u0026lt;TASK\u0026gt;\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)",
  "id": "OESA-2025-2353",
  "modified": "2026-08-06T11:09:26Z",
  "published": "2025-09-26T11:09:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2353"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-38680",
    "CVE-2025-38694",
    "CVE-2025-38695",
    "CVE-2025-39718",
    "CVE-2025-39773",
    "CVE-2025-39813",
    "CVE-2025-39829"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.