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

KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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

fuse-uring: fix moving cancelled entry to entinuserspace list

fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.

Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.

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

fuse-uring: remove request-less entries from entwreqqueue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be terminated and fuseuringreqend() will set ent->fusereq to NULL but it will leave the entry on entwreqqueue in FRRSFUSEREQ state. This can lead to a NULL deref if the request expiration logic scans entwreqqueue in the window before the entry is moved off it.

Fix this by taking the entry off entwreqqueue and changing its state from FRRSFUSEREQ to FRRSINVALID before terminating the request.

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

net: ethtool: phy: avoid NULL deref when PHY driver is unbound

phydev->drv can become NULL while the phydevice is still attached to its netdevice, namely after the PHY driver is unbound via sysfs:

echo <mdioid> > /sys/bus/mdiobus/drivers/<phydrv>/unbind

phyremove() clears phydev->drv but doesn't call phydetach(), so the phydevice stays in the link topology xarray and ethnlreqgetphydev() still hands it back. ETHTOOLMSGPHYGET then oopses on:

repdata->drvname = kstrdup(phydev->drv->name, GFPKERNEL);

drvname is already treated as optional by phyreplysize(), phyfillreply() and phycleanupdata(), so just skip the allocation when there is no driver bound.

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

net: ethtool: fix NULL pointer dereference in phyreplysize

In phypreparedata(), several strings such as 'name', 'drvname', 'upstreamsfpname', and 'downstreamsfpname' are allocated using kstrdup(). However, these allocations were not checked for failure.

If kstrdup() fails for 'name', it returns NULL while the function continues. This leads to a kernel NULL pointer dereference and panic later in phyreplysize() when it unconditionally calls strlen() on the NULL pointer.

While other strings like 'upstreamsfpname' might be checked before access in certain code paths, failing to handle these allocations consistently can lead to incomplete data reporting or hidden bugs.

Fix this by adding proper NULL checks for all kstrdup() calls in phypreparedata() and implement a centralized error handling path using goto labels to ensure all previously allocated resources are freed on failure.

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

igc: fix potential skb leak in igcfpexmitsmdframe()

When igcfpeinittxdescriptor() fails, no one takes care of an allocated skb, leaking it. [1] Use devkfreeskbany() on failure.

Tested on an I226 adapter with the following command, while injecting faults in igcfpeinittxdescriptor() to trigger the error path. # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on

[1] unreferenced object 0xffff888113c6cdc0 (size 224): ... backtrace (crc be3d3fda): kmemcacheallocnodenoprof+0x3b1/0x410 allocskb+0xde/0x830 igcfpexmitsmdframe.isra.0+0xad/0x1b0 igcfpesendmpacket+0x37/0x90 ethtoolmmsvverifytimer+0x15e/0x300

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

perf/x86/intel: Improve validation and configuration of ACR masks

Currently there are several issues on the user space ACR mask validation and configuration. - The validation for user space ACR mask (attr.config2) is incomplete, e.g., the ACR mask could include the index which belongs to another ACR events group, but it's not validated. - An early return on an invalid ACR mask caused all subsequent ACR groups to be skipped. - The stale hardware ACR mask (hw.config1) is not cleared before setting new hardware ACR mask.

The following changes address all of the above issues. - Figure out the event index group of an ACR group. Any bits in the user-space mask not present in the index group are now dropped. - Instead of an early return on invalid bits, drop only the invalid portions and continue iterating through all ACR events to ensure full configuration. - Explicitly clear the stale hardware ACR mask for each event prior to writing the new configuration.

Besides, a non-leader event member of ACR group could be disabled in theory. This could cause bit-shifting errors in the acrmask of remaining group members. But since ACR sampling requires all events to be active, this should not be a big concern in real use case. Add a "FIXME" comment to notice this risk.

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

fuse: fix uninit-value in fusedentryrevalidate()

fusedentryrevalidate() may be called with a dentry that didn't had ->dtime initialised. The issue was found with KMSAN, where lookupopen() calls dalloc(), followed by drevalidate(), as shown below:

