OESA-2025-2635

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, loadmicrocodeamd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: Some memory may share the same node as a CPU, and others are provided as memory only nodes. Therefore, some node CPU masks may be empty and wouldn t have a first CPU .On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumaskofnode(nid) is 0- cpumaskfirst(0) is CONFIGNRCPUS- cpudata(CONFIGNRCPUS) accesses the cpuinfo per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIGUBSANBOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type unsigned long[512] [...] Call Trace: dumpstack _ubsanhandleoutofbounds loadmicrocodeamd requestmicrocodeamd reloadstore kernfsfopwriteiter vfswrite ksyswrite dosyscall64 entrySYSCALL64after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. bp: Massage commit message, fix typo.

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

openvswitch: Fix unsafe attribute parsing in output_userspace()

This patch replaces the manual Netlink attribute iteration in outputuserspace() with nlaforeachnested(), which ensures that only well-formed attributes are processed.(CVE-2025-37998)

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

comedi: pcl726: Prevent invalid irq number

The reproducer passed in an irq number(0x80008000) that was too large, which triggered the oob.

Added an interrupt number check to prevent users from passing in an irq number that was too large.

If it->options[1] is 31, then 1 << it->options[1] is still invalid because it shifts a 1-bit into the sign bit (which is UB in C). Possible solutions include reducing the upper bound on the it->options[1] value to 30 or lower, or using 1U << it->options[1].

The old code would just not attempt to request the IRQ if the options[1] value were invalid. And it would still configure the device without interrupts even if the call to request_irq returned an error. So it would be better to combine this test with the test below.(CVE-2025-39685)

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

ACPI: pfr_update: Fix the driver update version check

The security-version-number check should be used rather than the runtime version check for driver updates.

Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one.

rjw: Changelog edits

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

mm/vmscan: fix hwpoisoned large folio handling in shrinkfoliolist

In shrinkfoliolist(), the hwpoisoned folio may be large folio, which can't be handled by unmappoisonedfolio(). For THP, trytounmapone() must be passed with TTUSPLITHUGEPMD to split huge PMD first and then retry. Without TTUSPLITHUGEPMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTUSPLITHUGEPMD, we will trigger a WARNONONCE due to the page isn't in swapcache.

Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.

This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:

cpu0 cpu1 shrinkfoliolist memoryfailure TestSetPageHWPoison unmappoisonedfolio --> trigger BUGON due to unmappoisonedfolio couldn't handle large folio

[(CVE-2025-39725)

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

RDMA: hfi1: fix possible divide-by-zero in findhwthread_mask()

The function divides number of online CPUs by numcoresiblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level.(CVE-2025-39742)

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

jbd2: prevent softlockup in jbd2logdo_checkpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlist_lock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like _flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] _ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 _writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 _writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfrom_fork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.(CVE-2025-39782)

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

net/mlx5: Fix lockdep assertion on sync reset unload event

Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning.

Kernel log: WARNING: CPU: 9 PID: 1578 at devlassertlocked+0x31/0x40 [...] Call Trace: <TASK> mlx5unloadonedevllocked+0x2c/0xc0 [mlx5core] mlx5syncresetunloadevent+0xaf/0x2f0 [mlx5core] processonework+0x222/0x640 workerthread+0x199/0x350 kthread+0x10b/0x230 ? _pfxworkerthread+0x10/0x10 ? _pfxkthread+0x10/0x10 retfromfork+0x8e/0x100 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>(CVE-2025-39832)

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

ppp: fix memory leak in padcompressskb

If allocskb() fails in padcompress_skb(), it returns NULL without releasing the old skb. The caller does:

skb = pad_compress_skb(ppp, skb);
if (!skb)
    goto drop;

drop: kfree_skb(skb);

When padcompressskb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.

Align padcompressskb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the newskb variable so the original skb is not lost when padcompress_skb() fails.(CVE-2025-39847)

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

Bluetooth: Fix use-after-free in l2capsockcleanup_listen()

syzbot reported the splat below without a repro.

In the splat, a single thread calling btacceptdequeue() freed sk and touched it after that.

The root cause would be the racy l2capsockcleanup_listen() call added by the cited commit.

btacceptdequeue() is called under locksock() except for l2capsock_release().

