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

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

eventpoll: Fix semi-unbounded recursion

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

ovpn: respect peer refcount in CMDNEWPEER error path

ovpnnlpeernewdoit()'s error path calls ovpnpeerrelease() directly rather than ovpnpeerput(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP.

For UDP, the ovpnsocket union uses the .ovpn arm and never points back at a peer; UDP encaprecv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpnpeeradd() publishes it.

For TCP, ovpnsocketnew() sets ovpnsock->peer and ovpntcpsocketattach() publishes ovpnsock via rcuassignskuserdata(). From that moment until ovpnsocketrelease() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpntcprcv() path, can reach the peer through skuserdata -> ovpnsock->peer and bump its refcount via ovpnpeerhold().

ovpntcpsocketwaitfinish() (called inside ovpnsocketrelease()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpnnlpeermodify() or ovpnpeeradd() returns an error while such a caller is in flight - notably an ovpntcprecvmsg() blocked in skbrecvdatagram() on peer->tcp.userqueue - the direct ovpnpeerrelease() destroys the peer while the caller still holds the reference, and the eventual ovpnpeerput() from that caller operates on freed memory.

Replace the direct destructor call with ovpnpeerput() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpnpeerreleasekref() runs the same destructor.

With this conversion ovpnpeerrelease() has no callers outside peer.c - ovpnpeerreleasekref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h.

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

ovpn: tcp - use cached peer pointer in ovpntcpclose()

ovpntcpclose() loads the ovpnsocket via rcudereferenceskuserdata() under rcureadlock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpnpeerdel(), re-dereferencing the ovpnsocket after the RCU read section has ended.

Unlike ovpntcpsendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by locksock() held across the function, ovpntcpclose() runs without the socket lock: inetrelease() invokes skprot->close() without taking locksock first.

ovpnsocketrelease() can therefore complete its krefput -> detach -> synchronizercu -> kfree(sock) sequence concurrently, in the window after ovpntcpclose() drops rcureadlock() but before it dereferences sock->peer. The synchronizercu() in ovpnsocketrelease() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards.

A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sksocket member after tcpclose()"): trigger a peer removal (keepalive expiration or netlink OVPNCMDDELPEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim.

Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpnpeerdel() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpnsocketnew() under locksock(), before rcuassignskuserdata() publishes the ovpnsocket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpntcprecvmsg(), ovpntcpsendmsg(), ovpntcpdataready() and ovpntcpwritespace(); those will be cleaned up via a dedicated helper in a follow-up net-next series.

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

NFS: Fix filehandle bounds checking in nfsfhtodentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

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

tls: handle data disappearing from under the TLS ULP

TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARNON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry.

We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len).

If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place.

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

media: venus: Fix OOB read due to missing payload bound check

Currently, The eventseqchanged() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length.

This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed.

Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed.

This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior.

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

rxrpc: Fix RxGK token loading to check bounds

rxrpcpreparsexdryfsrxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through roundup(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, roundup() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged addkey() call.

Fix this by:

(1) Rejecting raw key lengths above AFSTOKENGKKEYMAX and raw ticket lengths above AFSTOKENGKTOKENMAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKENRKTIXMAX.

(2) Sizing the flexible-array allocation from the validated raw key length via structsizet() instead of the rounded value.

(3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse.

The control path (valid token with lengths within bounds) is unaffected.

drm/amdgpu: Refactor amdgpugemvaioctl for Handling Last Fence Update and Timeline Management v4

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

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the fields in the descriptor.

btrfs: qgroup: fix race between quota disable and quota rescan ioctl

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

net/mlx5e: Remove skb secpath if xfrm state is not found

Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.

Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.

Subsequently, functions like xfrmpolicycheck() attempt to access fields such as xfrminputstate(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.

This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.

BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7forupstreammindebug202505272244 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:xfrmpolicycheck+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? trytowakeup+0x108/0x4c0 ? udp4liblookup2+0xbe/0x150 ? udpliblportinuse+0x100/0x100 ? udp4liblookup+0x2b0/0x410 xfrmpolicycheck2.constprop.0+0x11e/0x130 udpqueuercvoneskb+0x1d/0x530 udpunicastrcvskb+0x76/0x90 udp4librcv+0xa64/0xe90 ipprotocoldeliverrcu+0x20/0x130 iplocaldeliverfinish+0x75/0xa0 iplocaldeliver+0xc1/0xd0 ? ipprotocoldeliverrcu+0x130/0x130 ipsublistrcv+0x1f9/0x240 ? iprcvfinishcore+0x430/0x430 iplistrcv+0xfc/0x130 netifreceiveskblistcore+0x181/0x1e0 netifreceiveskblistinternal+0x200/0x360 ? mlx5ebuildrxskb+0x1bc/0xda0 [mlx5core] groreceiveskb+0xfd/0x210 mlx5ehandlerxcqempwrq+0x141/0x280 [mlx5core] mlx5epollrxcq+0xcc/0x8e0 [mlx5core] ? mlx5ehandlerxdim+0x91/0xd0 [mlx5core] mlx5enapipoll+0x114/0xab0 [mlx5core] napipoll+0x25/0x170 netrxaction+0x32d/0x3a0 ? mlx5eqcompint+0x8d/0x280 [mlx5core] ? notifiercallchain+0x33/0xa0 handlesoftirqs+0xda/0x250 irqexitrcu+0x6d/0xc0 commoninterrupt+0x81/0xa0 </IRQ>

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

rcu: Fix rcureadunlock() deadloop due to IRQ work

During rcureadunlockspecial(), if this happens during irqexit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irqexit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on the tracetickstop() tracepoint As shown in the trace below. Fix by managing the irqwork state correctly.

irqexit() irqexitrcu() / inhardirq() returns false after this / preemptcountsub(HARDIRQOFFSET) tickirqexit() ticknohzirqexit() ticknohzstopschedtick() tracetickstop() / a bpf prog is hooked on this trace point / bpftracetickstop() bpftracerun2() rcureadunlockspecial() / will send a IPI to itself / irqworkqueueon(&rdp->deferqsiw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in tickirqexit(). It will hang on boot without the patch:

static inline void tickirqexit(void) { + rcureadlock(); + WRITEONCE(current->rcureadunlockspecial.b.needqs, true); + rcureadunlock(); +

[neeraj: Apply Frederic's suggested fix for PREEMPTRT]

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

xfrm: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRMMSGALLOCSPI Netlink message, which triggers the kernel function xfrmallocspi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spimin = 0x10000000 spimax = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.

Current implementation: xfrmspihash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlistforeachentryrcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI

Proposed Change: xfrmstatelookupspiproto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.

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

net: devmem: reject dma-buf bind with non-page-aligned size or SG length

netdevmembinddmabuf() trusts dmabuf->size and sgdmalen() to be PAGESIZE multiples without checking:

- txvec is sized dmabuf->size / PAGESIZE, and netdevmemgetniovat() only bounds-checks virtaddr < dmabuf->size before indexing txvec[virtaddr / PAGESIZE]. With size = NPAGESIZE + r (1 <= r < PAGESIZE), sendmsg() at iovbase = NPAGESIZE passes the bound check and reads txvec[N] -- one past.

- owner->area.numniovs = len / PAGESIZE while genpooladdowner() covers the full byte len, so a non-page-multiple non-final sg desyncs numniovs from the genpool region for every later sg, on both RX and TX.

dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL.

The size check is TX-only (only txvec is sized off dmabuf->size); the SG-length check covers both directions.

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

mm: swap: fix potential buffer overflow in setupclusters()

In setupswapmap(), we only ensure badpages are in range (0, lastpage]. As maxpages might be < lastpage, setupclusters() will encounter a buffer overflow when a badpage is >= maxpages.

Only call incclusterinfopage() for badpage which is < maxpages to fix the issue.

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

crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks

Change the krb5 crypto library to provide facilities to precheck the length of the message about to be decrypted or verified.

Fix AFRXRPC to make use of this to validate DATA packets secured with RxGK.

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

futex: Fix UaF between futexkeytonodeopt() and vmareplacepolicy()

During futexkeytonodeopt() execution, vma->vmpolicy is read under speculative mmap lock and RCU. Concurrently, mbind() may call vmareplacepolicy() which frees the old mempolicy immediately via kmemcachefree().

This creates a race where futexkeytonode() dereferences a freed mempolicy pointer, causing a use-after-free read of mpol->mode.

[ 151.412631] BUG: KASAN: slab-use-after-free in futexkeytonode (kernel/futex/core.c:349) [ 151.414046] Read of size 2 at addr ffff888001c49634 by task e/87

[ 151.415969] Call Trace:

[ 151.416732] asanload2 (mm/kasan/generic.c:271) [ 151.416777] futexkeytonode (kernel/futex/core.c:349) [ 151.416822] getfutexkey (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593)

Fix by adding rcu to mpolput().

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

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in getblkslow() due to requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.

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

wifi: cfg80211: Add missing lock in cfg80211checkandendcac()

Callers of wdevchandef() must hold the wiphy mutex.

But the worker cfg80211propagatecacdonewk() never takes the lock. Which triggers the warning below with the meshpeerconnecteddfs test from hostapd and not (yet) released mac80211 code changes:

WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdevchandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211propagatecacdonewk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? printk+0x0/0x98 [<6003c2b3>] showstack+0x10e/0x11a [<6002ec30>] ? printk+0x0/0x98 [<60037608>] dumpstacklvl+0x71/0xb8 [<6063717b>] ? wdevchandef+0x60/0x165 [<6003766d>] dumpstack+0x1e/0x20 [<6005d1b7>] warn+0x101/0x20f [<6005d3a8>] warnslowpathfmt+0xe3/0x15d [<600b0c5c>] ? marklock.part.0+0x0/0x4ec [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<600b11a2>] ? markheldlocks+0x5a/0x6e [<6005d2c5>] ? warnslowpathfmt+0x0/0x15d [<60052e53>] ? unblocksignals+0x3a/0xe7 [<60052f2d>] ? umsetsignals+0x2d/0x43 [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<607508b2>] ? lockisheldtype+0x207/0x21f [<6063717b>] wdevchandef+0x60/0x165 [<605f89b4>] regulatorypropagatedfsstate+0x247/0x43f [<60052f00>] ? umsetsignals+0x0/0x43 [<605e6bfd>] cfg80211propagatecacdonewk+0x3a/0x4a [<6007e460>] processscheduledworks+0x3bc/0x60e [<6007d0ec>] ? movelinkedworks+0x4d/0x81 [<6007d120>] ? assignwork+0x0/0xaa [<6007f81f>] workerthread+0x220/0x2dc [<600786ef>] ? setpfworker+0x0/0x57 [<60087c96>] ? tokthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? workerthread+0x0/0x2dc [<6006c05b>] ? calculatesigpending+0x0/0x56 [<6003b37d>] newthreadhandler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] upconsolesem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] upconsolesem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] ieee80211wakequeue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] ieee80211wakequeue+0x643/0x985

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

net: enetc: fix NTMP DMA use-after-free issue

The AI-generated review reported a potential DMA use-after-free issue [1]. If netcxmitntmpcmd() times out and returns an error, the pending command is not explicitly aborted, while ntmpfreedatamem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer.

To resolve this issue, this patch does the following modifications:

1. Convert cbdr->ringlock from a spinlock to a mutex

The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dmafreecoherent() might sleep.

2. Introduce software command BD (struct netcswcbd)

The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size. And netcxmitntmpcmd() only reclaims older BDs when the number of used BDs reaches NETCCBDRCLEANWORK (16). The software BD enables correct DMA memory release. With this, struct ntmpdmabuf and ntmpfreedatamem() are no longer needed and are removed.

3. Require callers to hold ringlock across netcxmitntmpcmd()

netcxmitntmpcmd() releases the ringlock before the caller finishes consuming the response. At this point, if a concurrent thread submits a new command, it may trigger ntmpcleancbdr() and free the DMA buffer while it is still in use. Move ringlock ownership to the caller to ensure the response buffer cannot be reclaimed prematurely. So the helpers ntmpselectandlockcbdr() and ntmpunlockcbdr() are added.

These changes eliminate the DMA use-after-free condition and ensure safe and consistent BD reclamation and DMA buffer lifecycle management.

Bluetooth: hcisync: reject oversized Broadcast Announcement prepend

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

memcg: use round-robin victim selection in refillstock

Harry Yoo reported that getrandomu32below() is not safe to call in the nmi context and memcg charge draining can happen in nmi context.

More specifically getrandomu32below() is neither reentrant- nor NMI-safe: it acquires a per-cpu locallock via locallockirqsave() on the batchedentropyu32 state. An NMI that lands on a CPU mid-update of the ChaCha batch state and recurses into the random subsystem would corrupt that state. The memcgstock localtrylock prevents re-entry on the percpu stock itself, but cannot protect an unrelated subsystem's per-cpu lock.

Replace the random pick with a per-cpu round-robin counter stored in memcgstockpcp and serialized by the same localtrylock that already guards cached[] and nrpages[]. No atomics, no random calls, no extra locks needed.

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

drm/amdgpu/userq: fix access to stale wptr mapping

Use drmexec to take both locks i.e vm root bo and wptrobj bo to access the mapping data properly.

This fixes the security issue of unmap the wptrobj while a queue creation is in progress and passing other bo at same address.

(cherry picked from commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c)

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

wifi: ath12k: do WoW offloads only on primary link

In case of multi-link connection, WCN7850 firmware crashes due to WoW offloads enabled on both primary and secondary links.

Change to do it only on primary link to fix it.

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

btrfs: fix double free in createspaceinfosubgroup() error path

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

crypto: acomp - fix wrong pointer stored by acompsavereq()

acompsavereq() stores &req->chain in req->base.data. When acompreqchaindone() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acompreq. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption.

The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomprequestsetsrcdma()). This combination causes cryptoacompcompress() to enter the acompdoreqchain() path, which sets acompreqchaindone() as the completion callback via acompsavereq().

With KASAN enabled, this manifests as a general protection fault in acompreqchaindone():

general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acompreqchaindone+0x15b/0x4e0 Call Trace: <IRQ> qatcompalgcallback+0x5d/0xa0 [intelqat] adfringresponsehandler+0x376/0x8b0 [intelqat] adfresponsehandler+0x60/0x170 [intelqat] taskletactioncommon+0x223/0x820 handlesoftirqs+0x1ab/0x640 </IRQ>

Fix this by storing the request itself in req->base.data instead of &req->chain, so that acompreqchaindone() receives the correct pointer. Simplify acomprestorereq() accordingly to access req->chain directly.

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

ovpn: fix possible use-after-free in ovpnnetxmit

When building the skblist in ovpnnetxmit, skbsharecheck will free the original skb if it is shared. The current implementation continues to use the stale skb pointer for subsequent operations: - peer lookup, - skbdstdrop (even though all segments produced by skbgsosegment will have a dst attached), - ovpnpeerstatsincrementtx.

Fix this by moving the peer lookup and skbdstdrop before segmentation so that the original skb is still valid when used. Return early if all segments fail skbsharecheck and the list ends up empty. Also switch ovpnpeerstatsincrementtx to use skblist.next; the next patch fixes the stats logic.

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

netfilter: nftables: Fix for duplicate device in netdev hooks

When handling NETDEVREGISTER notification, duplicate device registration must be avoided since the device may have been added by nftnetdevhookalloc() already when creating the hook.