OESA-2025-2351

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 uvcparseformat()

The buffer length check before calling uvcparseformat() 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 uvcparseformat().(CVE-2025-38680)

In the Linux kernel, the following vulnerability has been resolved:

media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090prwon_apb()

In dib7090prwon_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 az6027i2cxfer()")(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 lpfcsli4readrev() from lpfcsli4hbasetup() fails, the resultant cleanup routine lpfcsli4vportdeletefcpxriaborted() may occur before sli4hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abtsiobuflistlock for the first hardware queue. Fix by adding a null ptr check on phba->sli4hba.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 virtiovsockskbrxput(). Unfortunately, virtiovsockskbrxput() 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 virtiovsockskbrxput().(CVE-2025-39718)

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix soft lockup in brmulticastquery_expired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> _netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 _brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 _runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 _irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastquery_interval ip link set dev br0 up

The multicaststartupquery_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 traceprintkseq during ftrace_dump

When calling ftracedumpone() concurrently with reading tracepipe, a WARNONONCE() in traceprintk_seq() can be triggered due to a race condition.

The issue occurs because:

CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger

!traceempty(&iter) traceiteratorreset(&iter) <- len = size = 0 cat /sys/kernel/tracing/tracepipe tracefindnextentryinc(&iter) _findnextentry ringbufferemptycpu <- all empty return NULL

traceprintkseq(&iter.seq) WARNONONCE(s->seq.len >= s->seq.size)

In the context between traceempty() and tracefindnextentryinc() during ftracedump, the ring buffer data was consumed by other readers. This caused tracefindnextentryinc to return NULL, failing to populate iter.seq. At this point, due to the prior traceiteratorreset, both iter.seq.len and iter.seq.size were set to 0. Since they are equal, the WARNONONCE condition is triggered.

Move the traceprintkseq() into the if block that checks to make sure the return value of tracefindnextentryinc() is non-NULL in ftracedumpone(), 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 ftracesuspendnotifiercall already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifierchainregister+0x44/0xb0 ... Call Trace: <TASK> blockingnotifierchainregister+0x34/0x60 registerftracegraph+0x330/0x410 ftraceprofilewrite+0x1e9/0x340 vfswrite+0xf8/0x420 ? filpflush+0x8a/0xa0 ? filpclose+0x1f/0x30 ? dodup2+0xaf/0x160 ksyswrite+0x65/0xe0 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x77/0x7f

When writing to the functionprofileenabled interface, the notifier was not unregistered after startgraphtracing failed, causing a warning the next time functionprofileenabled was written.

Fixed by adding unregisterpmnotifier in the exception path.(CVE-2025-39829)