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.

block: skip syncblockdev() on surprise removal in bdevmarkdead()

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

powerpc/hv-gpci: fix preempt count leak in sysfs show paths

Four sysfs show() callbacks in hv-gpci take getcpuvar(hvgpcireqb) (which calls preemptdisable()) but only call the matching putcpuvar() on the error path under the 'out:' label. Every successful read leaks one preemptdisable():

processorbustopologyshow() processorconfigshow() affinitydomainviavirtualprocessorshow() affinitydomainviadomainshow()

(affinitydomainviapartitionshow() was already correct.)

On a CONFIGPREEMPT=y kernel, repeated reads raise preemptcount and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandlerdisabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in callusermodehelperexec -> waitforcompletionstate -> schedule:

BUG: scheduling while atomic: <task>/<pid>/0x00000004 ... schedulebug+0x6c/0x90 schedule+0x58c/0x13a0 schedule+0x48/0x1a0 scheduletimeout+0x104/0x170 waitforcompletionstate+0x16c/0x330 callusermodehelperexec+0x254/0x2d0 vfscoredump+0x1050/0x2590 getsignal+0xb9c/0xc80 donotifyresume+0xf8/0x470

Add an outsuccess label that calls putcpuvar() before returning the byte count, mirroring affinitydomainviapartitionshow().

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

drivers/base/memory: set mem->altmap after successful device registration

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.

drm/amdgpu: csa unmap use uninterruptible lock

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:

iommufd: Fix protection fault in iommufdtestsyzconviova

Syzkaller reported the following bug:

general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl dosysioctl sesysioctl x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140

This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context.

Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspinpages() functions do.

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:

RDMA/bnxtre: Avoid CPU lockups due fifo occupancy check loop

Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high.

Add a loop count for FPGA and exit the waitforfifooccupancybelowth if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxtrepacingtimerexp and further scheduling the work for pacing based on the fifo occupancy.

gpiolib: Fix crash on error in gpiochipgetngpios()

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

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:

netconsole: avoid OOB reads, msg is not nul-terminated

msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printksharedpbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see:

printk: console [netconext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netconext0/594

CPU: 65 UID: 0 PID: 594 Comm: pr/netconext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasanreport+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsolewrite+0x3fe/0xa10 nbconemitnextrecord+0x46e/0x860 nbconkthreadfunc+0x623/0x750

Allocated by task 1: nbconalloc+0x1ea/0x450 registerconsole+0x26b/0xe10 initnetconsole+0xbb0/0xda0

The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)

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.

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

ksmbd: fix out-of-bounds write in smb2getea() EA alignment

smb2getea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buffreelen is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space.

When the EA value exactly fills the remaining buffer (buffreelen == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buffreelen boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERYINFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory.

Add a bounds check before the alignment memset to ensure buffreelen can accommodate the padding bytes.

This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in getfileallinfo() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERYINFO for compound requests"), both of which added bounds checks before unconditional writes in QUERYINFO response handlers.

bpf: Fix undefined behavior in interpreter sdiv/smod for INTMIN

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

ksmbd: replace hardcoded hdr2len with offsetof() in smb2calcmaxoutbuflen()

After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2calcmaxoutbuflen() expects the second argument (hdr2len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.

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:

ksmbd: fix use-after-free in ksmbdtreeconnectput under concurrency

Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes put()/write on it.

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.