Two threads could see the same socket during the list iteration in btacceptdequeue():

CPU1 CPU2 (close()) ---- ---- sockhold(sk) sockhold(sk); locksock(sk) <-- block close() sockput(sk) btacceptunlink(sk) sockput(sk) <-- refcnt by btacceptenqueue() releasesock(sk) locksock(sk) sockput(sk) btacceptunlink(sk) sockput(sk) <-- last refcnt btaccept_unlink(sk) <-- UAF

Depending on the timing, the other thread could show up in the "Freed by task" part.

Let's call l2capsockcleanuplisten() under locksock() in l2capsockrelease().

BUG: KASAN: slab-use-after-free in dorawspinlock+0x26f/0x2b0 kernel/locking/spinlockdebug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 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 debugspinlockbefore kernel/locking/spinlockdebug.c:86 [inline] dorawspinlock+0x26f/0x2b0 kernel/locking/spinlockdebug.c:115 spinlockbh include/linux/spinlock.h:356 [inline] releasesock+0x21/0x220 net/core/sock.c:3746 btacceptdequeue+0x505/0x600 net/bluetooth/afbluetooth.c:312 l2capsockcleanuplisten+0x5c/0x2a0 net/bluetooth/l2capsock.c:1451 l2capsockrelease+0x5c/0x210 net/bluetooth/l2capsock.c:1425 _sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 _fput+0x3ff/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+0x3f6/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>

Allocated by task 5326: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:388 [inline] _kasankmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4365 [inline] _kmallocnopro ---truncated---(CVE-2025-39860)

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

libceph: fix invalid accesses to cephconnectionv1_info

There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).

On 64-bit systems, con->v1.authretry overlaps with con->v2.outiter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.

con->v1.connectseq overlaps with con->v2.connbufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.(CVE-2025-39880)

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

Bluetooth: l2cap: Check encryption key size on incoming connection

This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit

This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.

Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available

And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 > ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)(CVE-2025-39889)

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

cnic: Fix use-after-free bugs in cnicdeletetask

The original code uses canceldelayedwork() in cniccmstopbnx2xhw(), which does not guarantee that the delayed work item 'deletetask' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flushworkqueue() in cniccmstopbnx2xhw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flushworkqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnicdev is deallocated by cnicfreedev(), while deletetask remains active and attempt to dereference cnicdev in cnicdeletetask().

A typical race condition is illustrated below:

CPU 0 (cleanup) | CPU 1 (delayed work callback) cnicnetdevevent() | cnicstophw() | cnicdeletetask() cniccmstopbnx2xhw() | ... canceldelayedwork() | /* the queuedelayedwork() flushworkqueue() | executes after flushworkqueue()*/ | queuedelayedwork() cnicfreedev(dev)//free | cnicdeletetask() //new instance | dev = cp->dev; //use

Replace canceldelayedwork() with canceldelayedworksync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnicdev is deallocated. Furthermore, since canceldelayedworksync() uses _flushwork(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flushworkqueue() becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnicdeletetask() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)

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

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: phwfn->cdev->dbgfeatures[DBGFEATUREPROTECTIONOVERRIDE].dumpbuf and the size of the buffer is buf_size in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

[exception RIP: qed_grc_dump_addr_range+0x108]

qedprotectionoverridedump at ffffffffc02662ed [qed] qeddbgprotectionoverridedump at ffffffffc0267792 [qed] qeddbgfeature at ffffffffc026aa8f [qed] qeddbgalldata at ffffffffc026b211 [qed] qedfwfatalreporterdump at ffffffffc027298a [qed] devlinkhealthdodump at ffffffff82497f61 devlinkhealthreport at ffffffff8249cf29 qedreportfatalerror at ffffffffc0272baf [qed] qedesptask at ffffffffc045ed32 [qede] processonework at ffffffff81d19783

or the qedf storage driver path:

[exception RIP: qed_grc_dump_addr_range+0x108]

