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

wifi: mt76: mt7921: validate CLC firmware records

The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying.

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

nvdimm: pmem: keep PREFLUSH before data writes

pmemsubmitbio() records a REQPREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQFUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier.

Run the REQPREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQFUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.

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

pppasync: drop the errored frame instead of resetting its headroom

pppreceivenonmpframe() prepends a two-byte direction tag before running the pass/active BPF filters:

(be16 )skbpush(skb, 2) = htons(PPPFILTERINBOUNDTAG);

Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in pppasync's processinputpacket() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from devallocskb() carries NETSKBPAD:

err: if (skb) { / make skb appear as freshly allocated / skbtrim(skb, 0); skbreserve(skb, - skbheadroom(skb)); }

ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head:

skbuff: skbunderpanic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x13e/0x230 Call Trace: skbpush+0xbd/0x100 pppreceivenonmpframe+0x48a/0x1d10 pppinput+0x4e9/0x2f80 pppasyncprocess+0x2a/0xe0 taskletactioncommon+0x20f/0x8a0 handlesoftirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt

Zeroing the headroom violates the NETSKBPAD guarantee that devallocskb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled pppdecompressframe() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason.

Rather than restore the headroom, drop the errored frame - as pppsynctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read.

The original V1 of this patch made room in pppreceivenonmpframe() with skbcowhead(); Eric pointed out that fixing the root cause in the transport is the right approach.

Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.

EDAC/devicesysfs: Use kstrtouint() for pollmsec to prevent truncation

accel/qaic: Address potential out-of-bounds read in respworker()

drm/cirrus-qemu: Validate BAR0 size during probe

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

nvme-rdma: fix -EIO cleanup order in queuerq

On -EIO, the RDMA queuerq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete.

Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.

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

sctp: fix a TOCTOU race in SCTPCMDTIMERSTART

The SCTPCMDTIMERSTART handler checks timerpending() before calling timerreduce(). The timer can expire and detach between these operations, causing timerreduce() to rearm the timer without taking the association reference required for the newly armed timer.

The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown.

Use the return value of timerreduce() to determine whether the timer was actually armed. Take the association reference only when timerreduce() successfully starts a new timer, closing the race between checking the timer state and rearming it.

This issue was reported by Nico Yip (@cyeaa) working with TrendAI Zero Day Initiative.

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

scsi: mpi3mr: Fix target device refcount leak in mpi3mrsasportadd()

mpi3mrgettgtdevbyaddr() increments the target device kref when it returns a device. If a subsequent error triggers a goto outfail after the tgtdev reference is acquired, the reference is never released because the outfail path does not call mpi3mrtgtdevput(). This prevents the target device structure from ever being freed.

Add a tgtdev put in the outfail path, guarded by a NULL check since tgtdev is only acquired for SASENDDEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL.

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

scsi: mpi3mr: Fix NULL pointer dereference in mpi3mrsasportadd()

sasportallocnum() can return NULL on memory allocation failure. The return value is passed directly to sasportadd() without a NULL check, which causes a NULL pointer dereference.

Additionally, if sasportadd() fails, the allocated port is not freed before jumping to outfail, leaking the sasport structure. Call sasportfree() to properly release it.

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

sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration

sctpverifyasconf() walks ASCONF-ACK parameters with sctpwalkparams(), which advances by SCTPPAD4(length), while the consumer sctpgetasconfresponse() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset.

When those bytes yield a length of zero, the while loop over asconfacklen makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help).

The SCTPPARAMERRCAUSE case of sctpverifyasconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read.

