OESA-2025-2883

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunximusbdriver// get the usb phy @glue->xceivsunximusbprobe() -> devmusbgetphy().2) register and unregister platform driver @musbdrivermusbprobe() -> sunximusbinit()use the phy here//the phy is released heremusbremove() -> sunximusbexit() -> devmusbputphy()3) register @musbdriver againmusbprobe() -> sunximusbinit()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devmusbputphy()from sunximusbexit().(CVE-2024-50269)

In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table 0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cachepreresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cachectr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)

In the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iiogtsbuildavailscaletable()If pertimescales[i] or pertimegains[i] kcalloc fails in the for loopof iiogtsbuildavailscaletable(), the errfreeout will fail to callkfree() each time when i is reduced to 0, so all the pertimescales[0]and pertimegains[0] will not be freed, which will cause memory leaks.Fix it by checking if i >= 0.(CVE-2024-53076)

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

wifi: ath10k: avoid NULL pointer error during sdio remove

When running 'rmmod ath10k', ath10ksdioremove() will free sdio workqueue by destroyworkqueue(). But if CONFIGINITONFREEDEFAULTON is set to yes, kernel panic will happen: Call trace: destroyworkqueue+0x1c/0x258 ath10ksdioremove+0x84/0x94 sdiobusremove+0x50/0x16c devicereleasedriverinternal+0x188/0x25c devicedriverdetach+0x20/0x2c

This is because during 'rmmod ath10k', ath10ksdioremove() will call ath10kcoredestroy() before destroyworkqueue(). wiphydevrelease() will finally be called in ath10kcoredestroy(). This function will free struct cfg80211registereddevice *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIGINITONFREEDEFAULTON.

After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.

Call trace: ath10ksdioremove ->ath10kcoreunregister …… ->ath10kcorestop ->ath10khifstop ->ath10ksdioirqdisable ->ath10khifpowerdown ->deltimersync(&arsdio->sleeptimer) ->ath10kcoredestroy ->ath10kmacdestroy ->ieee80211freehw ->wiphyfree …… ->wiphydevrelease ->destroyworkqueue

Need to call destroyworkqueue() before ath10kcoredestroy(), free the work queue buffer first and then free pointer of work queue by ath10kcoredestroy(). This order matches the error path order in ath10ksdio_probe().

No work will be queued on sdio workqueue between it is destroyed and ath10kcoredestroy() is called. Based on the callstack above, the reason is: Only ath10ksdiosleeptimerhandler(), ath10ksdiohiftxsg() and ath10ksdioirqdisable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10kcoredestroy() in ath10khifpowerdown(). ath10ksdioirqdisable() only be called in ath10khifstop(). ath10kcoreunregister() will call ath10khifpowerdown() to stop hif bus, so ath10ksdiohiftx_sg() won't be called anymore.

Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)

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

wifi: iwlwifi: limit printed string from FW file

There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.

Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)

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

ppp: Fix KMSAN uninit-value warning with bpf

Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.

