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

pwrseq: core: fix use-after-free in pwrseqdebugfsseqnext()

pwrseqdebugfsseqnext() declares 'next' with free(putdevice), which causes putdevice() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seqfile framework receives a pointer whose reference has already been dropped.

Simply removing free(putdevice) would fix the UAF but would leak the reference acquired by busfindnextdevice(), as stop() only calls upread(&pwrseqsem) and never releases the device reference.

Fix this by making the reference counting consistent across all seqfile callbacks, matching the standard pattern used by PCI and SCSI:

- start(): use getdevice() so it returns a referenced pointer. - next(): explicitly putdevice(curr) to release the previous device's reference (no NULL check needed - the seqfile framework only calls next() while the previous return was non-NULL). - stop(): putdevice(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.

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

block: don't overwrite bipvcnt in biointegritycopyuser()

biointegrityaddpage() already sets bipvcnt to 1 for the bounce segment. Overwriting it with nrvecs breaks bipvcnt <= bipmaxvcnt on WRITE (bipmaxvcnt is 1), so the gap-merge checks in block/blk.h read past the bipvec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce.

The line was added for split propagation, but biointegrityclone() doesn't copy bipvcnt and BIPCLONEFLAGS excludes BIPCOPYUSER.

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

accel/ivpu: Add buffer overflow check in MS getinfoioctl

Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy.

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

KVM: arm64: Reassign nestedmmus array behind mmulock

kvm->arch.nestedmmus[] is walked under kvm->mmulock, including from the MMU notifier path (kvmunmapgfnrange() -> kvmnesteds2unmap()), which can run at any time. kvmvcpuinitnested() reallocates the array and frees the old buffer while holding only kvm->arch.configlock, so such a walker can reference the freed array.

Allocate the new array outside of mmulock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well.

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

Bluetooth: btmtk: validate WMT event SKB length before struct access

btmtkusbhciwmtsync() casts the WMT event response SKB data to struct btmtkhciwmtevt (7 bytes) and struct btmtkhciwmtevtfuncc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom.

Use skbpulldata() to validate and advance past the base WMT event header. For the FUNCCTRL case, pull the additional status field bytes before accessing them.

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

fs/ntfs3: Initialize new folios before use

KMSAN reports an uninitialized value in longestmatchstd(), invoked from ntfscompresswrite(). When new folios are allocated without being marked uptodate and nireadframe() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized.

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

bpf: Preserve id of register in synclinkedregs()

synclinkedregs() copies the id of knownreg to reg when propagating bounds of knownreg to reg using the off of knownreg, but when knownreg was linked to reg like:

knownreg = reg ; both knownreg and reg get same id knownreg += 4 ; knownreg gets off = 4, and its id gets BPFADDCONST

now when a call to synclinkedregs() happens, let's say with the following:

if knownreg >= 10 goto pc+2

knownreg's new bounds are propagated to reg but now reg gets BPFADDCONST from the copy.

This means if another link to reg is created like:

anotherreg = reg ; anotherreg should get the id of reg but assignscalaridbeforemov() sees BPFADDCONST on reg and assigns a new id to it.

As reg has a new id now, knownreg's link to reg is broken. If we find new bounds for knownreg, they will not be propagated to reg.

This can be seen in the selftest added in the next commit:

0: (85) call bpfgetprandomu32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,varoff=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero

When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPFADDCONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken.

After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero.

Fix this by preserving id in synclinkedregs() like off and subregdef.

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

netfilter: nfnetlinkqueue: do shared-unconfirmed check before segmentation

Ulrich reports a regression with nfqueue:

If an application did not set the 'FGSO' capability flag and a gso packet with an unconfirmed nfconn entry is received all packets are now dropped instead of queued, because the check happens after skbgsosegment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skbclone happening via skbgsosegment().

Move the check so that its peformed vs. the aggregated packet.

Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.

For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.

While at it, simplify nfctdropunconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.

This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.

Next patch adds a udpgro test case to cover this scenario.

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

drm/amdgpu: Use kvfree instead of kfree in amdgpugmcgetnpsmemranges()

amdgpudiscoverygetnpsinfo() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption.

Use kvfree() to safely handle both kmalloc and vmalloc allocations.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

