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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

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

configfs: fix possible memory leak in configfscreatedir()

kmemleak reported memory leaks in configfscreatedir():

unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmemcachealloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) newfragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfsregistersubsystem (fs/configfs/dir.c:1857) basicwrite (drivers/hwtracing/stm/pbasic.c:14) stmpbasic dooneinitcall (init/main.c:1296) doinitmodule (kernel/module/main.c:2455) ...

unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmemcachealloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfsnewdirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfsmakedirent (fs/configfs/dir.c:248) configfscreatedir (fs/configfs/dir.c:296) configfsattachgroup.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfsregistersubsystem (fs/configfs/dir.c:1881) basicwrite (drivers/hwtracing/stm/pbasic.c:14) stmpbasic dooneinitcall (init/main.c:1296) doinitmodule (kernel/module/main.c:2455) ...

This is because the refcount is not correct in configfsmakedirent(). For normal stage, the refcount is changing as:

configfsregistersubsystem() configfscreatedir() configfsmakedirent() configfsnewdirent() # set scount = 1 dentry->dfsdata = configfsget(sd); # scount = 2 ... configfsunregistersubsystem() configfsremovedir() removedir() configfsremovedirent() # scount = 1 dput() ... dentryunlinkinode() configfsdiput() # scount = 0, release

However, if we failed in configfscreate():

configfsregistersubsystem() configfscreatedir() configfsmakedirent() # scount = 2 ... configfscreate() # fail ->outremove: configfsremovedirent(dentry) configfsput(sd) # scount = 1 return PTRERR(inode);

There is no inode in the error path, so the configfsdiput() is lost and makes sd and fragment memory leaked.

To fix this, when we failed in configfscreate(), manually call configfsput(sd) to keep the refcount correct.

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation

Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.

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

drm/amdgpu: Fix PCI device refcount leak in amdgpuatrmgetbios()

As comment of pcigetclass() says, it returns a pcidevice with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.

If we break the loop in amdgpuatrmgetbios() with 'pdev' not NULL, we need to call pcidevput() to decrease the refcount. Add the missing pcidevput() to avoid refcount leak.

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

wifi: ath9k: avoid uninit memory read in ath9khtcrxmsg()

syzbot is reporting uninit value at ath9khtcrxmsg() [1], for ioctl(USBRAWIOCTLEPWRITE) can call ath9khifusbrxstream() with pktlen = 0 but ath9khifusbrxstream() uses devallocskb(pktlen + 32, GFPATOMIC) based on an assumption that pktlen is valid. As a result, ath9khifusbrxstream() allocates skb with uninitialized memory and ath9khtcrxmsg() is reading from uninitialized memory.

Since bytes accessed by ath9khtcrxmsg() is not known until ath9khtcrxmsg() is called, it would be difficult to check minimal valid pktlen at "if (pktlen > 2 MAXRXBUFSIZE) {" line in ath9khifusbrxstream().

We have two choices. One is to workaround by adding GFPZERO so that ath9khtcrxmsg() sees 0 if pktlen is invalid. The other is to let ath9khtcrxmsg() validate pktlen before accessing. This patch chose the latter.

Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol.

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

drm/amdkfd: Fix memory leak in kfdmemdmamapuserptr()

If the number of pages from the userptr BO differs from the SG BO then the allocated memory for the SG table doesn't get freed before returning -EINVAL, which may lead to a memory leak in some error paths. Fix this by checking the number of pages before allocating memory for the SG table.

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

mISDN: annotate data-race around dev->work

dev->work can re read locklessly in mISDNread() and mISDNpoll(). Add READONCE()/WRITEONCE() annotations.

BUG: KCSAN: data-race in mISDNioctl / mISDNread

write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdnaddtimer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDNioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl+0xce/0x140 fs/ioctl.c:583 x64sysioctl+0x43/0x50 fs/ioctl.c:583 x64syscall+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDNread+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 doloopreadvwritev fs/readwrite.c:847 [inline] vfsreadv+0x3fb/0x690 fs/readwrite.c:1020 doreadv+0xe7/0x210 fs/readwrite.c:1080 dosysreadv fs/readwrite.c:1165 [inline] sesysreadv fs/readwrite.c:1162 [inline] x64sysreadv+0x45/0x50 fs/readwrite.c:1162 x64syscall+0x2831/0x3000 arch/x86/include/generated/asm/syscalls64.h:20 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd8/0x2c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

