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:

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:

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:

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:

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

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

HID: appletb-kbd: fix UAF in inactivity-timer cleanup path

Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletbkbdprobe") added timerdeletesync(&kbd->inactivitytimer) to both the probe closehw error path and appletbkbdremove(), but the way it was wired in left the inactivity timer reachable during driver tear-down via two distinct windows.

Window A -- putdevice() before timerdeletesync():

putdevice(&kbd->backlightdev->dev); timerdeletesync(&kbd->inactivitytimer);

The inactivitytimer softirq reads kbd->backlightdev and calls backlightdevicesetbrightness() -> mutexlock(&opslock). If a concurrent hidappletbbl unbind drops the last devm reference between these two calls, the backlightdevice is freed and the mutexlock() touches freed memory.

Window B -- backlight cleanup before hidhwstop():

if (kbd->backlightdev) { timerdeletesync(...); putdevice(...); } hidhwclose(hdev); hidhwstop(hdev);

Even after Window A is closed, hidhwclose()/hidhwstop() still run afterwards, so a late ".event" callback from the HID core (USB URB completion on real Apple hardware) can arrive after timerdeletesync() drained the softirq but before putdevice() drops the reference. That callback reaches resetinactivitytimer(), which calls modtimer() and re-arms the timer. The freshly re-armed timer can then fire on the about-to-be-freed backlightdevice.

Both windows produce the same KASAN slab-use-after-free:

BUG: KASAN: slab-use-after-free in mutexlock+0x1aab/0x21c0 Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0 Call Trace: <IRQ> mutexlock backlightdevicesetbrightness appletbinactivitytimer calltimerfn runtimersoftirq handlesoftirqs Allocated by task N: devmbacklightdeviceregister appletbblprobe Freed by task M: (concurrent hidappletbbl unbind path)

Close both windows at once by reworking the tear-down in appletbkbdremove() and in the probe closehw error path so that

1) hidhwclose()/hidhwstop() run before the backlight cleanup, guaranteeing no further .event callback can fire and re-arm the timer, and 2) inside the "if (kbd->backlightdev)" block, timerdeletesync() runs before putdevice(), so the softirq is drained before the final reference is dropped.

btrfs: fix double free in createspaceinfosubgroup() error path

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

mm/damon/sysfs-schemes: protect memcgpath kfree() with damonsysfslock

Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg]path".

Reads of 'memcgpath' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those.

This patch (of 2):

damonsysfsschemefilter->mmecgpath can be read and written by users, via DAMON sysfs memcgpath file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damonsysfslock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcgpath-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damonsysfslock.

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:

mm/damon/core: validate damosquotagoal->nid for nodemem{used,free}bp

Patch series "mm/damon/core: validate damosquotagoal->nid".

nodemem[cg]{used,free}bp DAMOS quota goals receive the node id. The node id is used for simeminfonode() and NODEDATA() without proper validation. As a result, privileged users can trigger an out of bounds memory access using DAMONSYSFS. Fix the issues.

The issue was originally reported [1] with a fix by another author. The original author announced [2] that they will stop working including the fix that was still in the review stage. Hence I'm restarting this.

This patch (of 2):

Users can set damosquotagoal->nid with arbitrary value for nodemem{used,free}bp. But DAMON core is using those for simeminfonode() without the validation of the value. This can result in out of bounds memory access. The issue can actually triggered using DAMON user-space tool (damo), like below.

$ sudo ./damo start --damosaction stat \ --damosquotagoal nodememusedbp 50% -1 \ --damosquotainterval 1s $ sudo dmesg [...] [ 65.565986] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098

Fix this issue by adding the validation of the given node. If an invalid node id is given, it returns 0% for used memory ratio, and 100% for free memory ratio.

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.

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

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

ovpn: tcp - fix packet extraction from stream

When processing TCP stream data in ovpntcprecv, we receive large cloned skbs from strprcv that may contain multiple coalesced packets. The current implementation has two bugs:

1. Header offset overflow: Using pskbpull with large offsets on coalesced skbs causes skb->data - skb->head to exceed the u16 storage of skb->networkheader. This causes skbresetnetworkheader to fail on the inner decapsulated packet, resulting in packet drops.

2. Unaligned protocol headers: Extracting packets from arbitrary positions within the coalesced TCP stream provides no alignment guarantees for the packet data causing performance penalties on architectures without efficient unaligned access. Additionally, openvpn's 2-byte length prefix on TCP packets causes the subsequent 4-byte opcode and packet ID fields to be inherently misaligned.

Fix both issues by allocating a new skb for each openvpn packet and using skbcopybits to extract only the packet content into the new buffer, skipping the 2-byte length prefix. Also, check the length before invoking the function that performs the allocation to avoid creating an invalid skb.

If the packet has to be forwarded to userspace the 2-byte prefix can be pushed to the head safely, without misalignment.

