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

i2c: imx-lpi2c: mark I2C adapter when hardware is powered down

On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers.

During system suspend/resume, there exists a time window between: - suspendnoirq and the system entering suspend - the system starting to resume and resumenoirq

In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored.

If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang.

Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.

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

fuse-uring: fix EFAULT clobber in fuseuringcommit

copyfromuser() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuseoutheader)). fuseuringcommit stores that residual in ssizet err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual.

err = copyfromuser(&req->out.h, &ent->headers->inout, sizeof(req->out.h)); if (err) { req->out.h.error = -EFAULT; goto out; / err is the positive residual / } ... out: fuseuringreqend(ent, req, err);

fuseuringreqend() then runs

if (error) req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual. FUSE callers such as fusesimplerequest() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuseuringreqend() receives a negative errno and sets req->out.h.error to -EFAULT.

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

fuse-uring: end fusereq on io-uring cancel task work

When iouring delivers task work with tw.cancel set (PFEXITING, PFKTHREAD fallback, or percpurefisdying on the ring context), fuseuringsendintask() takes the cancel branch, assigns -ECANCELED, and falls through to fuseuringsend(). That path only flips the entry to FRRSUSERSPACE and completes the iouring cmd; it never discharges the ring entry's owning reference to the fusereq that fuseuringaddreqtoringent() handed it at dispatch time.

fuseuringsendintask() tw.cancel == true err = -ECANCELED fuseuringsend(ent, cmd, err, issueflags) ent->state = FRRSUSERSPACE listmove(&ent->list, &queue->entinuserspace) ent->cmd = NULL iouringcmddone(-ECANCELED) / ent->fusereq still set, req still hashed /

The fusereq stays linked on fpq->processing[hash] and fuserequestend() is never invoked. The originating syscall thread blocks in D-state in requestwaitanswer() until fuseabortconn() runs, which can be the entire connection lifetime. For FRBACKGROUND requests fc->numbackground is never decremented either, so repeated cancels inflate the counter until maxbackground is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single iouring worker thread exits while the fuse connection stays up), so this cannot be left for fuseabortconn() to clean up.

Ending the req but still routing the entry through fuseuringsend() is not enough: that leaves a req-less entry on entinuserspace, and entlistrequestexpired() dereferences ent->fusereq unconditionally on the head of that list, which would then NULL-deref.

Fix the cancel branch to release the entry directly. Remove it from the queue, complete the iouring cmd, end the fusereq, free the entry, and drop its queuerefs (waking the teardown waiter if it was the last).

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

i2c: davinci: fix division by zero on missing clock-frequency

When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCII2CDEFAULTBUSFREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz.

The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->busfreq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence.

Fix this by redefining DAVINCII2CDEFAULTBUSFREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases.

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

regulator: tps65219: fix irqdata.rdev not being assigned

Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper function") removed the tps65219getrdevbyname() helper along with the irqdata.rdev assignment that depended on it. This left irqdata.rdev uninitialized for all IRQs, causing undefined behavior when regulatornotifiercallchain() is called from the IRQ handler:

Internal error: Oops: 0000000096000004 pc : regulatornotifiercallchain lr : tps65219regulatorirqhandler Call trace: regulatornotifiercallchain tps65219regulatorirqhandler handlenestedirq regmapirqthread irqthreadfn irqthread kthread retfromfork

Instead of restoring a dedicated lookup array, restructure the probe function to combine regulator registration with IRQ registration in the same loop. This way the rdev returned by devmregulatorregister() is naturally available for assigning to irqdata.rdev without any auxiliary data structure.

Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any registered regulator are registered with rdev=NULL, and the IRQ handler is protected with a NULL check to avoid crashing.

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

netfs, afs: Fix write skipping in dir/link writepages

Fix netfswritesingle() and afssinglewritepages() to better handle a write that would be skipped due to lock contention and WBSYNCNONE by returning 1 from netfswritesingle() if it skipped and making afssinglewritepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark.

This is really only theoretical for directories in netfswritesingle() as the only path to that is through afssinglewritepages() that takes the ->validatelock around it, thereby serialising it.

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

x86/kexec: Push kjump return address even for non-kjump kexec

The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec.

After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec).

That commit fixed things for the actual kjump path, but no longer "gratuitously" pushes the unused return address to the stack in the non-kjump path. Put that back in the non-kjump path, to prevent purgatory from crashing when trying to access it.

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

xfrm: iptfs: fix ABBA deadlock in iptfsdestroystate()

iptfsdestroystate() calls hrtimercancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems.

