In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Don't setup bogus ioviter for silencing
At transition to the ioviter for PCM data transfer, we blindly applied the ioviter setup also for silencing (i.e. data = NULL), and it leads to a calculation of bogus ioviter. Fortunately this didn't cause troubles on most of architectures but it goes wrong on RISC-V now, causing a NULL dereference.
Handle the NULL data case to treat the silencing in interleavedcopy() for addressing the bug above. noninterleavedcopy() has already the NULL data handling, so it doesn't need changes.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fix use-after-free in gfs2qddealloc
gfs2qddealloc(), called as an RCU callback from gfs2qddispose(), accesses the superblock object sdp through qd->qdsbd after freeing qd. It does so to decrement sdquotacount and wake up sdkillwait.
However, by the time the RCU callback runs, gfs2putsuper() may have already freed sdp via freesbd(). This can happen when gfs2quotacleanup() is called during unmount: it disposes of quota objects via callrcu() and then waits on sdkillwait with a 60-second timeout. If the timeout expires, or if gfs2glhashclear() triggers additional qdput() calls that schedule more RCU callbacks after the wait completes, gfs2putsuper() will proceed to free the superblock while RCU callbacks referencing it are still pending.
Add an rcubarrier() before freesbd() in gfs2putsuper() to ensure all pending RCU callbacks (including gfs2qddealloc) have completed before the superblock is freed.
In the Linux kernel, the following vulnerability has been resolved:
quota: Fix race of dquotscanactive() with quota deactivation
dquotscanactive() can race with quota deactivation in quotareleaseworkfn() like:
CPU0 (quotareleaseworkfn) CPU1 (dquotscanactive) ============================== ============================== spinlock(&dqlistlock); listreplaceinit( &releasingdquots, &rlshead); / dquot X on rlshead, dqcount == 0, DQACTIVEB still set / spinunlock(&dqlistlock); synchronizesrcu(&dquotsrcu); spinlock(&dqlistlock); listforeachentry(dquot, &inuselist, dqinuse) { / finds dquot X / dquotactive(X) -> true atomicinc(&X->dqcount); } spinunlock(&dqlistlock); spinlock(&dqlistlock); dquot = listfirstentry(&rlshead); WARNONONCE(atomicread(&dquot->dqcount));
The problem is not only a cosmetic one as under memory pressure the caller of dquotscanactive() can end up working on freed dquot.
Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix oops due to out of scope access
Below oops triggers when kill QEMU process:
Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> dorawspinlock+0xaa/0xc0 rawspinlockirqsave+0x21/0x40 domainremovedevpasid+0x52/0x160 intelnestedsetdevpasid+0x1b9/0x1e0 iommusetgrouppasid+0x56/0x120 pcidevresetiommudone+0xe3/0x180 pcieflr+0x65/0x160 pciresetfunctionlocked+0x5b/0x120 vfiopcicoreclosedevice+0x63/0xe0 [vfiopcicore] vfiodfclose+0x4f/0xa0 vfiodfunbindiommufd+0x2d/0x60 vfiodevicefopsrelease+0x3e/0x40 fput+0xe5/0x2c0 taskworkrun+0x58/0xa0 doexit+0x2c8/0x600 dogroupexit+0x2f/0xa0 getsignal+0x863/0x8c0 archdosignalorrestart+0x24/0x100 exittousermodeloop+0x87/0x380 dosyscall64+0x2ff/0x11e0 entrySYSCALL64afterhwframe+0x76/0x7e
The global static blocked domain is a dummy domain without corresponding dmardomain structure, accessing beyond iommudomain structure triggers oops easily. Fix it by return early in domainremovedevpasid() like identity domain.
In the Linux kernel, the following vulnerability has been resolved:
of: unittest: fix use-after-free in testdrvprobe()
The function testdrvprobe() retrieves the devicenode from the PCI device, applies an overlay, and then immediately calls ofnodeput(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to ofplatformdefaultpopulate(), leading to a use-after-free.
The reference to pdev->dev.ofnode is owned by the device model and should not be released by the driver. Remove the erroneous ofnodeput() to prevent premature freeing.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix tcx/netkit detach permissions when prog fd isn't given
This commit fixes a security issue where BPFPROGDETACH on tcx or netkit devices could be executed by any user when no program fd was provided, bypassing permission checks. The fix adds a capability check for CAPNETADMIN or CAPSYSADMIN in this case.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix slab-use-after-free in qdput
Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2qdshrinkscan) tried to access already-freed objects on the LRU list.
Fix this by removing qd objects from the LRU list before freeing them in qdput().
Initial fix from Deepanshu Kartikey <kartikey406@gmail.com>.
In the Linux kernel, the following vulnerability has been resolved:
efi: Fix reservation of unaccepted memory table
The reserveunaccepted() function incorrectly calculates the size of the memblock reservation for the unaccepted memory table. It aligns the size of the table, but fails to account for cases where the table's starting physical address (efi.unaccepted) is not page-aligned.
If the table starts at an offset within a page and its end crosses into a subsequent page that the aligned size does not cover, the end of the table will not be reserved. This can lead to the table being overwritten or inaccessible, causing a kernel panic in acceptmemory().
This issue was observed when starting Intel TDX VMs with specific memory sizes (e.g., > 64GB).
Fix this by calculating the end address first (including the unaligned start) and then aligning it up, ensuring the entire range is covered by the reservation.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hciconn: fix potential UAF in setcigparamssync
hciconn lookup and field access must be covered by hdev lock in setcigparamssync, otherwise it's possible it is freed concurrently.
Take hdev lock to prevent hciconn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration.
bpf: Fix undefined behavior in interpreter sdiv/smod for INTMIN
In the Linux kernel, the following vulnerability has been resolved:
net: bcmasp: fix double free of WoL irq
We do not need to free wolirq since it was instantiated with devmrequestirq(). So devres will free for us.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial OOB in getfileallinfo() for compound requests
When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix OOB write in QUERYINFO for compound requests
When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.
The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.
This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.
In the Linux kernel, the following vulnerability has been resolved:
smb/server: call ksmbdsessionrpcclose() on error path in createsmb2pipe()
When ksmbdiovpinrsp() fails, we should call ksmbdsessionrpcclose().
In the Linux kernel, the following vulnerability has been resolved:
libceph: reset sparse-read state in osdfault()
When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.
If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:
libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read
Therefore, reset the sparse-read state in osdfault(), ensuring retries start from a clean state.
clk: samsung: exynos-clkout: Assign .num before accessing .hws
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing
The hppopulateelementsfrompackage() functions in the hp-bioscfg driver contain out-of-bounds array access vulnerabilities.
These functions parse ACPI packages into internal data structures using a for loop with index variable 'elem' that iterates through enumobj/integerobj/orderobj/passwordobj/stringobj arrays.
When processing multi-element fields like PREREQUISITES and ENUMPOSSIBLEVALUES, these functions read multiple consecutive array elements using expressions like 'enumobj[elem + reqs]' and 'enumobj[elem + posvalues]' within nested loops.
The bug is that the bounds check only validated elem, but did not consider the additional offset when accessing elem + reqs or elem + posvalues.
The fix changes the bounds check to validate the actual accessed index.
In the Linux kernel, the following vulnerability has been resolved:
shmem: fix recovery on rename failures
mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().
Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().
Not hard to fix, fortunately - mtreestore() can't fail if the index we are trying to store into is already present in the tree as a singleton.
For simpleoffsetrenameexchange() that's enough - we just need to be careful about the order of operations.
For simpleoffsetrename() solution is to preinsert the target into the tree for newdir; the rest can be done without any potentially failing operations.
That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().
In the Linux kernel, the following vulnerability has been resolved:
media: ivsc: Fix crash at shutdown due to missing meicldevdisable() calls
Both the ACE and CSI driver are missing a meicldevdisable() call in their remove() function.
This causes the meicl client to stay part of the meidevice->filelist list even though its memory is freed by meiclbusdevrelease() calling kfree(cldev->cl).
This leads to a use-after-free when meivscremove() runs meistop() which first removes all mei bus devices calling meiaceremove() and meicsiremove() followed by meiclbusdevrelease() and then calls meiclalldisconnect() which walks over meidevice->filelist dereferecing the just freed cldev->cl.
And meivscremove() it self is run at shutdown because of the platformdeviceunregister(tp->pdev) in vsctpshutdown()
When building a kernel with KASAN this leads to the following KASAN report:
[ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in meiclsetdisconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNEDMODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] meiclsetdisconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] meiclalldisconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] meireset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] meistop (drivers/misc/mei/init.c:348) mei [ 106.635062] meivscremove (drivers/misc/mei/meidev.h:784 drivers/misc/mei/platform-vsc.c:393) meivsc [ 106.635066] platformremove (drivers/base/platform.c:1424)
Add the missing meicldevdisable() calls so that the meicl gets removed from meidevice->filelist before it is freed to fix this.
In the Linux kernel, the following vulnerability has been resolved:
ice: add NULL check in eswitch lag check
The function icelagisswitchdevrunning() is being called from outside of the LAG event handler code. This results in the lag->uppernetdev being NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a check before it is dereferenced.
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumrouter: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.
[1] BUG: KASAN: slab-use-after-free in mlxswspneighentryupdate+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dumpstacklvl+0x6f/0xa0 printaddressdescription.constprop.0+0x6f/0x350 printreport+0x108/0x205 kasanreport+0xdf/0x110 mlxswspneighentryupdate+0x1ea/0x200 mlxswsprouterrifgonesync+0x2a8/0x440 mlxswsprifdestroy+0x1e9/0x750 mlxswspnetdeviceipipolevent+0x3c9/0xdc0 mlxswsprouternetdeviceevent+0x3ac/0x15e0 notifiercallchain+0xca/0x150 callnetdevicenotifiersinfo+0x7f/0x100 unregisternetdevicemanynotify+0xc8c/0x1d90 rtnldellink+0x34e/0xa50 rtnetlinkrcvmsg+0x6fb/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 syssendmsg+0xfc/0x180 syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Set nchannels after allocating struct cfg80211scanrequest
Make sure that nchannels is set after allocating the struct cfg80211registereddevice::intscanreq member. Seen with syzkaller:
UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211channel [] countedby(nchannels)' (aka 'struct ieee80211channel []')
This was missed in the initial conversions because I failed to locate the allocation likely due to the "sizeof(void )" not matching the "channels" array type.
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: Fix packet corruption in vmxnet3xdpxmitframe
Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.
If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.
vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:
page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATODEVICE);
The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void )xdpf, that is, xdp->data - xdp->datahardstart.
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ds90ub9x3: Fix extra fwnodehandleput()
The ub913 and ub953 drivers call fwnodehandleput(priv->sd.fwnode) as part of their remove process, and if the driver is removed multiple times, eventually leads to put "overflow", possibly causing memory corruption or crash.
The fwnodehandleput() is a leftover from commit 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching"), which changed the code related to the sd.fwnode, but missed removing these fwnodehandleput() calls.
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SOPEEK or SORCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcpv4rcv(->) // tcprcvestablished(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcpinput.c/tcpdataqueue()/5257 ==== [5201<->39222]: tcpdataqueue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKBDROPREASONPROTOMEM [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcpdataqueue(<-) [5201<->39222]: tcptransmitskb(->) [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpselectwindow(->) [5201<->39222]: (inetcsk(sk)->icskack.pending & ICSKACKNOMEM) ? --> TRUE [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] returning 0 [5201<->39222]: tcpselectwindow(<-) [5201<->39222]: ADVERTISING WIN 0, ACKSEQ: 265600160 [5201<->39222]: [tcptransmitskb(<-) [5201<->39222]: tcprcvestablished(<-) [5201<->39222]: tcpv4rcv(<-)
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcvwnd and tp->rcvwup accordingly, which means // we unconditionally shrink the window.
[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 0, winnow = 131184, 2 winnow = 262368] [5201<->39222]: [newwin >= (2 winnow) ? --> timetoack = 0] [5201<->39222]: NOT calling tcpsendack() [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [5201<->39222]: tcpcleanuprbuf(<-) [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcprecvmsglocked(<-)
// After each read, the algorithm for calculating the new receive // window in tcpcleanuprbuf() finds it is too small to advertise // or to update tp->rcvwnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
[5201<->39222]: tcprecvmsglocked(->) [5201<->39222]: tcpcleanuprbuf(->) tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160 [5201<->39222]: [newwin = 262144, winnow = 131184, 2 winn ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
OPP: add index check to assert to avoid buffer overflow in readfreq()
Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: devpmoppfindfreqexactindexed() or devpmoppfindfreqceil/floorindexed().
Add a secondary parameter to the assert function, unused for assertsingleclk() then add assertclkindex() which will check for the clock index when called from the indexed() find functions.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix a missing return value check bug
In the smb2sendinterimresp(), if ksmbdallocworkstruct() fails to allocate a node, it returns a NULL pointer to the inwork pointer. This can lead to an illegal memory write of inwork->responsebuf when allocateinterimrspbuf() attempts to perform a kzalloc() on it.
To address this issue, incorporating a check for the return value of ksmbdallocworkstruct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Skip restore TC rules for vport rep without loaded flag
During driver unload, unregisternetdev is called after unloading vport rep. So, the mlx5ereppriv is already freed while trying to get rpriv->netdev, or walk rpriv->tcht, which results in use-after-free. So add the checking to make sure access the data of vport rep which is still loaded.
Bluetooth: btmtk: avoid UAF in btmtkprocesscoredump
In the Linux kernel, the following vulnerability has been resolved:
nommu: pass NULL argument to vmaiterprealloc()
When deleting a vma entry from a maple tree, it has to pass NULL to vmaiterprealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acctcollect() reading the size of vma entries after domunmap().
This commit fixes this issue by passing a right argument to the preallocation call.