OESA-2025-1573

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

wifi: ath11k: add srng->lock for ath11khalsrng_* in monitor mode

ath11khalsrng_* should be used with srng->lock to protect srng data.

For ath11kdprxmondestprocess() and ath11kdpfullmonprocessrx(), they use ath11khalsrng_* for many times but never call srng->lock.

So when running (full) monitor mode, warning will occur: RIP: 0010:ath11khalsrngdstpeek+0x18/0x30 [ath11k] Call Trace: ? ath11khalsrngdstpeek+0x18/0x30 [ath11k] ath11kdprxprocessmonstatus+0xc45/0x1190 [ath11k] ? idrallocu32+0x97/0xd0 ath11kdprxprocessmonrings+0x32a/0x550 [ath11k] ath11kdpservicesrng+0x289/0x5a0 [ath11k] ath11kpcicextgrpnapipoll+0x30/0xd0 [ath11k] _napipoll+0x30/0x1f0 netrxaction+0x198/0x320 _dosoftirq+0xdd/0x319

So add srng->lock for them to avoid such warnings.

Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct halsrng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11kdpprocessrx().

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58096)

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

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash.

kernel log: ath11kpci 0000:58:00.0: data msdupop: invalid bufid 309 ath11kpci 0000:58:00.0: data dprxmonitorlinkdescreturn failed ath11kpci 0000:58:00.0: data msdupop: invalid bufid 309 ath11kpci 0000:58:00.0: data dprxmonitorlinkdescreturn failed

Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)

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

wifi: nl80211: reject cooked mode if it is set along with other flags

It is possible to set both MONITORFLAGCOOKFRAMES and MONITORFLAGACTIVE flags simultaneously on the same monitor interface from the userspace. This causes a sub-interface to be created with no IEEE80211SDATAINDRIVER bit set because the monitor interface is in the cooked state and it takes precedence over all other states. When the interface is then being deleted the kernel calls WARNONCE() from checksdataindriver() because of missing that bit.

Fix this by rejecting MONITORFLAGCOOK_FRAMES if it is set along with other flags.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-21909)

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

gpio: rcar: Use raw_spinlock to protect register access

Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access.