For the output timer (iptfstimer): - iptfsdestroystate() holds x->lock, calls hrtimercancel() - iptfsdelaytimer() callback takes x->lock

For the drop timer (droptimer): - iptfsdestroystate() holds droplock, calls hrtimercancel() - iptfsdroptimer() callback takes droplock

Both timers use HRTIMERMODERELSOFT, so their callbacks run in softirq context. When hrtimercancel() is called for a soft timer that is currently executing on another CPU, hrtimercancelwaitrunning() spins on softirqexpirylock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimercancel(), a circular dependency forms:

CPU 0: holds lockA -> waits for softirqexpirylock CPU 1: holds softirqexpirylock -> waits for lockA

Fix by calling hrtimercancel() before acquiring the respective locks. hrtimercancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimercancel() already guarantees.

Found by source code audit.

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

drm/v3d: Fix global performance monitor reference counting

In the SETGLOBAL ioctl, v3dperfmonfind() bumps the reference count on the perfmon it returns, but v3dperfmonsetglobalioctl() and v3dperfmondelete() fail to release that reference on several paths:

1. v3dperfmonsetglobalioctl() leaks the reference on its error paths.

2. CLEARGLOBAL leaks both the find reference and the reference previously stashed in v3d->globalperfmon by the SETGLOBAL ioctl that configured it.

3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SETGLOBAL ioctl.

Release each of these references explicitly.

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

wifi: mt76: fix deadlock in remain-on-channel

mt76remainonchannel() and mt76roccomplete() call mt76setchannel() while already holding dev->mutex. Since mt76setchannel() also acquires dev->mutex, this results in a deadlock.

Use mt76setchannel() instead of mt76setchannel(). Add canceldelayedworksync() for macwork before acquiring the mutex in mt76remainonchannel() to prevent a secondary deadlock with the macwork workqueue.

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

smb: client: use kzalloc to zero-initialize security descriptor buffer

Commit 62e7dd0a39c2d ("smb: common: change the data type of numaces to le16") split struct smbacl's le32 numaces field into le16 numaces and le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1].

When building an ACL descriptor in buildsecdesc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data.

When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndrpullsecuritydescriptor failed: Range Error", causing chmod to fail with EINVAL.

Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized.

[1] https://learn.microsoft.com/en-us/openspecs/windowsprotocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428

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

platform/chrome: crosectypec: Init mutex in Thunderbolt registration

crostypecregisterthunderbolt() missed initializing the adata->lock mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in crostypecaltmodework()).

Initialize the mutex in crostypecregisterthunderbolt() to fix the issue.

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

mm/damon/core: fix damoncall() vs kdamondfn() exit race

Patch series "mm/damon/core: fix damoncall()/damoswalk() vs kdmond exit race".

damoncall() and damoswalk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those.

This patch (of 2);

When kdamondfn() main loop is finished, the function cancels all remaining damoncall() requests and unset the damonctx->kdamond so that API callers and API functions themselves can know the context is terminated. damoncall() adds the caller's request to the queue first. After that, it shows if the kdamond of the damonctx is still running (damonctx->kdamond is set). Only if the kdamond is running, damoncall() starts waiting for the kdamond's handling of the newly added request.

The damoncall() requests registration and damonctx->kdamond unset are protected by different mutexes, though. Hence, damoncall() could race with damonctx->kdamond unset, and result in deadlocks.

For example, let's suppose kdamond successfully finished the damoncall() requests cancelling. Right after that, damoncall() is called for the context. It registers the new request, and shows the context is still running, because damonctx->kdamond unset is not yet done. Hence the damoncall() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damoncall() caller threads infinitely waits.

Fix this by introducing another damonctx field, namely callcontrolsobsolete. It is protected by the damonctx->callcontrolslock, which protects damoncall() requests registration. Initialize (unset) it in kdamondfn() before letting damonstart() returns and set it just before the cancelling of remaining damoncall() requests is executed. damoncall() reads the obsolete field under the lock and avoids adding a new request.

After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together.

Note that the deadlock will not happen when damoncall() is called for repeat mode request. In tis case, damoncall() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloconcancel, the request memory would be leaked.

The issue is found by sashiko [1].

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

mm/damon/core: fix damoswalk() vs kdamondfn() exit race

When kdamondfn() main loop is finished, the function cancels remaining damoswalk() request and unset the damonctx->kdamond so that API callers and API functions themselves can show the context is terminated. damoswalk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damonctx is still running (damonctx->kdamond is set). Only if the kdamond is running, damoswalk() starts waiting for the kdamond's handling of the newly added request.

