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

ksmbd: fix use-after-free in oplock break notification

smb2oplockbreaknoti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, sessionfdcheck() clears opinfo->conn and drops its conn reference under ci->mlock, and the last ksmbdconnput() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbdconnget() is a plain atomicinc, and the queued break work later dereferences the stale conn via ksmbdconnwrite(), a use-after-free reachable by any authenticated client holding a durable batch oplock.

Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplockbreak() already holds a live ksmbdfile (or an explicit ksmbdinodelookuplock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->ofp, which a concurrent close may free. Select and pin the connection under ci->mlock, the same lock sessionfdcheck() and ksmbdreopendurablefd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures.

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

mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()

copyhugetlbpagerange() clears the uffd-wp bit of migration and hwpoison entries with hugepteclearuffdwp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pteswpuffdwp() and pteswpmkuffdwp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.

No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADVHWPOISON on a 2MB anon hugetlb page shows:

offset before=120e00 offset after =120e02

The fallout is mostly latent: rmap walks match migration entries by folio range and removemigrationpte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlbchangeprotection() rewriting a writable migration entry via makereadablemigrationentry(swpoffset(entry)) -- propagates it.

Migration entries legitimately carry uffd-wp, so clear it with pteswpclearuffdwp(), matching copynonpresentpte() and movehugepte().

A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by makehwpoisonentry() (trytounmapone() does not preserve uffd-wp on the hwpoison path) and hugetlbchangeprotection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.

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

ksmbd: defer publishing granted locks to prevent UAF/double-free race

In smb2lock(), mid-batch granted locks are published to connection-wide (conn->locklist) and file-wide (fp->locklist) lists immediately upon vfslockfile() success, while also remaining tracked on the stack-local rollbacklist.

If a subsequent element in the same SMB2LOCK request array fails validation or execution, the thread jumps to out: and walks rollbacklist to undo previously granted locks. However, because the granted lock was already published to conn->locklist, a concurrent UNLOCK request on the same connection can find the lock object and kfree() it before the rollback loop executes.

When the granting thread subsequently walks rollbacklist, it dereferences and frees the already-freed ksmbdlock structure, resulting in a Use-After-Free and Double-Free (on both ksmbdlock and struct filelock).

Fix this by deferring the publication of granted locks to conn->locklist and fp->locklist until after the entire array of lock elements has been processed without error. Mid-batch grants remain tracked exclusively on the request-local rollbacklist until the whole batch succeeds, eliminating the race window.

drm/amdkfd: Add TLB flush after MES queue eviction/suspension

erofs: fix interlaced ztailpacking pclusters

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

drm/amdgpu/gfx6: Use PFP on the compute queues too

On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.)

This means that we have to take into consideration that the PFP also exists on compute queues on GFX6:

Use PFP for register writes on both graphics and compute queues.

In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission.

After a VM flush, emit PFPSYNCME on compute queues as well.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

dm: fix resume-vs-remove race

If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in dmdestroy. The result is that the table is destroyed without calling the postsuspend method.

Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free.

Fix this bug by refusing to resume if the device is being destroyed.

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

platform/chrome: sensorhub: Bound the EC-reported sensor number

Each EC FIFO event carries an 8-bit sensor number (in->sensornum). crosecsensorhubringhandler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which crosecsensorringprocessevent() then uses unchecked to index sensorhub->batchstate[] - allocated with only sensorhub->sensornum entries. A sensor number of sensornum or larger is an out-of-bounds read and write of batchstate[].

Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.

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

ocfs2: fix missing metadata reservation for large xattrs

[BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block.

[CAUSE] ocfs2calcxattrsetneed() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The notfound path leaves metaadd at zero, so metaac is NULL when ocfs2xattrextendallocation() runs.

A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and metaac is NULL, ocfs2addclustersinbtree() returns RESTARTMETA, and ocfs2xattrextendallocation() hits BUGON(why == RESTARTMETA).

[FIX] The case where no xattr block exists yet already calls ocfs2extendmetaneeded(&defxv.xv.xrlist) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent.

Replace the BUGON with a -ENOSPC return so that if RESTARTMETA is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.

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

crypto: qat - validate RSA CRT component lengths

The generic RSA key parser (rsahelper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size nsz, but qatrsasetkeycrt() allocates half-size DMA buffers (keysz / 2) and right-aligns each component with:

memcpy(dst + halfkeysz - len, src, len)

When a CRT component is larger than halfkeysz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption.

Add a len > halfkeysz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.

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

wifi: ath11k: fix potential buffer underflow in ath11khalrxmsdulistget()

When the first entry in msdudetails has a zero buffer address, the code accesses msdudetails[i - 1] with i == 0, causing a buffer underflow.

Fix similarly to ath12kwifi7halrxmsdulistget() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

libceph: reject zero bucket types in crushdecode

CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices.

If crushdecode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to isout(), which then indexes the OSD weight array with a negative value.

Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.

hwmon: (pmbus/core) honor vrmversion in pmbusdata2regvid()

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

netfilter: xtconnmark: reject invalid shift parameters

Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmarktgshift().

A shiftbits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shiftdir values are also accepted and silently fall back to the left-shift path.

Reject invalid revision-2 shift parameters in connmarktgcheck() so malformed rules fail at installation time, before they can reach the packet path.

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

net/sched: actpedit: fix TOCTOU heap OOB write in tc offload

There is a TOCTOU race condition in flower lockless approach between sizing a flowrule buffer and filling it. zdi-disclosures@trendmicro.com reports: The clsflower classifier operates with TCFPROTOOPSDOITUNLOCKED (flchange runs without RTNL), while RTMNEWACTION holds RTNL, so the independent locking domains make the race reachable in practice. KASAN confirms: BUG: KASAN: slab-out-of-bounds in tcfpeditoffloadactsetup+0x81b/0x930 Write of size 4 at addr ffff888001f27520 by task poc-toctou/312 The buggy address is located 0 bytes to the right of allocated 288-byte region [ffff888001f27400, ffff888001f27520) (cache kmalloc-512)

Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAPNETADMIN).

The fix introduces reading tcfpnkeys under act->tcfalock in all places using a new tcfpeditnkeyslocked() which replaces the old tcfpeditnkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than silently truncating the key count, which leads to incorrect action semantics offloaded to hardware and secondary OOB writes if the remaining capacity is zero or consumed by prior actions, we enforce remaining capacity checks and return -ENOSPC if the required space exceeds the remaining capacity.

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

accel/amdxdna: Fix potential amdxdnaumap lifetime race

amdxdnaumaprelease() calls the blocking mmuintervalnotifierremove() before removing the object from abo->mem.umaplist. If aie2populaterange() runs concurrently, it may obtain a reference to an amdxdnaumap that is being released, leading to a potential use-after-free.

Use krefgetunlesszero() in aie2populaterange() when acquiring a reference. If the reference count has already dropped to zero, release is in progress and the entry is skipped.

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

ntfs: fix mreclock ABBA deadlock in rename

ntfsfilefsync(), ntfsdirfsync() and ntfswriteinode() lock an inode's mreclock before taking the mreclock of its parent directory.

ntfsrename() takes oldni->mreclock and olddirni->mreclock before taking newni->mreclock for an existing target, or newdirni->mreclock for a cross-directory rename. This can deadlock when ntfsfilefsync() or ntfswriteinode() holds the target inode, or when ntfsdirfsync() holds a child target directory, while rename() holds the parent directory and waits for the target.

Fix this by locking the existing target inode before taking any parent directory mreclock. For cross-directory renames where the target parent is a descendant of the source parent, lock the target parent before the source parent so the directory order matches the child-to-parent order used by ntfsfilefsync(), ntfsdirfsync(), and ntfswriteinode().

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

xfrm: Check for underflow in xfrmstatemtu

Leo Lin reported OOB write issue in esp component:

xfrmstatemtu() returns u32 but performs its arithmetic in unsigned modulo-2^32 space using an attacker-influenced "headerlen + authsize + netadj" subtracted from a small "mtu" argument. A nobody user can install an IPv4 ESP tunnel SA with a large authentication key (XFRMAALGAUTHTRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc), configure a small interface MTU (68 bytes), and set XFRMATFCPAD to a large value. When a single UDP datagram is then sent through the tunnel, xfrmstatemtu() underflows to a near-2^32 value, and espoutput() consumes it as a signed int via:

padto = min(x->tfcpad, xfrmstatemtu(x, mtucached)) esp.tfclen = padto - skb->len (assigned to int)

esp.tfclen ends up negative (e.g. -207). It is sign-extended to sizet when passed to memset() inside espoutputfilltrailer(), producing a ~16 EB write of zeroes at skbtailpointer(skb). KASAN logs it as "Write of size 18446744073709551537 at addr ffff888...".

Check for underflow and return 1. This causes the sendmsg attempt to fail with ENETUNREACH.

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

net: bridge: use a stable FDB dst snapshot in RCU readers

Local FDB entries can be rewritten in place by fdbdeletelocal(), which updates f->dst to another port or to NULL while keeping the entry alive. Several bridge RCU readers inspect f->dst, including brfdbfillbuf() through the brforwardread() sysfs path.

These readers currently load f->dst multiple times and can therefore observe inconsistent values across the check and later dereference. In brfdbfillbuf(), this means a concurrent local-FDB update can change f->dst after the NULL check and before the portno dereference, leading to a NULL-ptr-deref.

Fix this by taking a single READONCE() snapshot of f->dst in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place f->dst updates in fdbdeletelocal() with WRITEONCE() so the readers and writer use matching access patterns.