qedprotectionoverridedump at ffffffffc068b2ed [qed] qeddbgprotectionoverridedump at ffffffffc068c792 [qed] qeddbgfeature at ffffffffc068fa8f [qed] qeddbgalldata at ffffffffc0690211 [qed] qedfwfatalreporterdump at ffffffffc069798a [qed] devlinkhealthdodump at ffffffff8aa95e51 devlinkhealthreport at ffffffff8aa9ae19 qedreportfatalerror at ffffffffc0697baf [qed] qedhwerrnotify at ffffffffc06d32d7 [qed] qedspqpost at ffffffffc06b1011 [qed] qedfcoedestroyconn at ffffffffc06b2e91 [qed] qedfcleanupfcport at ffffffffc05e7597 [qedf] qedfrporteventhandler at ffffffffc05e7bf7 [qedf] fcrportwork at ffffffffc02da715 [libfc] processone_work at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.(CVE-2025-39949)

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

i40e: fix validation of VF state in get resources

VF state I40EVFSTATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources.

Use I40EVFSTATERESOURCESLOADED that is set only in i40evcgetvfresources_msg() and cleared during reset.(CVE-2025-39969)

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

i40e: fix input validation logic for action_meta

Fix condition to check 'greater or equal' to prevent OOB dereference.(CVE-2025-39970)

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

i40e: fix idx validation in i40evalidatequeue_map

Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40evalidatequeue_map().(CVE-2025-39972)

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

i40e: add validation for ring_len param

The ring_len parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation.

To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)

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

futex: Prevent use-after-free during requeue-PI

syzbot managed to trigger the following race:

T1 T2

futexwaitrequeuepi() futexdowait() schedule() futexrequeue() futexproxytrylockatomic() futexrequeuepiprepare() requeuepiwakefutex() futexrequeuepicomplete() /* preempt */

     * timeout/ signal wakes T1 *

futexrequeuepiwakeupsync() // QREQUEUEPILOCKED futexhashput() // back to userland, on stack futexq is garbage

                                  /* back */
                                 wake_up_state(q->task, TASK_NORMAL);

In this scenario futexwaitrequeuepi() is able to leave without using futexq::lock_ptr for synchronization.

This can be prevented by reading futexq::task before updating the futexq::requeuestate. A reference on the taskstruct is not needed because requeuepiwakefutex() is invoked with a spinlockt held which implies a RCU read section.

Even if T1 terminates immediately after, the taskstruct will remain valid during T2's wakeupstate(). A READONCE on futexq::task before futexrequeuepicomplete() is enough because it ensures that the variable is read before the state is updated.

Read futex_q::task before updating the requeue state, use it for the following wakeup.(CVE-2025-39977)

In the Linux kernel, a race condition vulnerability exists in the mm/hugetlb subsystem. Migration may race with fallocating hole operations. The removeinodesinglefolio function checks if the folio is still mapped without holding the folio lock. If the folio is migrated and the mapped page table entry has been converted to a migration entry, foliomapped() returns false and fails to unmap it. Due to the extra refcount held by removeinodesinglefolio, migration fails, restores the migration entry to a normal page table entry, and the folio is mapped again, ultimately triggering a BUG in filemapunaccount_folio.(CVE-2025-40006)

In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamicevents interface on tracefs is compatible withkprobeevents and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)

There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perfevents initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perfevents pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/tracekprobe.c at line 1308, the kprobeperffunc function attempts to access the call->perfevents pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)

In the Linux kernel, a vulnerability has been identified in the PTP (Precision Time Protocol) subsystem. syzbot reported a WARNING in maxvclocksstore function. This occurs when the max argument is too large for kcalloc to handle, leading to potential buffer overflow. The vulnerability is resolved by adding an upper bound on max_vclocks.(CVE-2025-40057)

In the Linux kernel, the following vulnerability has been resolved:tty: ngsm: Don t block input queue by waiting MSCCurrently gsmqueue() processes incoming frames and when opening a DLC channel it calls gsmdlciopen() which calls gsmmodemupdate(). If basic mode is used it calls gsmmodemupdviamsc() and it cannot block the input queue by waiting the response to come into the same input queue.Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsmmodemsendinitialmsc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.(CVE-2025-40071)

In the Linux kernel, an integer overflow vulnerability exists in the armspe component of the perf subsystem. The PERFIDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn t been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exceptiontargetel() during the next injection. Reject the ioctls outright as no sane VMM would call these before KVMARMVCPU_INIT anyway.(CVE-2025-40102)