The damoswalk() requests registration and damonctx->kdamond unset are protected by different mutexes, though. Hence, damoswalk() could race with damonctx->kdamond unset, and result in deadlocks.

For example, let's suppose kdamond successfully finished the damowwalk() request cancelling. Right after that, damoswalk() is called for the context. It registers the new request, and shows the context is still running, because damonctx->kdamond unset is not yet done. Hence the damoswalk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damoswalk() caller thread infinitely waits.

Fix this by introducing another damonctx field, namely walkcontrolobsolete. It is protected by the damonctx->walkcontrollock, which protects damoswalk() request registration. Initialize (unset) it in kdamondfn() before letting damonstart() returns and set it just before the cancelling of the remaining damoswalk() request is executed. damoswalk() reads the obsolete field under the lock and avoids adding a new request.

After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together.

The issue is found by sashiko [1].

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

thermal/of: Fix reference leak in thermalofcmlookup()

In thermalofcmlookup(), trnp is obtained via ofparsephandle(), but never released.

Use the free(devicenode) cleanup attribute to automatically release the node and fix the leak.

[ rjw: Changelog edits ]

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

accel/amdxdna: Fix potential NULL pointer dereference in context cleanup

aiedestroycontext() is invoked during error handling in aie2createcontext(). However, aiedestroycontext() assumes that the context's mailbox channel pointer is non-NULL. If mailbox channel creation fails, the pointer remains NULL and calling aiedestroycontext() can lead to a NULL pointer dereference.

In aie2createcontext(), replace aiedestroycontext() with a function which request firmware to remove the context created previously.

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

batman-adv: Avoid double-rtnllock ELP metric worker

batadvvelpgetthroughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via canceldelayedworksync() in batadvvelpifacedisable(). In this case, an rtnllock() would cause a deadlock.

To avoid this, rtnltrylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held.

But for cfg80211 interfaces, batadvgetrealnetdev() was called - which also uses rtnllock(). The approach for ethtoolgetlinkksettings() must also be used instead and the lockless version batadvgetrealnetdev() has to be called.

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

KVM: arm64: Eagerly init vgic dist/redist on vgic creation

If vgicallocateprivateirqslocked() fails for any odd reason, we exit kvmvgiccreate() early, leaving dist->rdregions uninitialised.

kvmvgicdistdestroy() then comes along and walks into the weeds trying to free the RDs. Got to love this stuff.

Solve it by moving all the static initialisation early, and make sure that if we fail halfway, we're in a reasonable shape to perform the rest of the teardown. While at it, reset the vgic model on failure, just in case...

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

serial: 8250: Fix TX deadlock when using DMA

dmaengineterminateasync does not guarantee that the dmatxcomplete callback will run. The callback is currently the only place where dma->txrunning gets cleared. If the transaction is canceled and the callback never runs, then dma->txrunning will never get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear dma->txrunning after we terminate the DMA transaction. This is "safe" because serial8250txdmaflush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->txrunning is serialized.

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

igb: remove napisynchronize() in igbdown()

When an AFXDP zero-copy application terminates abruptly (e.g., kill -9), the XSK buffer pool is destroyed but NAPI polling continues. igbcleanrxirqzc() repeatedly returns the full budget, preventing napicompletedone() from clearing NAPISTATESCHED.

igbdown() calls napisynchronize() before napidisable() for each queue vector. napisynchronize() spins waiting for NAPISTATESCHED to clear, which never happens. igbdown() blocks indefinitely, the TX watchdog fires, and the TX queue remains permanently stalled.

napidisable() already handles this correctly: it sets NAPISTATEDISABLE. After a full-budget poll, napipoll() checks napidisablepending(). If set, it forces completion and clears NAPISTATESCHED, breaking the loop that napisynchronize() cannot.

napisynchronize() was added in commit 41f149a285da ("igb: Fix possible panic caused by Rx traffic arrival while interface is down"). napidisable() provides stronger guarantees: it prevents further scheduling and waits for any active poll to exit. Other Intel drivers (ixgbe, ice, i40e) use napidisable() without a preceding napisynchronize() in their down paths.

Remove redundant napisynchronize() call and reorder napidisable() before igbsetqueuenapi() so the queue-to-NAPI mapping is only cleared after polling has fully stopped.

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

xfrm: iptfs: fix skbput() panic on non-linear skb during reassembly

In iptfsreassemcont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear.

