OESA-2025-2119

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/amd/display: Fix memory leak

[why] Resource release is needed on the error handling path to prevent memory leak.

[how] Fix this by adding kfree on the error handling path.(CVE-2022-49135)

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

netfilter: nftables: avoid skb access on nfstolen

When verdict is NF_STOLEN, the skb might have been freed.

When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload

To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN.

Avoid 2 by skipping skb->mark access if verdict is STOLEN.

3 is avoided by precomputing the trace id.

Only dump the packet when verdict is not "STOLEN".(CVE-2022-49622)

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

nfsd: release svcexpkey/svcexport with rcu_work

The last reference for cache_head can be reduced to zero in c_show and e_show(using rcu_read_lock and rcu_read_unlock). Consequently, svc_export_put and expkey_put will be invoked, leading to two issues:

1. The svc_export_put will directly free ex_uuid. However, e_show/c_show will access ex_uuid after cache_put, which can trigger a use-after-free issue, shown below.

   ================================================================== BUG: KASAN: slab-use-after-free in svcexportshow+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870

   CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printaddressdescription.constprop.0+0x2c/0x3a0 printreport+0xb9/0x280 kasanreport+0xae/0xe0 svcexportshow+0x362/0x430 [nfsd] cshow+0x161/0x390 [sunrpc] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 procregread+0xe1/0x140 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

   Allocated by task 830: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 _kmallocnodetrackcallernoprof+0x1bc/0x400 kmemdupnoprof+0x22/0x50 svcexportparse+0x8a9/0xb80 [nfsd] cachedodowncall+0x71/0xa0 [sunrpc] cachewriteprocfs+0x8e/0xd0 [sunrpc] procregwrite+0xe1/0x140 vfswrite+0x1a5/0x6d0 ksyswrite+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

   Freed by task 868: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x37/0x50 kfree+0xf3/0x3e0 svcexportput+0x87/0xb0 [nfsd] cachepurge+0x17f/0x1f0 [sunrpc] nfsddestroyserv+0x226/0x2d0 [nfsd] nfsdsvc+0x125/0x1e0 [nfsd] writethreads+0x16a/0x2a0 [nfsd] nfsctltransactionwrite+0x74/0xa0 [nfsd] vfswrite+0x1a5/0x6d0 ksyswrite+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

2. We cannot sleep while using rcu_read_lock/rcu_read_unlock. However, svc_export_put/expkey_put will call path_put, which subsequently triggers a sleeping operation due to the following dput.

   ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted

... Call Trace: dumpstack+0x9a/0xd0 _mightsleep+0x231/0x240 dput+0x39/0x600 pathput+0x1b/0x30 svcexportput+0x17/0x80 eshow+0x1c9/0x200 seqreaditer+0x63f/0x7c0 seqread+0x226/0x2d0 vfsread+0x113/0x2c0 ksysread+0xc9/0x170 dosyscall64+0x33/0x40 entrySYSCALL64after_hwframe+0x67/0xd1

Fix these issues by using rcu_work to help release svc_expkey/svc_export. This approach allows for an asynchronous context to invoke path_put and also facilitates the freeing of uuid/exp/key after an RCU grace period.(CVE-2024-53216)

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

scsi: ufs: bsg: Set bsg_queue to NULL after removal

Currently, this does not cause any issues, but I believe it is necessary to set bsg_queue to NULL after removing it to prevent potential use-after-free (UAF) access.(CVE-2024-54458)

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

nfsd: make sure exp active before svcexportshow

The function e_show was called with protection from RCU. This only ensures that exp will not be freed. Therefore, the reference count for exp can drop to zero, which will trigger a refcount use-after-free warning when exp_get is called. To resolve this issue, use cache_get_rcu to ensure that exp remains active.

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcountwarnsaturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb1/0x120 ... Call Trace: <TASK> eshow+0x20b/0x230 [nfsd] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-56558)

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

ipv6: mcast: extend RCU protection in igmp6_send()

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.

Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFP_KERNEL allocations which can sleep.

Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.(CVE-2025-21759)

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

rapidio: fix an API misues when rioaddnet() fails

rioaddnet() calls deviceregister() and fails when deviceregister() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue.(CVE-2025-21934)

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

netfilter: nfttunnel: fix geneveopt type confusion addition

When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char *.

However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.

[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] _syssendmsg+0xfd/0x170 [ 7.003145] _syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8

Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)

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

mm/vmscan: don't try to reclaim hwpoison folio