value changed: 0x00000000 -> 0x00000001

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

net: liquidio: Initialize netdev pointer before queue setup

In setupnicdevices(), the netdev is allocated using allocetherdevmq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netifsetrealnumrxqueues() and netifsetrealnumtxqueues().

If either of these functions fails, setupnicdevices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidiodestroynicdevice() will fail to find and free the netdev, resulting in a memory leak.

Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

spi: tegra210-quad: Protect currxfer check in IRQ handler

Now that all other accesses to currxfer are done under the lock, protect the currxfer NULL check in tegraqspiisrthread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->currxfer) // sees non-NULL spinlock() tqspi->currxfer = NULL spinunlock() handlexfer() spinlock() t = tqspi->currxfer // NULL! ... t->len ... // NULL dereference!

With this patch, all currxfer accesses are now properly synchronized.

Although all accesses to currxfer are done under the lock, in tegraqspiisrthread() it checks for NULL, releases the lock and reacquires it later in handlecpubasedxfer()/handledmabasedxfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared currxfer, the handler will safely return without dereferencing the NULL pointer.

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

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

net/mlx5e: Don't store mlx5epriv in mlx5edev devlink priv

mlx5epriv is an unstable structure that can be memset(0) if profile attaching fails, mlx5epriv in mlx5edev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5edev and get mdev from the containing mlx5adev aux device structure.

This fixes a kernel oops in mlx5eremove when switchdev mode fails due to change profile failure.

$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12

$ devlink dev reload pci/0000:00:03.0 ==> oops

BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5eremove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsgdoit+0xe8/0x140

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

l2tp: avoid one data-race in l2tptunneldelwork()

We should read sk->sksocket only when dealing with kernel sockets.

syzbot reported the following data-race:

BUG: KCSAN: data-race in l2tptunneldelwork / skcommonrelease

write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sksetsocket include/net/sock.h:2092 [inline] sockorphan include/net/sock.h:2118 [inline] skcommonrelease+0xae/0x230 net/core/sock.c:4003 udplibclose+0x15/0x20 include/net/udp.h:325 inetrelease+0xce/0xf0 net/ipv4/afinet.c:437 sockrelease net/socket.c:662 [inline] sockclose+0x6b/0x150 net/socket.c:1455 fput+0x29b/0x650 fs/filetable.c:468 fput+0x1c/0x30 fs/filetable.c:496 taskworkrun+0x131/0x1a0 kernel/taskwork.c:233 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop kernel/entry/common.c:44 [inline] exittousermodeloop+0x1fe/0x740 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x1e1/0x2b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tptunneldelwork+0x2f/0x1a0 net/l2tp/l2tpcore.c:1418 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0x4ce/0x9d0 kernel/workqueue.c:3340 workerthread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 retfromfork+0x149/0x290 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

value changed: 0xffff88811b818000 -> 0x0000000000000000

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

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.

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

octeonep: Fix memory leak in octepdevicesetup()

In octepdevicesetup(), if octepctrlnetinit() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory.

Fix this by jumping to the unsupporteddev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

net: cpsw: Execute ndosetrxmode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstacklvl from warn+0xb8/0x11c warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0x98 cpswaddmcaddr from hwaddrrefsyncdev+0xc4/0xec hwaddrrefsyncdev from devmcadd+0x78/0x88 devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from ipv6devmcinc+0x1fc/0x2f0 ipv6devmcinc from ipv6sockmcjoin+0x124/0x1b4 ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosocksetsockopt from syssetsockopt+0x84/0xac syssetsockopt from retfastsyscall+0x0/0x54

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver.

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

pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains

Fix out-of-range access of bc->domains in imx8mblkctrlremove().

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

net: usb: asix: validate PHY address before use

The ASIX driver reads the PHY address from the USB device via asixreadphyaddr(). A malicious or faulty device can return an invalid address (>= PHYMAXADDR), which causes a warning in mdiobusgetphy():

addr 207 out of range WARNING: drivers/net/phy/mdiobus.c:76

Validate the PHY address in asixreadphyaddr() and remove the now-redundant check in ax88172a.c.

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

iio: adc: at91-sama5d2adc: Fix potential use-after-free in sama5d2adc driver

at91adcinterrupt can call at91adctouchdatahandler function to start the work by schedulework(&st->touchst.workq).

If we remove the module which will call at91adcremove to make cleanup, it will free indiodev through iiodeviceunregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:

CPU0 CPU1