When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skbput() to append the data and as newskb is non-linear it triggers SKBLINEARASSERT check.

Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skbput+0x3c/0x40 [...] Call Trace: <IRQ> iptfsreassemcont+0x1ab/0x5e0 [xfrmiptfs] iptfsinputordered+0x2af/0x380 [xfrmiptfs] iptfsinput+0x122/0x3e0 [xfrmiptfs] xfrminput+0x91e/0x1a50 xfrm4esprcv+0x3a/0x110 ipprotocoldeliverrcu+0x1d7/0x1f0 iplocaldeliverfinish+0xbe/0x1e0 netifreceiveskbcore.constprop.0+0xb56/0x1120 netifreceiveskblistcore+0x133/0x2b0 netifreceiveskblistinternal+0x1ff/0x3f0 napicompletedone+0x81/0x220 virtnetpoll+0x9d6/0x116e [virtionet] napipoll.constprop.0+0x2b/0x270 netrxaction+0x162/0x360 handlesoftirqs+0xdc/0x510 irqexitrcu+0xe7/0x110 irqexitrcu+0xe/0x20 commoninterrupt+0x85/0xa0 </IRQ> <TASK>

Fix this by checking if the skb is non-linear. If it is, linearize it by calling skblinearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it.

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

Bluetooth: L2CAP: Fix deadlock in l2capconndel()

l2capconndel() calls canceldelayedworksync() for both infotimer and idaddrtimer while holding conn->lock. However, the work functions l2capinfotimeout() and l2capconnupdateidaddr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2capconndel() takes the lock.

Move the work cancellations before acquiring conn->lock and use disabledelayedworksync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hciconndel().

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

xfrm: iptfs: validate inner IPv4 header length in IPTFS payload

Add validation of the inner IPv4 packet totlen and ihl fields parsed from decrypted IPTFS payloads in inputprocesspayload(). A crafted ESP packet containing an inner IPv4 header with totlen=0 causes an infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the data offset never advances and the while(data < tail) loop never terminates, spinning forever in softirq context.

Reject inner IPv4 packets where totlen < ihl4 or ihl4 < sizeof(struct iphdr), which catches both the totlen=0 case and malformed ihl values. The normal IP stack performs this validation in iprcvcore(), but IPTFS extracts and processes inner packets before they reach that layer.

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

dmaengine: idxd: Fix crash when the event log is disabled

If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.

Also, only try to free the event log if it was properly allocated.

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

drm/xe/regsr: Fix leak on xastore failure

Free the newly allocated entry when xastore() fails to avoid a memory leak on the error path.

v2: use goto failfree. (Bala)

(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)

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

accel/amdxdna: Fix NULL pointer dereference of mgmtchann

mgmtchann may be set to NULL if the firmware returns an unexpected error in aie2sendmgmtmsgwait(). This can later lead to a NULL pointer dereference in aie2hwstop().

Fix this by introducing a dedicated helper to destroy mgmtchann and by adding proper NULL checks before accessing it.

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

HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer

Add DMA buffer readiness check before reading DMA buffer to avoid unexpected NULL pointer accessing.

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

wifi: ath12k: fix dead lock while flushing management frames

Commit [1] converted the management transmission work item into a wiphy work. Since a wiphy work can only run under wiphy lock protection, a race condition happens in below scenario:

1. a management frame is queued for transmission. 2. ath12kmacopflush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12kmacflush() the process waits for the transmission done. 3. Since wiphy lock has been taken by the flush process, the transmission work item has no chance to run, hence the dead lock.

From user view, this dead lock results in below issue:

wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticated wlp8s0: associate with xxxxxx (try 1/3) wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTHLEAVING) ath12kpci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1

The dead lock can be avoided by invoking wiphyworkflush() to proactively run the queued work item. Note actually it is already present in ath12kmacopflush(), however it does not protect the case where vif being NULL. Hence move it ahead to cover this case as well.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPLV1.0V2.0SILICONZ-1.115823.3

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

exfat: fix refcount leak in exfatfind

Fix refcount leaks in exfatfind related to exfatgetdentryset.

Function exfatgetdentryset would increase the reference counter of es->bh on success. Therefore, exfatputdentryset must be called after exfatgetdentryset to ensure refcount consistency. This patch relocate two checks to avoid possible leaks.

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

spi: microchip-core-qspi: stop checking viability of op->maxfreq in supportsop callback

In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->maxfreq in mchpcoreqspisetupclock() was copied into mchpcoreqspisupportsop(). Unfortunately, op->maxfreq is not valid when this function is called during probe but is instead zero. Accordingly, baudrateval is calculated to be INTMAX due to division by zero, causing probe of the attached memory device to fail.

Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supportsop callback when the peropfreq capability was added, so just remove it to restore prior functionality.