[    4.239592] =============================
[    4.239595] [ BUG: Invalid wait context ]
[    4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
[    4.239603] -----------------------------
[    4.239606] kworker/u8:5/76 is trying to lock:
[    4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
[    4.239641] other info that might help us debug this:
[    4.239643] context-{5:5}
[    4.239646] 5 locks held by kworker/u8:5/76:
[    4.239651]  #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c
[    4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
[    4.254094]  #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c
[    4.254109]  #2: ffff00000920c8f8
[    4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.
[    4.264803]  (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc
[    4.264820]  #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690
[    4.264840]  #4:
[    4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.
[    4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690
[    4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
[    4.304082] stack backtrace:
[    4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35
[    4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
[    4.304097] Workqueue: async async_run_entry_fn
[    4.304106] Call trace:
[    4.304110]  show_stack+0x14/0x20 (C)
[    4.304122]  dump_stack_lvl+0x6c/0x90
[    4.304131]  dump_stack+0x14/0x1c
[    4.304138]  __lock_acquire+0xdfc/0x1584
[    4.426274]  lock_acquire+0x1c4/0x33c
[    4.429942]  _raw_spin_lock_irqsave+0x5c/0x80
[    4.434307]  gpio_rcar_config_interrupt_input_mode+0x34/0x164
[    4.440061]  gpio_rcar_irq_set_type+0xd4/0xd8
[    4.444422]  __irq_set_trigger+0x5c/0x178
[    4.448435]  __setup_irq+0x2e4/0x690
[    4.452012]  request_threaded_irq+0xc4/0x190
[    4.456285]  devm_request_threaded_irq+0x7c/0xf4
[    4.459398] ata1: link resume succeeded after 1 retries
[    4.460902]  mmc_gpiod_request_cd_irq+0x68/0xe0
[    4.470660]  mmc_start_host+0x50/0xac
[    4.474327]  mmc_add_host+0x80/0xe4
[    4.477817]  tmio_mmc_host_probe+0x2b0/0x440
[    4.482094]  renesas_sdhi_probe+0x488/0x6f4
[    4.486281]  renesas_sdhi_internal_dmac_probe+0x60/0x78
[    4.491509]  platform_probe+0x64/0xd8
[    4.495178]  really_probe+0xb8/0x2a8
[    4.498756]  __driver_probe_device+0x74/0x118
[    4.503116]  driver_probe_device+0x3c/0x154
[    4.507303]  __device_attach_driver+0xd4/0x160
[    4.511750]  bus_for_each_drv+0x84/0xe0
[    4.515588]  __device_attach_async_helper+0xb0/0xdc
[    4.520470]  async_run_entry_fn+0x30/0xd8
[    4.524481]  process_one_work+0x210/0x62c
[    4.528494]  worker_thread+0x1ac/0x340
[    4.532245]  kthread+0x10c/0x110
[    4.535476]  ret_from_fork+0x10/0x20(CVE-2025-21912)

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

usb: typec: ucsi: Fix NULL pointer access

Resources should be released only after all threads that utilize them have been destroyed. This commit ensures that resources are not released prematurely by waiting for the associated workqueue to complete before deallocating them.(CVE-2025-21918)

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

net: mctp: unshare packets when reassembling

Ensure that the fraglist used for reassembly isn't shared with other packets. This avoids incorrect reassembly when packets are cloned, and prevents a memory leak due to circular references between fragments and their skbshared_info.

The upcoming MCTP-over-USB driver uses skb_clone which can trigger the problem - other MCTP drivers don't share SKBs.

A kunit test is added to reproduce the issue.(CVE-2025-21972)

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

bus: mhi: host: Fix race between unprepare and queue_buf

A client driver may use mhiunpreparefromtransfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhiqueuebuf() which will invoke mhigentre(). If mhigentre() runs after mhiunpreparefromtransfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault.

This occurs because mhigentre() does not verify the channel state after locking it. Fix this by having mhigentre() confirm the channel state is valid, or return error to avoid accessing deinitialized data.

mani: added stable tag

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

drm/i915/huc: Fix fence not released on early probe errors

HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel:

<4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915swfence hint: swfencedummynotify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debugprintobject+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915moduleloa Tainted: G U 6.14.0-CIDRM16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debugprintobject+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] _debugobjectinit+0x17b/0x1c0 <4> [309.731957] debugobjectinit+0x34/0x50 <4> [309.732126] _i915swfenceinit+0x34/0x60 [i915] <4> [309.732256] intelhucinitearly+0x4b/0x1d0 [i915] <4> [309.732468] intelucinitearly+0x61/0x680 [i915] <4> [309.732667] intelgtcommoninitearly+0x105/0x130 [i915] <4> [309.732804] intelrootgtinitearly+0x63/0x80 [i915] <4> [309.732938] i915driverprobe+0x1fa/0xeb0 [i915] <4> [309.733075] i915pciprobe+0xe6/0x220 [i915] <4> [309.733198] localpciprobe+0x44/0xb0 <4> [309.733203] pcideviceprobe+0xf4/0x270 <4> [309.733209] reallyprobe+0xee/0x3c0 <4> [309.733215] _driverprobedevice+0x8c/0x180 <4> [309.733219] driverprobedevice+0x24/0xd0 <4> [309.733223] _driverattach+0x10f/0x220 <4> [309.733230] busforeachdev+0x7d/0xe0 <4> [309.733236] driverattach+0x1e/0x30 <4> [309.733239] busadddriver+0x151/0x290 <4> [309.733244] driverregister+0x5e/0x130 <4> [309.733247] _pciregisterdriver+0x7d/0x90 <4> [309.733251] i915pciregisterdriver+0x23/0x30 [i915] <4> [309.733413] i915init+0x34/0x120 [i915] <4> [309.733655] dooneinitcall+0x62/0x3f0 <4> [309.733667] doinitmodule+0x97/0x2a0 <4> [309.733671] loadmodule+0x25ff/0x2890 <4> [309.733688] initmodulefromfile+0x97/0xe0 <4> [309.733701] idempotentinitmodule+0x118/0x330 <4> [309.733711] _x64sysfinitmodule+0x77/0x100 <4> [309.733715] x64syscall+0x1f37/0x2650 <4> [309.733719] dosyscall64+0x91/0x180 <4> [309.733763] entrySYSCALL64afterhwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]---

That scenario is most easily reproducible with igt@i915moduleload@reload-with-fault-injection.

Fix the issue by moving the cleanup step to driver release path.

(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)(CVE-2025-37754)

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

drm/nouveau: prime: fix ttmbodelayed_delete oops

Fix an oops in ttmbodelayed_delete which results from dererencing a dangling pointer:

Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216 Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttmbodelayeddelete [ttm] RIP: 0010:dmaresviterfirstunlocked+0x55/0x290 Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x26 ? dieaddr+0x3d/0x70 ? excgeneralprotection+0x159/0x460 ? asmexcgeneralprotection+0x27/0x30 ? dmaresviterfirstunlocked+0x55/0x290 dmaresvwaittimeout+0x56/0x100 ttmbodelayeddelete+0x69/0xb0 [ttm] processonework+0x217/0x5c0 workerthread+0x1c8/0x3d0 ? applywqattrscleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreadsonlinecpu+0x140/0x140 retfromfork+0x40/0x70 ? kthreadsonlinecpu+0x140/0x140 retfromfork_asm+0x11/0x20 </TASK>

The cause of this is:

• drmprimegemdestroy calls dmabufput(dmabuf) which releases the reference to the shared dmabuf. The reference count is 0, so the dmabuf is destroyed, which in turn decrements the corresponding amdgpubo reference count to 0, and the amdgpubo is destroyed - calling drmgemobjectrelease then dmaresvfini (which destroys the reservation object), then finally freeing the amdgpubo.

• nouveaubo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpubo.

• nouveaugemobjectdel calls ttmboput(&nvbo->bo) which calls ttmborelease, which schedules ttmbodelayeddelete.

• ttmbodelayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.

Fix this by moving the drmprimegemdestroy call from nouveaugemobjectdel to nouveaubodelttm. This ensures that it will be run after ttmbodelayeddelete.(CVE-2025-37765)

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

virtiofs: add filesystem context source name check

In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.(CVE-2025-37773)

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

hfs/hfsplus: fix slab-out-of-bounds in hfsbnoderead_key

Syzbot reported an issue in hfs subsystem:

BUG: KASAN: slab-out-of-bounds in memcpyfrompage include/linux/highmem.h:423 [inline] BUG: KASAN: slab-out-of-bounds in hfsbnoderead fs/hfs/bnode.c:35 [inline] BUG: KASAN: slab-out-of-bounds in hfsbnoderead_key+0x314/0x450 fs/hfs/bnode.c:70 Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102

Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 memcpyfrompage include/linux/highmem.h:423 [inline] hfsbnoderead fs/hfs/bnode.c:35 [inline] hfsbnodereadkey+0x314/0x450 fs/hfs/bnode.c:70 hfsbrecinsert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfscatcreate+0x41d/0xa50 fs/hfs/catalog.c:118 hfsmkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdir fs/namei.c:4300 [inline] _sesysmkdir fs/namei.c:4298 [inline] _x64sysmkdir+0x6c/0x80 fs/namei.c:4298 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7fbdd6057a99

Add a check for key length in hfsbnoderead_key to prevent out-of-bounds memory access. If the key length is invalid, the key buffer is cleared, improving stability and reliability.(CVE-2025-37782)

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

fbdev: omapfb: Add 'plane' value check

Function dispcovlsetup is not intended to work with the value OMAPDSSWB of the enum parameter plane.

The value of this parameter is initialized in dssinitoverlays and in the current state of the code it cannot take this value so it's not a real problem.

For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not.

For example, in dispcovlsetupglobalalpha it may lead to buffer overflow.

Add check for this value.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2025-37851)

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

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplay_create()

Add error handling to propagate amdgpucgscreatedevice() failures to the caller. When amdgpucgscreatedevice() fails, release hwmgr and return -ENOMEM to prevent null pointer dereference.

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

fs/jfs: Prevent integer overflow in AG size calculation

The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing.

On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures

Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize;

This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37858)

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

RDMA/core: Silence oversized kvmalloc() warning

syzkaller triggered an oversized kvmalloc() warning. Silence it by adding _GFPNOWARN.

syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 kvmallocnodenoprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: crepro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kvmallocnodenoprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ibumemodpget+0x1f6/0x390 mlx5ibregusermr+0x1e8/0x450 ibuverbsregmr+0x28b/0x440 ibuverbswrite+0x7d3/0xa30 vfswrite+0x1ac/0x6c0 ksyswrite+0x134/0x170 ? _sanitizercovtracepc+0x1c/0x50 dosyscall64+0x50/0x110 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-37867)

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

pdscore: make waitcontext part of q_info

Make the waitcontext a full part of the qinfo struct rather than a stack variable that goes away after pdscadminqpost() is done so that the context is still available after the wait loop has given up.

There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to completeall() the completion context that had been created on the stack in pdscadminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth.(CVE-2025-37886)

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

jfs: reject on-disk inodes of an unsupported type

Syzbot has reported the following BUG:

kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clearinode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: <TASK> ? _diebody+0x5f/0xb0 ? die+0x9e/0xc0 ? dotrap+0x15a/0x3a0 ? clearinode+0x168/0x190 ? doerrortrap+0x1dc/0x2c0 ? clearinode+0x168/0x190 ? _pfxdoerrortrap+0x10/0x10 ? reportbug+0x3cd/0x500 ? handleinvalidop+0x34/0x40 ? clearinode+0x168/0x190 ? excinvalidop+0x38/0x50 ? asmexcinvalidop+0x1a/0x20 ? clearinode+0x57/0x190 ? clearinode+0x167/0x190 ? clearinode+0x168/0x190 ? clearinode+0x167/0x190 jfsevictinode+0xb5/0x440 ? _pfxjfsevictinode+0x10/0x10 evict+0x4ea/0x9b0 ? _pfxevict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? _pfxtxUpdateMap+0x10/0x10 jfslazycommit+0x49a/0xb80 ? rawspinunlockirqrestore+0x8f/0x140 ? lockdephardirqson+0x99/0x150 ? _pfxjfslazycommit+0x10/0x10 ? _pfxdefaultwakefunction+0x10/0x10 ? _kthreadparkme+0x169/0x1d0 ? _pfxjfslazycommit+0x10/0x10 kthread+0x2f2/0x390 ? _pfxjfslazycommit+0x10/0x10 ? _pfxkthread+0x10/0x10 retfromfork+0x4d/0x80 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

This happens when 'clearinode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copyfrom_dinode()'.(CVE-2025-37925)

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

perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.

When generating the MSRIA32PEBSENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBSENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest.

Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSRIA32DS_AREA, the CPU will hit page faults on address '0' when trying to record PEBS events.

The issue is most easily reproduced by running perf kvm top from before commit 7b100989b4f6 ("perf evlist: Remove evlistadddefault") (after which, perf kvm top effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intelguestgetmsrs() misconstrues a guest-owned PEBS event.

Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events.

Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM and userspace, but missed the case where userspace is profiling only KVM.(CVE-2025-37936)

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

ftrace: Add condresched() to ftracegraphsethash()

When the kernel contains a large number of functions that can be traced, the loop in ftracegraphset_hash() may take a lot of time to execute. This may trigger the softlockup watchdog.

Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions.

This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.(CVE-2025-37940)

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

wifi: ath12k: Fix invalid data access in ath12kdprxhundecap_nwifi

In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12kdprxhundecapnwifi function for DPRXDECAPTYPENATIVEWIFI decap type and potentially resulting in invalid data access and memory corruption.

Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DPRXDECAPTYPENATIVE_WIFI decap type.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1(CVE-2025-37943)

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

iio: imu: stlsm6dsx: fix possible lockup in stlsm6dsxreadfifo

Prevent stlsm6dsxreadfifo from falling in an infinite loop in case patternlen is equal to zero and the device FIFO is not empty.(CVE-2025-37970)

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

block: fix resource leak in blkregisterqueue() error path

When registering a queue fails after blkmqsysfsregister() is successful but the function later encounters an error, we need to clean up the blkmq_sysfs resources.

Add the missing blkmqsysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.(CVE-2025-37980)