| at91adcworkqhandler at91adcremove | iiodeviceunregister(indiodev) | //free indiodev a bit later | | iiopushtobuffers(indiodev) | //use indiodev

Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91adcremove.

binfmtmisc: restore write access before closing files opened by openexec()

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

staging: rtl8723bs: fix out-of-bounds read in rtwgetie() parser

The Information Element (IE) parser rtwgetie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on malformed frames.

iio: accel: bmc150: Fix irq assumption regression

block: Use RCU in blkmq[un]quiescetagset() instead of set->taglistlock

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

usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal

The delayed work item otgevent is initialized in fslotgconf() and scheduled under two conditions: 1. When a host controller binds to the OTG controller. 2. When the USB ID pin state changes (cable insertion/removal).

A race condition occurs when the device is removed via fslotgremove(): the fslotg instance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work function fslotgevent() accesses the already freed memory.

The problematic scenario:

(detach thread) | (delayed work) fslotgremove() | kfree(fslotgdev) //FREE| fslotgevent() | og = containerof(...) //USE | og-> //USE

Fix this by calling disabledelayedworksync() in fslotgremove() before deallocating the fslotg structure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.

This bug was identified through static analysis.

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

bpf: Add bpfprogrundatapointers()

syzbot found that clsbpfclassify() is able to change tcskbcb(skb)->dropreason triggering a warning in skskbreasondrop().

WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 skskbreasondrop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 skskbreasondrop+0x76/0x170 net/core/skbuff.c:1214

struct tcskbcb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and dataend for clsactbpf").

dropreason was added later.

Add bpfprogrundatapointers() helper to save/restore the netsched storage colliding with BPF datameta/dataend.

atm/fore200e: Fix possible data race in fore200eopen()

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

ntfs3: Fix uninit buffer allocated by getname()

Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.

ALSA: firewire-motu: add bounds check in putuser loop for DSP events

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

net/handshake: duplicate handshake cancellations leak socket

When a handshake request is cancelled it is removed from the handshakenet->hnrequests list, but it is still present in the handshakerhashtbl until it is destroyed.

If a second cancellation request arrives for the same handshake request, then removepending() will return false... and assuming HANDSHAKEFREQCOMPLETED isn't set in req->hrflags, we'll continue processing through the outtrue label, where we put another reference on the sock and a refcount underflow occurs.

This can happen for example if a handshake times out - particularly if the SUNRPC client sends the AUTHTLS probe to the server but doesn't follow it up with the ClientHello due to a problem with tlshd. When the timeout is hit on the server, the server will send a FIN, which triggers a cancellation request via xsresettransport(). When the timeout is hit on the client, another cancellation request happens via xstlshandshakesync().

Add a testandsetbit(HANDSHAKEFREQCOMPLETED) in the pending cancel path so duplicate cancels can be detected.

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

KVM: Disallow toggling KVMMEMGUESTMEMFD on an existing memslot

Reject attempts to disable KVMMEMGUESTMEMFD on a memslot that was initially created with a guestmemfd binding, as KVM doesn't support toggling KVMMEMGUESTMEMFD on existing memslots. KVM prevents enabling KVMMEMGUESTMEMFD, but doesn't prevent clearing the flag.

Failure to reject the new memslot results in a use-after-free due to KVM not unbinding from the guestmemfd instance. Unbinding on a FLAGSONLY change is easy enough, and can/will be done as a hardening measure (in anticipation of KVM supporting dirty logging on guestmemfd at some point), but fixing the use-after-free would only address the immediate symptom.

================================================================== BUG: KASAN: slab-use-after-free in kvmgmemrelease+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745

CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5c0 kasanreport+0xb4/0xe0 kvmgmemrelease+0x362/0x400 [kvm] fput+0x2fa/0x9d0 taskworkrun+0x12c/0x200 doexit+0x6ae/0x2100 dogroupexit+0xa8/0x230 x64sysexitgroup+0x3a/0x50 x64syscall+0x737/0x740 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 </TASK>

Allocated by task 745 on cpu 6 at 9.746971s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasankmalloc+0x77/0x90 kvmsetmemoryregion.part.0+0x652/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 745 on cpu 6 at 9.747467s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasansavefreeinfo+0x37/0x50 kasanslabfree+0x3b/0x60 kfree+0xf5/0x440 kvmsetmemslot+0x3c2/0x1160 [kvm] kvmsetmemoryregion.part.0+0x86a/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53