Reject SCTPPARAMERRCAUSE parameters shorter than sizeof(struct sctpaddipparam) + sizeof(struct sctperrhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERRCAUSE parameter the consumer can see, so the consumer's asconfacklen check is dropped and it returns errparam->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTPPARAMERRCAUSE per RFC 5061.

The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.

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

vxlan: mdb: Fix use-after-free in vxlanmdbremotesrcdel()

vxlanmdbisvalidsource(), which validates MDBEATTRSOURCE and every MDBEATTRSRCLIST member, accepts the all-zeros address.

A source list is only accepted on a (, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlanmdbentrykey, so if MDBEATTRSOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (, G) key and resolves to the same entry. Omitting MDBEATTRSOURCE is not equivalent, as the key is then left with a zero address family.

vxlanmdbremotesrcdel() removes the forwarding entry of a source before freeing the source entry:

vxlanmdbremotesrcfwddel(vxlan, group, remote, &ent->addr); vxlanmdbremotesrcentrydel(ent);

With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlistdel() reads ->pprev and ->next out of it and writes through them.

Adding the (, G) entry with NLMFREPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlanmdbremotesrcsreplace().

BUG: KASAN: slab-use-after-free in vxlanmdbadd+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 vxlanmdbadd+0x1cd/0xd70 vxlanmdbadd+0xc0/0x140 rtnlmdbadd+0x157/0x2a0 rtnetlinkrcvmsg+0x207/0x5a0 Allocated by task 84: kmalloccachenoprof+0x153/0x360 vxlanmdbremotesrcsadd+0x2eb/0x440 vxlanmdbadd+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlanmdbremotedel+0x129/0x1a0 vxlanmdbdel+0x4f/0xe0 vxlanmdbremotesrcfwddel.isra.0+0x162/0x1b0 vxlanmdbadd+0x1c5/0xd70

The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace.

Reject the all-zeros address in vxlanmdbisvalidsource(), which covers both call sites. A (, G) entry is expressed by omitting the source, so nothing legitimate is refused.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF

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

ksmbd: rate limit unmapped SID errors

A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages.

Rate limit the message to prevent an authenticated client from flooding the kernel log.

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

watchdog: msc313e: Fix NULL pointer dereference in PM callbacks

msc313ewdtprobe() doesn't set the driver data for the platform device. As a result, devgetdrvdata() in msc313ewdtsuspend() and msc313ewdtresume() will return NULL, leading to a NULL pointer dereference afterward.

Set the platform device driver data in msc313ewdtprobe().

Bluetooth: btintel: validate version TLV value lengths

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

tipc: fix NULL deref in tipcnamednodeup() on empty publication list

User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPCMAXPUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues:

1. User-space applications subscribing to node or link up/down events stop receiving notifications.

2. A NULL pointer dereference can occur:

BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipcnamednodeup (./include/linux/skbuff.h:2251 net/tipc/namedistr.c:195 net/tipc/namedistr.c:221) ... Call Trace: <IRQ> tipcnodewriteunlock (net/tipc/node.c:428) tipcrcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipcudprecv (net/tipc/udpmedia.c:389)

Thread 1 (tipcnetfinalize) | Thread 2 (nameddistribute) -----------------------------|----------------------------- | ... | listforeachentry(publ, pls, bindingnode) { | ... | skbqueuetail(list, skb); | ... | } | ... | hdr = bufmsg(skbpeektail(list)); ... | tipcnametblpublish(); |

If 'tipcnametblpublish()' (Thread 1) fails because the number of local publications reaches TIPCMAXPUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'bufmsg()', leading to a NULL pointer dereference.

Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPCMAXPUBL - 1). This ensures that the maximum bulk size calculated in tipclinksetqueuelimits() remains valid.

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

ipv6: mcast: fix RCU list diversion in ip6mcdel1src()

When removing a source filter whose count reaches zero, ip6mcdel1src() unlinks psf from pmc->mcasources. If the filter was previously active, the code moved psf directly into pmc->mcatomb by updating psf->sfnext.

Because pmc->mcasources is traversed locklessly under RCU (e.g. by ipv6chkmcastaddr()), mutating psf->sfnext before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mcasources and improperly examine deleted tombstone entries.

Fix this by allocating a new tombstone node for pmc->mcatomb (as done in sfsetstate()) and retiring the original psf via kfreercu().

Bluetooth: L2CAP: fix chan mode for LECONNREQ + EXTFLOWCTL pchan

Bluetooth: hcicore: Fix race condition during device registration

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

net/sched: clsu32: fix duplicate handle when node ID pool is exhausted

gennewkid() falls back to returning max (htid | 0xFFF) when both idrallocu32() ranges are full, instead of reporting an error. u32change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space.

The handle was never reserved in ht->handleidr, so every later error path that does idrremove(&ht->handleidr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates.

The 4095 limit is per (table, bucket) — ht->handleidr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 2564095 knodes.

The sibling helper gennewhtid() has the same silent in-band failure: it returns 0 when the tpc handle pool (1..0x7FF) is full, and u32init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32lookupht(), allowing cross-tcfproto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has.

Return an error so u32change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM).

Conditions to recreate the bug: - CONFIGNETSCHED=y, CONFIGCLSU32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAPNETADMIN). - For gennewhtid: create 2047 u32 proto entries on the same block to fill the tpc handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables.

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

