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:
hwmon: (nct6775) Fix access to temperature configuration registers
The number of temperature configuration registers does not always match the total number of temperature registers. This can result in access errors reported if KASAN is enabled.
BUG: KASAN: global-out-of-bounds in nct6775probe+0x5654/0x6fe9 nct6775core
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:
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:
smb: client: fix potential deadlock when releasing mids
All releasemid() callers seem to hold a reference of @mid so there is no need to call krefput(&mid->refcount, releasemid) under @server->midlock spinlock. If they don't, then an use-after-free bug would have occurred anyways.
By getting rid of such spinlock also fixes a potential deadlock as shown below
CPU 0 CPU 1 ------------------------------------------------------------------ cifsdemultiplexthread() cifsdebugdataprocshow() releasemid() spinlock(&server->midlock); spinlock(&cifstcpseslock) spinlock(&server->midlock) releasemid() smb2findsmbtcon() spinlock(&cifstcpseslock) deadlock
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:
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:
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:
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:
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:
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:
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:
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.
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:
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:
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:
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:
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.
In the Linux kernel, the following vulnerability has been resolved:
regulator: rtq2208: Fix uninitialized use of regulatorconfig
Fix rtq2208 driver uninitialized use to cause kernel error.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: clear wdev->cqmconfig pointer on free
When we free wdev->cqmconfig when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.
In the Linux kernel, the following vulnerability has been resolved:
ioviter: fix copypagefromiteratomic() if KMAPLOCALFORCEMAP
generic/077 on x8632 CONFIGDEBUGKMAPLOCALFORCEMAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly):
WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmaplocalindexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copypagefromiteratomic+0xa6/0x5ec genericperformwrite+0xf6/0x1b4 shmemfilewriteiter+0x54/0x67
Fix copypagefromiteratomic() by limiting it in that case (include/linux/skbuff.h skbfragmustloop() does similar).
But going forward, perhaps CONFIGDEBUGKMAPLOCALFORCEMAP is too surprising, has outlived its usefulness, and should just be removed?
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Vangogh: Fix kernel memory out of bounds write
KASAN reports that the GPU metrics table allocated in vangoghtablesinit() is not large enough for the memset done in smucmninitsoftgpumetrics(). Condensed report follows:
[ 33.861314] BUG: KASAN: slab-out-of-bounds in smucmninitsoftgpumetrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] <TASK> [ 33.861829] dumpstacklvl+0x66/0x90 [ 33.861838] printreport+0xce/0x620 [ 33.861853] kasanreport+0xda/0x110 [ 33.862794] kasancheckrange+0xfd/0x1a0 [ 33.862799] asanmemset+0x23/0x40 [ 33.862803] smucmninitsoftgpumetrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangoghgetgpumetricsv24+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangoghcommongetgpumetrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpudpmgetgpumetrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpugetgpumetrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] devattrshow+0x43/0xc0 [ 33.867147] sysfskfseqshow+0x1f1/0x3b0 [ 33.867155] seqreaditer+0x3f8/0x1140 [ 33.867173] vfsread+0x76c/0xc50 [ 33.867198] ksysread+0xfb/0x1d0 [ 33.867214] dosyscall64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasansavestack+0x33/0x50 [ 33.867364] kasansavetrack+0x17/0x60 [ 33.867367] kasankmalloc+0x87/0x90 [ 33.867371] vangoghinitsmctables+0x3f9/0x840 [amdgpu] [ 33.867835] smuswinit+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpudeviceinit+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpudriverloadkms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpupciprobe+0x2d6/0xcd0 [amdgpu] [ 33.869608] localpciprobe+0xda/0x180 [ 33.869614] pcideviceprobe+0x43f/0x6b0
Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block.
Root cause appears that when GPU metrics tables for v24 parts were added it was not considered to enlarge the table to fit.
The fix in this patch is rather "brute force" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write.
v2: Drop impossible v30 case. (Mario)
(cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)
In the Linux kernel, the following vulnerability has been resolved:
net: bcmasp: fix potential memory leak in bcmaspxmit()
The bcmaspxmit() returns NETDEVTXOK without freeing skb in case of mapping fails, add devkfreeskb() to fix it.