bnxten: Fix RSS context delete logic

We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netifrunning() is true to help delete RSS contexts with interface down.

Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts.

Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netifrunning() check is not necessary.

Remove the netifrunning() condition check when deleting an RSS context.

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

KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU

Reject synchronizing vCPU state to its associated VMSA if the vCPU has already been launched, i.e. if the VMSA has already been encrypted. On a host with SNP enabled, accessing guest-private memory generates an RMP #PF and panics the host.

BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: errorcode(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sevessyncvmsa+0x54/0x4c0 [kvmamd] Call Trace: <TASK> snplaunchupdatevmsa+0x19d/0x290 [kvmamd] snplaunchfinish+0xb6/0x380 [kvmamd] sevmemencioctl+0x14e/0x720 [kvmamd] kvmarchvmioctl+0x837/0xcf0 [kvm] kvmvmioctl+0x3fd/0xcc0 [kvm] x64sysioctl+0xa3/0x100 x64syscall+0xfe0/0x2350 dosyscall64+0x81/0x10f0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7ffff673287d </TASK>

Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"), but has only been actively dangerous for the host since SNP support was added. With SEV-ES, KVM would "just" clobber guest state, which is totally fine from a host kernel perspective since userspace can clobber guest state any time before sevlaunchupdatevmsa().

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

KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish

Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as allowing userspace to manipulate and/or run a vCPU while its state is being synchronized would at best corrupt vCPU state, and at worst crash the host kernel.

Opportunistically assert that vcpu->mutex is held when synchronizing its VMSA (the SEV-ES path already locks vCPUs).

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

xfrm: Fix work re-schedule after cancel in xfrmnatkeepalivenetfini()

After canceldelayedworksync() is called from xfrmnatkeepalivenetfini(), xfrmstatefini() flushes remaining states via xfrmstatedelete(), which calls xfrmnatkeepalivestateupdated() to re-schedule natkeepalivework.

The following is a simple race scenario:

cpu0 cpu1

cleanupnet() [Round 1] opsundolist() xfrmnetexit() xfrmnatkeepalivenetfini() canceldelayedworksync(natkeepalivework); xfrmstatefini() xfrmstateflush() xfrmstatedelete(x) xfrmstatedelete(x) xfrmnatkeepalivestateupdated(x) scheduledelayedwork(natkeepalivework); rcubarrier(); netcompletefree(); netpassivedec(net); llistadd(&net->deferfreelist, &deferfreelist);

cleanupnet() [Round 2] rcubarrier(); netcompletefree() kmemcachefree(netcachep, net); natkeepalivework() // on freed net

To prevent this, canceldelayedworksync() is replaced with disabledelayedworksync().

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

HID: bpf: prevent buffer overflow in hidhwrequest

right now the returned value is considered to be always valid. However, when playing with HID-BPF, the return value can be arbitrary big, because it's the return value of dispatchhidbpfrawrequests(), which calls the structops and we have no guarantees that the value makes sense.

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

gpio: virtuser: fix UAF in configfs release path

The gpio-virtuser configfs release path uses guard(mutex) to protect the device structure. However, the device is freed before the guard cleanup runs, causing mutexunlock() to operate on freed memory.

Specifically, gpiovirtuserdeviceconfiggrouprelease() destroys the mutex and frees the device while still inside the guard(mutex) scope. When the function returns, the guard cleanup invokes mutexunlock(&dev->lock), resulting in a slab use-after-free.

Limit the mutex lifetime by using a scopedguard() only around the activation check, so that the lock is released before mutexdestroy() and kfree() are called.

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

RDMA/core: always drop device refcount in ibdelsubdeviceandput()

Since nldevdeldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add support to add/delete a sub IB device through netlink") grabs a reference using ibdevicegetbyindex() before calling ibdelsubdeviceandput(), we need to drop that reference before returning -EOPNOTSUPP error.

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

drm/xe/oa: Fix potential UAF in xeoaaddconfigioctl()

In xeoaaddconfigioctl(), we accessed oaconfig->id after dropping metricslock. Since this lock protects the lifetime of oaconfig, an attacker could guess the id and call xeoaremoveconfigioctl() with perfect timing, freeing oaconfig before we dereference it, leading to a potential use-after-free.

Fix this by caching the id in a local variable while holding the lock.

v2: (Matt A) - Dropped mutexunlock(&oa->metricslock) ordering change from xeoaremoveconfigioctl()

(cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

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

iommufd: Fix race during abort for file descriptors

fput() doesn't actually call fileoperations release() synchronously, it puts the file on a work queue and it will be released eventually.

This is normally fine, except for iommufd the file and the iommufdobject are tied to gether. The file has the object as it's privatedata and holds a users refcount, while the object is expected to remain alive as long as the file is.

When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount.

Fix this by putting the core code in charge of the file lifetime, and call fputsync() during abort to ensure that release() is called before kfree. fputsync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle.

If the object is successfully allocated then the file will hold a users refcount and the iommufdobject cannot be destroyed.

It is worth noting that close(); ioctl(IOMMUDESTROY); doesn't have an issue because close() is already using a synchronous version of fput().

The UAF looks like this:

BUG: KASAN: slab-use-after-free in iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164

CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchsubrelease include/linux/atomic/atomic-instrumented.h:400 [inline] refcountdec include/linux/refcount.h:455 [inline] refcountdec include/linux/refcount.h:476 [inline] iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 fput+0x402/0xb70 fs/filetable.c:468 taskworkrun+0x14d/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xeb/0x110 kernel/entry/common.c:43 exittousermodeprepare include/linux/irq-entry-common.h:225 [inline] syscallexittousermodework include/linux/entry-common.h:175 [inline] syscallexittousermode include/linux/entry-common.h:210 [inline] dosyscall64+0x41c/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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

s390/mm: Do not map lowcore with identity mapping

Since the identity mapping is pinned to address zero the lowcore is always also mapped to address zero, this happens regardless of the relocatelowcore command line option. If the option is specified the lowcore is mapped twice, instead of only once.

This means that NULL pointer accesses will succeed instead of causing an exception (low address protection still applies, but covers only parts). To fix this never map the first two pages of physical memory with the identity mapping.

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

spi: cs42l43: Property entry should be a null-terminated array

The software node does not specify a count of property entries, so the array must be null-terminated.

When unterminated, this can lead to a fault in the downstream cs35l56 amplifier driver, because the node parse walks off the end of the array into unknown memory.

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

smc: Fix various oops due to inetsock type confusion.

syzbot reported weird splats [0][1] in cipsov4socksetattr() while freeing inetsk(sk)->inetopt.

The address was freed multiple times even though it was read-only memory.

cipsov4socksetattr() did nothing wrong, and the root cause was type confusion.

The cited commit made it possible to create smcsock as an INET socket.

The issue is that struct smcsock does not have struct inetsock as the first member but hijacks AFINET and AFINET6 skfamily, which confuses various places.

In this case, inetsock.inetopt was actually smcsock.clcskdataready(), which is an address of a function in the text segment.

$ pahole -C inetsock vmlinux struct inetsock { ... struct ipoptionsrcu inetopt; / 784 8 /

$ pahole -C smcsock vmlinux struct smcsock { ... void (clcskdataready)(struct sock ); / 784 8 /

The same issue for another field was reported before. [2][3]

At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change.

Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txoptget").

Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra.

Let's add inetsock as the first member of smcsock.

[0]: kvfreecallrcu(): Double-freed call. rcuhead 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slabcommon.c:1956 kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 lr : kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 (P) cipsov4socksetattr+0x2f0/0x3f4 net/ipv4/cipsoipv4.c:1914 netlblsocksetattr+0x240/0x334 net/netlabel/netlabelkapi.c:1000 smacknetlbladd+0xa8/0x158 security/smack/smacklsm.c:2581 smackinodesetsecurity+0x378/0x430 security/smack/smacklsm.c:2912 securityinodesetsecurity+0x118/0x3c0 security/security.c:2706 vfssetxattrnoperm+0x174/0x5c4 fs/xattr.c:251 vfssetxattrlocked+0x1ec/0x218 fs/xattr.c:295 vfssetxattr+0x158/0x2ac fs/xattr.c:321 dosetxattr fs/xattr.c:636 [inline] filesetxattr+0x1b8/0x294 fs/xattr.c:646 pathsetxattrat+0x2ac/0x320 fs/xattr.c:711 dosysfsetxattr fs/xattr.c:761 [inline] sesysfsetxattr fs/xattr.c:758 [inline] arm64sysfsetxattr+0xc0/0xdc fs/xattr.c:758 invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t64synchandler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t64sync+0x198/0x19c arch/arm64/kernel/entry.S:600

[ ---truncated---

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

iouring/msgring: ensure iokiocb freeing is deferred for RCU

syzbot reports that defer/local taskwork adding via msgring can hit a request that has been freed:

CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xd2/0x2b0 mm/kasan/report.c:521 kasanreport+0x118/0x150 mm/kasan/report.c:634 ioreqlocalworkadd iouring/iouring.c:1184 [inline] ioreqtaskworkadd+0x589/0x950 iouring/iouring.c:1252 iomsgremotepost iouring/msgring.c:103 [inline] iomsgdataremote iouring/msgring.c:133 [inline] iomsgringdata+0x820/0xaa0 iouring/msgring.c:151 iomsgringdata iouring/msgring.c:173 [inline] iomsgring+0x134/0xa00 iouring/msgring.c:314 ioissuesqe+0x17e/0x4b0 iouring/iouring.c:1739 ioissuesqe+0x165/0xfd0 iouring/iouring.c:1762 iowqsubmitwork+0x6e9/0xb90 iouring/iouring.c:1874 ioworkerhandlework+0x7cd/0x1180 iouring/io-wq.c:642 iowqworker+0x42f/0xeb0 iouring/io-wq.c:696 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

which is supposed to be safe with how requests are allocated. But msg ring requests alloc and free on their own, and hence must defer freeing to a sane time.

Add an rcuhead and use kfreercu() in both spots where requests are freed. Only the one in iomsgtwcomplete() is strictly required as it has been visible on the other ring, but use it consistently in the other spot as well.

This should not cause any other issues outside of KASAN rightfully complaining about it.

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

ASoC: codecs: wcd9375: Fix double free of regulator supplies

Driver gets regulator supplies in probe path with devmregulatorbulkget(), so should not call regulatorbulkfree() in error and remove paths to avoid double free.

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

virtio-net: xsk: rx: fix the frame's length check

When calling buftoxdp, the len argument is the frame data's length without virtio header's length (vi->hdrlen). We check that len with

xskpoolgetrxframesize() + vi->hdrlen

to ensure the provided len does not larger than the allocated chunk size. The additional vi->hdrlen is because in virtnetaddrecvbufxsk, we use part of XDPPACKETHEADROOM for virtio header and ask the vhost to start placing data from

hardstart + XDPPACKETHEADROOM - vi->hdrlen not hardstart + XDPPACKETHEADROOM

But the first buffer has virtioheader, so the maximum frame's length in the first buffer can only be

xskpoolgetrxframesize() not xskpoolgetrxframesize() + vi->hdrlen

like in the current check.

This commit adds an additional argument to buftoxdp differentiate between the first buffer and other ones to correctly calculate the maximum frame's length.

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

eth: fbnic: avoid double free when failing to DMA-map FW msg

The semantics are that caller of fbnicmbxmapmsg() retains the ownership of the message on error. All existing callers dutifully free the page.

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

wifi: ath12k: Fix buffer overflow in debugfs

If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users.

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

fs/fhandle.c: fix a race in call of haslockedchildren()

maydecodefh() is calling haslockedchildren() while holding no locks. That's an oopsable race...

The rest of the callers are safe since they are holding namespacesem and are guaranteed a positive refcount on the mount in question.

Rename the current haslockedchildren() to haslockedchildren(), make it static and switch the fs/namespace.c users to it.

Make haslockedchildren() a wrapper for haslockedchildren(), calling the latter under readseqlockexcl(&mountlock).

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

PCI/pwrctrl: Cancel outstanding rescan work when unregistering

It's possible to trigger use-after-free here by:

(a) forcing rescanworkfunc() to take a long time and (b) utilizing a pwrctrl driver that may be unloaded for some reason

Cancel outstanding work to ensure it is finished before we allow our data structures to be cleaned up.

[bhelgaas: tidy commit log]