Syzkaller reports a bug as follows:

Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VMBUGONFOLIO(!foliotestuptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swapstate.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : addtoswap+0xbc/0x158 lr : addtoswap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: addtoswap+0xbc/0x158 shrinkfoliolist+0x12ac/0x2648 shrinkinactivelist+0x318/0x948 shrinklruvec+0x450/0x720 shrinknodememcgs+0x280/0x4a8 shrinknode+0x128/0x978 balancepgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 retfromfork+0x10/0x20

I can reproduce this issue with the following steps:

1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. meswapcachedirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.

2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.

3) If we trigger a reclaim again and tries to reclaim the page, addtoswap() will trigger VMBUGON_FOLIO due to the uptodate flag is cleared.

To fix it, skip the hwpoisoned page in shrinkfoliolist(). Besides, the hwpoison folio may not be unmapped by hwpoisonusermappings() yet, unmap it in shrinkfoliolist(), otherwise the folio will fail to be unmaped by hwpoisonusermappings() since the folio isn't in lru list.(CVE-2025-37834)

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

KVM: x86: Reset IRTE to host control if new route isn't postable

Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.

The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)

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

bnxt_en: Fix out-of-bound memcpy() during ethtool -w

When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:

BUG: KFENCE: memory corruption in _bnxtgetcoredump+0x3ef/0x670 [bnxten] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): _bnxtgetcoredump+0x3ef/0x670 [bnxten] ethtoolgetdumpdata+0xdc/0x1a0 _devethtool+0xa1e/0x1af0 devethtool+0xa8/0x170 devioctl+0x1b5/0x580 sockdoioctl+0xab/0xf0 sockioctl+0x1ce/0x2e0 _x64sysioctl+0x87/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64after_hwframe+0x78/0x80

...

This happens when copying the coredump segment list in bnxthwrmdbgdmadata() with the HWRMDBGCOREDUMPLIST FW command. The info->destbuf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.

In some cases, this DMA length may exceed the info->destbuf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->destbuf. The extra DMA data contains no useful information.

This code path is shared for the HWRMDBGCOREDUMPLIST and the HWRMDBGCOREDUMPRETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRMDBGCOREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)

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

schhtb: make htbqlen_notify() idempotent

htbqlennotify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fqcodeldequeue().

Let's make it idempotent to ease qdisctreereduce_backlog() callers' life.(CVE-2025-37932)

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

mm/hugetlb: fix hugepmdunshare() vs GUP-fast race

hugepmdunshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.

If this happens in the middle of a concurrent gupfast(), gupfast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.

Fix it with an explicit broadcast IPI through tlbremovetablesyncone(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)

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

pagepool: Fix use-after-free in pagepoolrecyclein_ring

syzbot reported a uaf in pagepoolrecycleinring:

BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943

CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5862 _rawspinunlockbh include/linux/spinlockapismp.h:165 [inline] _rawspinunlockbh+0x1b/0x40 kernel/locking/spinlock.c:210 spinunlockbh include/linux/spinlock.h:396 [inline] ptrringproducebh include/linux/ptrring.h:164 [inline] pagepoolrecycleinring net/core/pagepool.c:707 [inline] pagepoolputunrefednetmem+0x748/0xb00 net/core/pagepool.c:826 pagepoolputnetmem include/net/pagepool/helpers.h:323 [inline] pagepoolputfullnetmem include/net/pagepool/helpers.h:353 [inline] napippputpage+0x149/0x2b0 net/core/skbuff.c:1036 skbpprecycle net/core/skbuff.c:1047 [inline] skbfreehead net/core/skbuff.c:1094 [inline] skbreleasedata+0x6c4/0x8a0 net/core/skbuff.c:1125 skbreleaseall net/core/skbuff.c:1190 [inline] _kfreeskb net/core/skbuff.c:1204 [inline] skskbreasondrop+0x1c9/0x380 net/core/skbuff.c:1242 kfreeskbreason include/linux/skbuff.h:1263 [inline] _skbqueuepurge_reason include/linux/skbuff.h:3343 [inline]

root cause is:

pagepoolrecycleinring ptrringproduce spinlock(&r->producerlock); WRITEONCE(r->queue[r->producer++], ptr) //recycle last page to pool pagepoolrelease pagepoolscrub pagepoolemptyring ptrringconsume pagepoolreturnpage //release all page _pagepooldestroy freepercpu(pool->recyclestats); free(pool) //free

 spin_unlock(&r->producer_lock); //pool->ring uaf read

recyclestatinc(pool, ring);

pagepool can be free while page pool recycle the last page in ring. Add producer-lock barrier to pagepool_release to prevent the page pool from being free before all pages have been recycled.

recyclestatinc() is empty when CONFIGPAGEPOOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)

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

thunderbolt: Do not double dequeue a configuration request