ipv6: mcast: use copy-on-write RCU updates in ip6mcsource()

pmc->sflist is read locklessly under rcureadlock() by inet6mccheck() during packet reception in the UDP and RAW multicast receive paths.

ip6mcsource() mutated psl->sladdr and psl->slcount in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcuassignpointer() before writing the new source into the array.

Because 16-byte struct in6addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6mccheck() could read torn IPv6 addresses or observe duplicated/missed source entries.

Fix this by switching ip6mcsource() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcuassignpointer(), and reclaim the old filter via kfreercu(), matching ip6mcmsfilter().

Also remove the now unused IP6SFBLOCK macro.

ASoC: amd: yc: fix memory leak in acp6xpdmdmaclose()

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

ipv6: sr: restore network header before routing and forwarding

ipv6srhrcv() runs with skb->data at the Segment Routing Header (SRH) while skbnetworkheader() points at the IPv6 header.

When segmentsleft > 0, ipv6srhrcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skbnetworkoffset() remained negative.

This led to two problems: 1. During ip6routeinput(), fib6rulesearlyflowdissect() invokes skbflowdissect() which passes the negative skbnetworkoffset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6forward() or redirected via actmirred, downstream handlers (like schfragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows.

Fix this by pushing -skbnetworkoffset(skb) before routing, ensuring skbnetworkoffset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skbtransportoffset(skb) to restore skb->data to the SRH before looping back.

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

staging: fbtft: make dirtylock IRQ-safe

fbtftmkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirtylock is also taken by fbtftdeferredio() in workqueue context with local interrupts enabled.

Lockdep reports a possible IRQ lock inversion involving dirtylock and consoleowner. A hardirq can interrupt a CPU holding dirtylock and enter the console rendering path, which can attempt to acquire dirtylock again.

The following lockdep report was observed on an RK3566 system with CONFIGPROVELOCKING enabled:

WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (consoleowner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirtylock){+.+.}-{2:2}

CPU0 CPU1 ---- ---- lock(&par->dirtylock); localirqdisable(); lock(consoleowner); lock(&par->dirtylock); <Interrupt> lock(consoleowner);

DEADLOCK

Use spinlockirqsave() for fbtftmkdirty() and spinlockirq() for fbtftdeferredio(). They only access the dirty line range, so the IRQ-off regions remain short.

afpacket: Don't cast tpackethdr.tplen to int in tpacketparseheader().

ALSA: ump: do not touch legacyrmidi before it exists

btrfs: fix transaction use-after-free in raid stripe insertion

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

scsi: mpt3sas: Avoid out-of-bounds cpumaskofnode() call in baseassignreplyqueues()

devtonode() can return NUMANONODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumaskofnode() indexes nodetocpumaskmap[-1], an out-of-bounds array read caught by UBSAN:

UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [1024]'

Fall back to cpuonlinemask when no NUMA node is available, rather than assuming devtonode() always returns a valid node index.

btrfs: restore active device pointers after failed sprout