===================================================== BUG: KMSAN: uninit-value in fusedentryrevalidate+0x150/0x13d0 fs/fuse/dir.c:394 fusedentryrevalidate+0x150/0x13d0 fs/fuse/dir.c:394 drevalidate fs/namei.c:1030 [inline] lookupopen fs/namei.c:4405 [inline] openlastlookups fs/namei.c:4583 [inline] pathopenat+0x1614/0x64c0 fs/namei.c:4827 dofileopen+0x2aa/0x680 fs/namei.c:4859 [...]

Uninit was created at: slabpostallochook mm/slub.c:4466 [inline] slaballocnode mm/slub.c:4788 [inline] kmemcachealloclrunoprof+0x382/0x1280 mm/slub.c:4807 dalloc+0x55/0xa00 fs/dcache.c:1740 dallocparallel+0x99/0x2740 fs/dcache.c:2604 lookupopen fs/namei.c:4398 [inline] openlastlookups fs/namei.c:4583 [inline] pathopenat+0x135f/0x64c0 fs/namei.c:4827 dofileopen+0x2aa/0x680 fs/namei.c:4859 [...] =====================================================

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

iommu/amd: Bounds-check devid in rlookupamdiommu()

iommudeviceregister() walks every device on the PCI bus via busforeachdev() and calls amdiommuprobedevice() for each. The inlined checkdevice() path computes the device's sbdf, calls rlookupamdiommu() to find the owning IOMMU, and only afterwards verifies devid <= pciseg->lastbdf. rlookupamdiommu() indexes rlookuptable[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run.

This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irqlookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which checkdevice() then dereferences as a struct amdiommu , causing a boot-time GPF.

Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object:

pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amdiommuprobedevice+0x54/0x3a0 Call Trace: iommuprobedevice+0x107/0x520 probeiommugroup+0x29/0x50 busforeachdev+0x7e/0xe0 iommudeviceregister+0xc9/0x240 iommugotostate+0x9c0/0x1c60 amdiommuinit+0x14/0x40 pciiommuinit+0x16/0x60 dooneinitcall+0x47/0x2f0

Guard the array access in rlookupamdiommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.

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

wifi: cfg80211: enforce HE/EHT cap/oper consistency

Xiang Mei reports that mac80211 could crash if ehtcap is set but ehtoper isn't. Rather than fixing that for the individual user(s), enforce that both HE/EHT have consistent elements.

Bluetooth: fix memory leak in error path of hciallocdev()

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

iommu/dma: Do not try to iommumap a 0 length region in swiotlb

iommudmaiovalinkswiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommumap() with a 0 size which the iommupt implementation will fail as illegal.

It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARNON.

Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink.

This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition.

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

clk: spacemit: ccumix: fix inverted condition in ccumixtriggerfc()

Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling.

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

KVM: x86: Do IRR scan in kvmapicupdateirr even if PIR is empty

Fall back to apicfindhighestvector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR.

In a nested VM stress test, the following WARNING fires in vmxchecknestedevents() when kvmcpuhasinterrupt() reports a pending interrupt but the subsequent kvmapichasinterrupt() (which invokes vmxsyncpirtoirr() again) returns -1:

WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmxchecknestedevents+0x6bf/0x6e0 [kvmintel] Call Trace: kvmcheckandinjectevents vcpuenterguest.constprop.0 vcpurun kvmarchvcpuioctlrun kvmvcpuioctl x64sysioctl dosyscall64 entrySYSCALL64afterhwframe

The root cause is a race between vmxsyncpirtoirr() on the target vCPU and vmxdeliverpostedinterrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction:

1. pitestandsetpir(vector) -- sets the PIR bit 2. pitestandseton() -- sets PID.ON

The following interleaving triggers the bug:

Sender vCPU (IPI): Target vCPU (1st syncpirtoirr): B1: set PIR[vector] A1: piclearon() A2: piharvestpir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct maxirr) B2: set PID.ON = 1

Target vCPU (2nd syncpirtoirr): C1: piteston() -> TRUE (from B2) C2: piclearon() -> ON=0 C3: piharvestpir() -> PIR empty C4: maxirr = -1, early return IRR NOT SCANNED

The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpuenterguest() iteration), but the incorrect maxirr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle.

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

crypto: qat - fix IRQ cleanup on 6xxx probe failure

When adfdevup() partially completes and then fails, the IRQ handlers registered during adfisrresourcealloc() are not detached before the MSI-X vectors are released.