As a side effect, this approach also avoids the expensive linearization that pskbpull triggers on cloned skbs with page fragments. In testing, this resulted in TCP throughput improvements of up to 74%.

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

drm/amdgpu: validate user queue size constraints

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

scsi: target: file: Use kzallocflex for aiocmd

The targetcorefile doesn't initialize the aiocmd->iocb for the kiwritestream. When a write command fdexecuterwaio() is executed, we may get a bogus kiwritestream value, causing unintended write failure status when checking iocb->kiwritestream > maxwritestreams in the block device.

Let's just use kzallocflex when allocating the aiocmd and let kiwritestream=0 to fix this issue.

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

perf/x86: Fix potential bad containerof in intelpmuhwconfig

Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86hybridpmu and a containerof operation in intelpmusetacrcausedconstr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intelpmusetacrcausedconstr with an isx86event check.

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

drm/amdgpu: validate doorbelloffset in user queue creation

amdgpuuserqgetdoorbellindex() passes the user-provided doorbelloffset to amdgpudoorbellindexonbar() without bounds checking. An arbitrarily large doorbelloffset can cause the calculated doorbell index to fall outside the allocated doorbell BO, potentially corrupting kernel doorbell space.

Validate that doorbelloffset falls within the doorbell BO before computing the BAR index, using u64 arithmetic to prevent overflow.

(cherry picked from commit de1ef4ffd70e1d15f0bf584fd22b1f28cbd5e2ec)

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.

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

rxrpc: Fix use of wrong skb when comparing queued RESP challenge serial

In rxrpcpostresponse(), the code should be comparing the challenge serial number from the cached response before deciding to switch to a newer response, but looks at the newer packet private data instead, rendering the comparison always false.

Fix this by switching to look at the older packet.

Fix further[1] to substitute the new packet in place of the old one if newer and also to release whichever we don't use.

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

rxrpc: fix oversized RESPONSE authenticator length check

rxgkverifyresponse() decodes authlen from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgkdecryptskb(), which can later reach skbtosgvec() with an impossible length and hit BUGON(len).

Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:

RIP: skbtosgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skbtosgvec() [net/core/skbuff.c:5305] rxgkdecryptskb() [net/rxrpc/rxgkcommon.h:81] rxgkverifyresponse() [net/rxrpc/rxgk.c:1268] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]

Reject authenticator lengths that exceed the remaining packet payload.

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

rxrpc: Fix buffer overread in rxgkdoverifyauthenticator()

Fix rxgkdoverifyauthenticator() to check the buffer size before checking the nonce.

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

tracing: Fix tracemarker copy link list updates

When the "copytracemarker" option is enabled for an instance, anything written into /sys/kernel/tracing/tracemarker is also copied into that instances buffer. When the option is set, that instance's tracearray descriptor is added to the markercopies link list. This list is protected by RCU, as all iterations uses an RCU protected list traversal.

When the instance is deleted, all the flags that were enabled are cleared. This also clears the copytracemarker flag and removes the tracearray descriptor from the list.

The issue is after the flags are called, a direct call to updatemarkertrace() is performed to clear the flag. This function returns true if the state of the flag changed and false otherwise. If it returns true here, synchronizercu() is called to make sure all readers see that its removed from the list.

But since the flag was already cleared, the state does not change and the synchronization is never called, leaving a possible UAF bug.

Move the clearing of all flags below the updating of the copytracemarker option which then makes sure the synchronization is performed.

Also use the flag for checking the state in updatemarkertrace() instead of looking at if the list is empty.

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

mm/hugememory: fix use of NULL folio in movepageshugepmd()

movepageshugepmd() handles UFFDIOMOVE for both normal THPs and huge zero pages. For the huge zero page path, srcfolio is explicitly set to NULL, and is used as a sentinel to skip folio operations like lock and rmap.

In the huge zero page branch, srcfolio is NULL, so foliomkpmd(NULL, pgprot) passes NULL through foliopfn() and pagetopfn(). With SPARSEMEMVMEMMAP this silently produces a bogus PFN, installing a PMD pointing to non-existent physical memory. On other memory models it is a NULL dereference.

Use pagefolio(srcpage) to obtain the valid huge zero folio from the page, which was obtained from pmdpage() and remains valid throughout.

After commit d82d09e48219 ("mm/hugememory: mark PMD mappings of the huge zero folio special"), moved huge zero PMDs must remain special so vmnormalpagepmd() continues to treat them as special mappings.

movepageshugepmd() currently reconstructs the destination PMD in the huge zero page branch, which drops PMD state such as pmdspecial() on architectures with CONFIGARCHHASPTESPECIAL. As a result, vmnormalpagepmd() can treat the moved huge zero PMD as a normal page and corrupt its refcount.

Instead of reconstructing the PMD from the folio, derive the destination entry from srcpmdval after pmdphugeclearflush(), then handle the PMD metadata the same way movehugepmd() does for moved entries by marking it soft-dirty and clearing uffd-wp.

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().