The following code can generate a PPP filter BPF program: ''' struct bpfprogram fp; pcapt *handle; handle = pcapopendead(DLTPPPPPPD, 65535); pcapcompile(handle, &fp, "ip and outbound", 0, 0); bpfdump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.

As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.

The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.

For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.

[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)

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

media: venus: hfi: add check to handle incorrect queue size

qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, emptyspace will be bigger than the space actually available. Since newwridx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->qsize

if (wridx >= rdidx) emptyspace = qsize - (wridx - rdidx) .... if (newwridx < qsize) { memcpy(wrptr, packet, dwords << 2) --> OOB write

Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)

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

media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization

On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)

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

net: tls: explicitly disallow disconnect

syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.

The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:

WARNING: CPU: 0 PID: 5834 at net/tls/tlsstrp.c:486 tlsstrpmsgload+0x72e/0xa80 net/tls/tlsstrp.c:486 RIP: 0010:tlsstrpmsgload+0x72e/0xa80 net/tls/tlsstrp.c:486 Call Trace: <TASK> tlsrxrecwait+0x280/0xa60 net/tls/tlssw.c:1363 tlsswrecvmsg+0x85c/0x1c30 net/tls/tlssw.c:2043 inet6recvmsg+0x2c9/0x730 net/ipv6/afinet6.c:678 sockrecvmsgnosec net/socket.c:1023 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1045 _sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)

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

ksmbd: fix the warning from _kernelwrite_iter

[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/readwrite.c:599 _kernelwriteiter+0x21b/0x280

This patch doesn't allow writing to directory.(CVE-2025-37775)

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

ksmbd: fix use-after-free in smbbreakalllevIIoplock()

There is a room in smbbreakalllevIIoplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)

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

pwm: mediatek: Prevent divide-by-zero in pwmmediatekconfig()

With CONFIGCOMPILETEST && !CONFIGHAVECLK, pwmmediatekconfig() has a divide-by-zero in the following line:

do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));

due to the fact that the !CONFIGHAVECLK version of clkgetrate() returns zero.

This is presumably just a theoretical problem: COMPILETEST overrides the dependency on RALINK which would select COMMONCLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.

Fixes the following warning:

drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section

ukleinek: s/CONFIGCLK/CONFIGHAVE_CLK/

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

iommu/amd: Fix potential buffer overflow in parseivrsacpihid

There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIIDLEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIIDLEN + 1 but uid string will overflow uid buffer which size is 256.

The same applies to the hid string with length 13 and uid string with length 250.

Check the length of hid and uid strings separately to prevent buffer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)

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

x86/sev: Evict cache lines during SNP memory validation

An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.

CPUID bit Fn8000001FEBX[31] defines the COHERENCYSFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.

Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCYSFWNO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)

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

i40e: remove read access to debugfs files

The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").

Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.

On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.

We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdevops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copyto_user to read beyond the length of the buffer allocated by kzalloc.

A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.

Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.

In order to properly remove the i40edbgnetdevopsbuf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40edbgcommandwrite, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdevops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)

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

ksmbd: smbdirect: verify remainingdatalength respects maxfragmentedrecv_size

This is inspired by the check for dataoffset + datalength.(CVE-2025-39942)

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

mm/ksm: fix flag-dropping behavior in ksm_madvise

syzkaller discovered the following crash: (kernel BUG)

[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfdrelease_all+0x3a8/0x460

<snip other registers, drop unreliable trace>

[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfdrelease+0xef/0x1b0 [ 44.620976] _fput+0x3f9/0xb60 [ 44.621240] fputclosesync+0x110/0x210 [ 44.622222] _x64sysclose+0x8f/0x120 [ 44.622530] dosyscall64+0x5b/0x2f0 [ 44.622840] entrySYSCALL64after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227

Kernel panics because it detects UFFD inconsistency during userfaultfdreleaseall(). Specifically, a VMA which has a valid pointer to vma->vmuserfaultfdctx, but no UFFD flags in vma->vm_flags.

The inconsistency is caused in ksmmadvise(): when user calls madvise() with MADVUNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.

Assuming x8664 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VMMERGEABLE assignment.

VMMERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vmflags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.

Fix it by changing VM_MERGEABLE constant to unsigned long, using the BIT() macro.

Note: other VM* flags are not affected: This only happens to the VMMERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.

Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM)BUGON()s"), this is no longer a kernel BUG, but a WARNING at the same place:

[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067

but the root-cause (flag-drop) remains the same.

[(CVE-2025-40040)

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

net: use dstdevrcu() in sksetupcaps()

Use RCU to protect accesses to dst->dev from sksetupcaps() and skdstgsomaxsize().

Also use dstdevrcu() in ip6dstmtumaybeforward(), and ipdstmtumaybeforward().

ip4dsthoplimit() can use dstdevnet_rcu().(CVE-2025-40170)