Since the device is enabled with pcimenabledevice(), calling pciallocirqvectors() internally registers pcimmsirelease() as a devres action. On probe failure, devres runs pcimmsirelease() which calls pcifreeirqvectors(), tearing down the MSI-X vectors while IRQ handlers (for example 'qat0-bundle0') are still attached. This causes removeprocentry() warnings:

[ 22.163964] removeprocentry: removing non-empty directory 'irq/143', leaking at least 'qat0-bundle0'

Moving the devmaddactionorreset() before adfdevup() does not solve the problem since devres runs in LIFO order and pcimmsirelease(), registered later inside adfdevup(), would still fire before adfdevicedown().

Fix by calling adfdevdown() explicitly when adfdevup() fails, to properly free IRQ handlers before devres releases the MSI-X vectors.

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

md/raid10: fix deadlock with check operation and nowait requests

When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nrpending value to signal there is work pending inside of waitbarrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nrpending in waitbarrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10makerequest") added a call to raidendbioio() to fix a memory leak when NOWAIT requests hit this condition. raidendbioio() eventually calls allowbarrier() and it will unconditionally do an atomicdecandtest(&conf->nrpending) even though the corresponding increment on nrpending didn't happen in the NOWAIT case.

This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nrpending value underflowing and so the md resync thread gets stuck waiting for nrpending to == 0.

Output of r10conf state of the array when we hit this condition:

crash> struct r10conf barrier = 1, nrpending = { counter = -41 }, nrwaiting = 15, nrqueued = 0,

Example of mdsync thread stuck waiting on raisebarrier() and other requests stuck in waitbarrier():

md1resync [<0>] raisebarrier+0xce/0x1c0 [<0>] raid10syncrequest+0x1ca/0x1ed0 [<0>] mddosync+0x779/0x1110 [<0>] mdthread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] retfromfork+0x34/0x50 [<0>] retfromforkasm+0x1a/0x30

kworker/u1040:2+flush-253:4 [<0>] waitbarrier+0x1de/0x220 [<0>] regularrequestwait+0x30/0x180 [<0>] raid10makerequest+0x261/0x1000 [<0>] mdhandlerequest+0x13b/0x230 [<0>] submitbio+0x107/0x1f0 [<0>] submitbionoacctnocheck+0x16f/0x390 [<0>] ext4iosubmit+0x24/0x40 [<0>] ext4dowritepages+0x254/0xc80 [<0>] ext4writepages+0x84/0x120 [<0>] dowritepages+0x7a/0x260 [<0>] writebacksingleinode+0x3d/0x300 [<0>] writebacksbinodes+0x1dd/0x470 [<0>] writebackinodeswb+0x4c/0xe0 [<0>] wbwriteback+0x18b/0x2d0 [<0>] wbworkfn+0x2a1/0x400 [<0>] processonework+0x149/0x330 [<0>] workerthread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] retfromfork+0x34/0x50 [<0>] retfromforkasm+0x1a/0x30

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

mm/mempolicy: fix memory leaks in weightedinterleaveautostore()

weightedinterleaveautostore() fetches oldwistate inside the if (!input) block only. This causes two memory leaks:

1. When a user writes "false" and the current mode is already manual, the function returns early without freeing the freshly allocated newwistate.

2. When a user writes "true", oldwistate stays NULL because the fetch is skipped entirely. The old state is then overwritten by rcuassignpointer() but never freed, since the cleanup path is gated on oldwistate being non-NULL. A user can trigger this repeatedly by writing "1" in a loop.

Fix both leaks by moving the oldwistate fetch before the input check, making it unconditional. This also allows a unified early return for both "true" and "false" when the requested mode matches the current mode.

Reviewed by: Donet Tom <donettom@linux.ibm.com>

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

ovpn: tcp - don't deref NULL sksocket member after tcpclose()

When deleting a peer in case of keepalive expiration, the peer is removed from the OpenVPN hashtable and is temporary inserted in a "release list" for further processing.

This happens in: ovpnpeerkeepalivework() unlockovpn(releaselist)

This processing includes detaching from the socket being used to talk to this peer, by restoring its original proto and socket ops/callbacks.

In case of TCP it may happen that, while the peer is sitting in the release list, userspace decides to close the socket. This will result in a concurrent execution of:

tcpclose(sk) tcpclose(sk) sockorphan(sk) sksetsocket(sk, NULL)

The last function call will set sk->sksocket to NULL.