Some of our devices crash in tbcfgrequest_dequeue():

general protection fault, probably for non-canonical address 0xdead000000000122

CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tbcfgrequestdequeue+0x2d/0xa0 Call Trace: <TASK> ? tbcfgrequestdequeue+0x2d/0xa0 tbcfgrequestwork+0x33/0x80 workerthread+0x386/0x8f0 kthread+0xed/0x110 retfromfork+0x38/0x50 retfromfork_asm+0x1b/0x30

The circumstances are unclear, however, the theory is that tbcfgrequestwork() can be scheduled twice for a request: first time via frame.callback from ringwork() and second time from tbcfgrequest(). Both times kworkers will execute tbcfgrequestdequeue(), which results in double listdel() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122).

Do not dequeue requests that don't have TBCFGREQUEST_ACTIVE bit set.(CVE-2025-38174)

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

schhfsc: make hfscqlen_notify() idempotent

hfscqlennotify() is not idempotent either and not friendly to its callers, like fqcodeldequeue(). Let's make it idempotent to ease qdisctreereduce_backlog() callers' life:

1. updatevf() decreases cl->clnactive, so we can check whether it is non-zero before calling it.

2. eltreeremove() always removes RB node cl->elnode, but we can use RBEMPTYNODE() + RBCLEARNODE() to make it safe.(CVE-2025-38177)

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

HID: core: do not bypass hidhwraw_request

hidhwraw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)

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

perf/core: Prevent VMA split of buffer mappings

The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.

Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perfmmapopen() calls, which take reference counts, but then the subsequent perfmmapclose() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.

As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.

Implement the vmoperationsstruct::may_split() callback and return unconditionally -EINVAL.

That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)

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

RDMA/hns: Fix double destruction of rsv_qp

rsvqp may be double destroyed in error flow, first in freemrinit(), and then in hnsroceexit(). Fix it by moving the freemrinit() call into hnsrocev2init().

listdel corruption, ffff589732eb9b50->next is LISTPOISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/listdebug.c:53 _listdelentryvalid+0x148/0x240 ... Call trace: _listdelentryvalid+0x148/0x240 hnsroceqpremove+0x4c/0x3f0 [hnsrocehwv2] hnsrocev2destroyqpcommon+0x1dc/0x5f4 [hnsrocehwv2] hnsrocev2destroyqp+0x22c/0x46c [hnsrocehwv2] freemrexit+0x6c/0x120 [hnsrocehwv2] hnsrocev2exit+0x170/0x200 [hnsrocehwv2] hnsroceexit+0x118/0x350 [hnsrocehwv2] _hnsrocehwv2initinstance+0x1c8/0x304 [hnsrocehwv2] hnsrocehwv2resetnotifyinit+0x170/0x21c [hnsrocehwv2] hnsrocehwv2resetnotify+0x6c/0x190 [hnsrocehwv2] hclgenotifyroceclient+0x6c/0x160 [hclge] hclgeresetrebuild+0x150/0x5c0 [hclge] hclgereset+0x10c/0x140 [hclge] hclgeresetsubtask+0x80/0x104 [hclge] hclgeresetservicetask+0x168/0x3ac [hclge] hclgeservicetask+0x50/0x100 [hclge] processonework+0x250/0x9a0 workerthread+0x324/0x990 kthread+0x190/0x210 retfromfork+0x10/0x18(CVE-2025-38582)

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

vmci: Prevent the dispatching of uninitialized payloads

The reproducer executes the host's unlockedioctl call in two different tasks. When initcontext fails, the struct vmcieventctx is not fully initialized when executing vmcidatagramdispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.

Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)

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

pinmux: fix race causing muxowner NULL with active muxusecount

commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrlselectstate() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.

The issue occurs due to the following interleaving:

 cpu0 (process A)                   cpu1 (process B)

  pin_request() {                   pin_free() {

                                     mutex_lock()
                                     desc->mux_usecount--; //becomes 0
                                     ..
                                     mutex_unlock()

mutexlock(desc->mux) desc->muxusecount++; // becomes 1 desc->muxowner = owner; mutexunlock(desc->mux)

                                     mutex_lock(desc->mux)
                                     desc->mux_owner = NULL;
                                     mutex_unlock(desc->mux)

This sequence leads to a state where the pin appears to be in use (mux_usecount == 1) but has no owner (mux_owner == NULL), which can cause NULL pointer on next pin_request on the same pin.

Ensure that updates to muxusecount and muxowner are performed atomically under the same lock. Only clear muxowner when muxusecount reaches zero and no new owner has been assigned.(CVE-2025-38632)

In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)