When the releasing routine is resumed, ovpntcpsocketdetach() will attempt to dereference sk->sksocket to restore its original ops member. This operation will crash due to sk->sksocket being NULL.

Fix this race condition by testing-and-accessing sk->sksocket atomically under sk->skcallbacklock.

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

net/mlx5e: Fix deadlocks between devlink and netdev instance locks

In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdevtrylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering.

The correct lock order is described by the init flow: probeone -> mlx5initone (acquires devlink lock) -> mlx5initonedevllocked -> mlx5registerdevice -> mlx5rescandriverslocked -...-> mlx5eprobe -> mlx5eprobe -> registernetdev (acquires rtnl lock) -> registernetdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock.

But in the current recovery flow, the order is wrong: mlx5etxerrcqework (acquires netdev lock) -> mlx5ereportertxerrcqe -> mlx5ehealthreport -> devlinkhealthreport (acquires devlink lock => boom!) -> devlinkhealthreporterrecover -> mlx5etxreporterrecover -> mlx5etxreporterrecoverfromctx -> mlx5etxreportererrcqerecover

The same pattern exists in: mlx5ereporterrxtimeout mlx5ereportertxptpsqunhealthy mlx5ereportertxtimeout

Fix these by moving the netdevtrylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.

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

afunix: Fix memleak of newsk in unixstreamconnect().

When preparepeercred() fails in unixstreamconnect(), unixreleasesock() is not called for newsk, and the memory is leaked.

Let's move preparepeercred() before unixcreate1().

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

drm/i915/vrr: Configure VRR timings after enabling TRANSDDIFUNCCTL

Apparently ICL may hang with an MCE if we write TRANSVRRVMAX/FLIPLINE before enabling TRANSDDIFUNCCTL.

Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason.

BSpec does tell us to configure VRR after enabling TRANSDDIFUNCCTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANSVRRCTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANSDDIFUNCCTL and TRANSVRRVMAX/VMIN/FLIPLINE, among other things

So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later.

BSpec: 22243 (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74)

drm/amdgpu: add upper bound check on user inputs in signal ioctl

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

drm/amdgpu/userq: Fix reference leak in amdgpuuserqwaitioctl

Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small.

(cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27)

drm/amdgpu: add upper bound check on user inputs in wait ioctl

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

ublk: fix NULL pointer dereference in ublkctrlsetsize()

ublkctrlsetsize() unconditionally dereferences ub->ubdisk via setcapacityandnotify() without checking if it is NULL.

ub->ubdisk is NULL before UBLKCMDSTARTDEV completes (it is only assigned in ublkctrlstartdev()) and after UBLKCMDSTOPDEV runs (ublkdetachdisk() sets it to NULL). Since the UBLKCMDUPDATESIZE handler performs no state validation, a user can trigger a NULL pointer dereference by sending UPDATESIZE to a device that has been added but not yet started, or one that has been stopped.

Fix this by checking ub->ubdisk under ub->mutex before dereferencing it, and returning -ENODEV if the disk is not available.

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

drm/tests: shmem: Hold reservation lock around vmap/vunmap

Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmaplocked, which led to errors such as show below.

[ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:390 drmgemshmemvmaplocked+0x3a3/0x6f0

[ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:293 drmgemshmempinlocked+0x1fe/0x350

[ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:234 drmgemshmemgetpageslocked+0x23c/0x370

[ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drmgemshmemhelper.c:452 drmgemshmemvunmaplocked+0x101/0x330

Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers.

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

drm/tests: shmem: Hold reservation lock around madvise

Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drmgemshmemmadviselocked(), which led to errors such as show below.

[ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drmgemshmemhelper.c:499 drmgemshmemmadviselocked+0xde/0x140

Only export the new helper drmgemshmemmadvise() for Kunit tests. This is not an interface for regular drivers.

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

drm/tests: shmem: Hold reservation lock around purge

Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drmgemshmempurgelocked(), which led to errors such as show below.

[ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drmgemshmemhelper.c:515 drmgemshmempurgelocked+0x51c/0x740

Only export the new helper drmgemshmempurge() for Kunit tests. This is not an interface for regular drivers.

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

misc: tifpc202: fix a potential memory leak in probe function

Use foreachchildofnodescoped() to simplify the code and ensure the device node reference is automatically released when the loop scope ends.