OESA-2025-1870

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

crypto: iaa - Fix potential use after free bug

The freedevicecompressionmode(iaadevice, devicemode) function frees "devicemode" but it iss passed to iaacompressionmodes[i]->free() a few lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)

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

mm/migratedevice: don't add folio to be freed to LRU in migratedevice_finalize()

If migration succeeded, we called foliomigrateflags()->memcgroupmigrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.

Similarly, if migration failed, memcg_data of the dst folio is left unset.

If we call folioputbacklru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

# ./hmm-tests ... # RUN hmm.hmmdeviceprivate.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VMWARNONONCEFOLIO(!memcg && !memcgroupdisabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 foliolruveclockirqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:foliolruveclockirqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.116547][T14893] ? _warn.cold+0x110/0x210 [ 102.117461][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.118667][T14893] ? reportbug+0x1b9/0x320 [ 102.119571][T14893] ? handlebug+0x54/0x90 [ 102.120494][T14893] ? excinvalidop+0x17/0x50 [ 102.121433][T14893] ? asmexcinvalidop+0x1a/0x20 [ 102.122435][T14893] ? _wakeupklogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dumppage+0x4f/0x60 [ 102.124352][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.125500][T14893] foliobatchmovelru+0xd4/0x200 [ 102.126577][T14893] ? _pfxlruadd+0x10/0x10 [ 102.127505][T14893] _foliobatchaddandmove+0x391/0x720 [ 102.128633][T14893] ? _pfxlruadd+0x10/0x10 [ 102.129550][T14893] folioputbacklru+0x16/0x80 [ 102.130564][T14893] migratedevicefinalize+0x9b/0x530 [ 102.131640][T14893] dmirrormigratetodevice.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirrorfopsunlocked_ioctl+0x89b/0xc80

Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.

The new flow resembles what we have in migratefoliomove(): add the dst to the lru, rem ---truncated---(CVE-2025-21861)

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

drm/radeon: fix uninitialized size issue in radeonvcecs_parse()

On the off chance that command stream passed from userspace via ioctl() call to radeonvcecsparse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeonvcecsreloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value.

Play it safe and init 'tmp' with 0, thus ensuring that radeonvcecs_reloc() will catch an early error in cases like these.

Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.

(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)

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

arm64: Don't call NULL in docompatalignment_fixup()

doalignmentt32tohandler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xtnat xttcpudp xtconntrack nftchainnat xtMASQUERADE nfnat nfconntracknetlink nfconntrack nfdefragipv6 nfdefragipv4 xfrmuser xfrmalgo xtaddrtype nftcompat brnetfilter veth nvmefa> libcrc32c crc32cgeneric raid0 multipath linear dmmod dax raid1 mdmod xhcipci nvme xhcihcd nvmecore t10pi usbcore igb crc64rocksoft crc64 crct10dif crct10difgeneric crct10difce crct10difcommon usbcommon i2calgobit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : docompatalignmentfixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 doalignmentfault+0x40/0x50 domemabort+0x4c/0xa0 el0da+0x48/0xf0 el0t32synchandler+0x110/0x140 el0t32sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]---(CVE-2025-22033)

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

net: libwx: fix Tx L4 checksum

The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.(CVE-2025-22101)

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

bnxten: Mask the bdcnt field in the TX BD properly

The bdcnt field in the TX BD specifies the total number of BDs for the TX packet. The bdcnt field has 5 bits and the maximum number supported is 32 with the value 0.

CONFIGMAXSKBFRAGS can be modified and the total number of SKB fragments can approach or exceed the maximum supported by the chip. Add a macro to properly mask the bdcnt field so that the value 32 will be properly masked and set to 0 in the bd_cnd field.

Without this patch, the out-of-range bd_cnt value will corrupt the TX BD and may cause TX timeout.

The next patch will check for values exceeding 32.(CVE-2025-22108)

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

KVM: x86: Acquire SRCU in KVMGETMP_STATE to protect guest memory accesses

Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLEFAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->checknested_events(), and emuating the nested VM-Exit can access guest memory.

The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triplefaulteventtest selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpumpstateget() to trigger the scenario.

============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pilockdepfalse_pos-lock #3 Not tainted

include/linux/kvmhost.h:1058 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by triplefaultev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvmvcpu_ioctl+0x8b/0x9a0 [kvm]

stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triplefaultev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x144/0x190 kvmvcpugfntomemslot+0x156/0x180 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] readandcheckmsrentry+0x2e/0x180 [kvmintel] _nestedvmxvmexit+0x550/0xde0 [kvmintel] kvmchecknestedevents+0x1b/0x30 [kvm] kvmapicacceptevents+0x33/0x100 [kvm] kvmarchvcpuioctlgetmpstate+0x30/0x1d0 [kvm] kvmvcpuioctl+0x33e/0x9a0 [kvm] _x64sysioctl+0x8b/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>(CVE-2025-23141)

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

tpm: do not start chip while suspended

Checking TPMCHIPFLAGSUSPENDED after the call to tpmfindgetops() can lead to a spurious tpmchipstart() call:

[35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 i2ctransfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS GoogleMorphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:i2ctransfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? _warn+0xd4/0x260 [35985.503868] ? _i2ctransfer+0xbe/0x810 [35985.503874] ? reportbug+0xf3/0x210 [35985.503882] ? handlebug+0x63/0xb0 [35985.503887] ? excinvalidop+0x16/0x50 [35985.503892] ? asmexcinvalidop+0x16/0x20 [35985.503904] ? _i2ctransfer+0xbe/0x810 [35985.503913] tpmcr50i2ctransfermessage+0x24/0xf0 [35985.503920] tpmcr50i2cread+0x8e/0x120 [35985.503928] tpmcr50requestlocality+0x75/0x170 [35985.503935] tpmchipstart+0x116/0x160 [35985.503942] tpmtrygetops+0x57/0x90 [35985.503948] tpmfindgetops+0x26/0xd0 [35985.503955] tpmget_random+0x2d/0x80

Don't move forward with tpmchipstart() inside tpmtrygetops(), unless TPMCHIPFLAGSUSPENDED is not set. tpmfindget_ops() will return NULL in such a failure case.(CVE-2025-23149)

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

f2fs: fix to avoid out-of-bounds access in f2fstruncateinode_blocks()

syzbot reports an UBSAN issue as below:

------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '_le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleoutofbounds+0x121/0x150 lib/ubsan.c:429 getnid fs/f2fs/node.h:381 [inline] f2fstruncateinodeblocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fsdotruncateblocks+0x782/0x1030 fs/f2fs/file.c:808 f2fstruncateblocks+0x10d/0x300 fs/f2fs/file.c:836 f2fstruncate+0x417/0x720 fs/f2fs/file.c:886 f2fsfilewriteiter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aiowrite+0x56b/0x7c0 fs/aio.c:1633 iosubmitone+0x8a7/0x18a0 fs/aio.c:2052 _dosysiosubmit fs/aio.c:2111 [inline] _sesysiosubmit+0x171/0x2e0 fs/aio.c:2081 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7f238798cde9

index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long)

In f2fstruncateinodeblocks(), UBSAN detects that getnid() tries to access .i_nid[-924], it means both offset[0] and level should zero.

The possible case should be in f2fsdotruncateblocks(), we try to truncate inode size to zero, however, dn.ofsinnode is zero and dn.nodepage is not an inode page, so it fails to truncate inode page, and then pass zeroed freefrom to f2fstruncateinodeblocks(), result in this issue.

if (dn.ofs_in_node || IS_INODE(dn.node_page)) {
    f2fs_truncate_data_blocks_range(&dn, count);
    free_from += count;
}

I guess the reason why dn.nodepage is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fsgetnodepage() may load a non-inode block.

Let's add a sanity check for such condition to avoid out-of-bounds access issue.(CVE-2025-37739)

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

net: ti: icss-iep: Fix possible NULL pointer dereference for perout request

The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icssiepexit(), results in NULL pointer dereference for perout.

To fix the null pointer dereference issue, the icssiepperoutenablehw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptpperoutrequest structure, as its contents are irrelevant in this case.(CVE-2025-37784)

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

crypto: null - Use spin lock instead of mutex

As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.(CVE-2025-37808)

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

usb: dwc3: gadget: check that event count does not exceed event buffer length

The event count is read from register DWC3GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : _memcpy+0x114/0x180 lr : dwc3checkeventbuf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: _memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34(CVE-2025-37810)

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

spi: fsl-qspi: use devm function instead of driver remove

Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devmaddactionorreset() for driver cleanup to ensure the release sequence.

Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.(CVE-2025-37849)

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

drm/amdkfd: Fix mode1 reset crash issue

If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM.

There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash.

To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.(CVE-2025-37854)

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

pdscore: handle unsupported PDSCORECMDFW_CONTROL result

If the FW doesn't support the PDSCORECMDFWCONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command.

This happens because the stack variable fwlist is not 0 initialized which results in fwlist.numfwslots being a garbage value from the stack. Then the driver tries to access fwlist.fwnames[i] with i >= ARRAY_SIZE and runs off the end of the array.

Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)

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

drm/nouveau: Fix WARNON in nouveaufencecontextkill()

Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveaufencesignal(). However, in at least one other place, nouveaufencedone(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveaufenceupdate().

Should nouveaufencecontext_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence.

Have nouveaufencecontext_kill() check for a fence being signaled.(CVE-2025-37930)

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

octeon_ep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device, the driver calls the device-specific ndostop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndostop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, devclose should be called instead of the device-specific stop function.devclose internally calls ndostop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndostop is not called.(CVE-2025-37933)

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

objtool, media: dib8000: Prevent divide-by-zero in dib8000setdds()

If dib8000setdds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.

Fixes the following warning with an UBSAN kernel:

drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000tune() falls through to next function dib8096pcfg_DibRx()(CVE-2025-37937)

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

arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs

A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next.

On exit from a BPF program, emit the BHB mititgation sequence.

This is only applied for 'classic' cBPF programs that are loaded by seccomp.(CVE-2025-37948)

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

drm/v3d: Add job to pending list if the reset was skipped

When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete.

However, when timedout_job() is called, the job in question is removed from the pending list, which means it won't be automatically freed through free_job(). Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes.

This situation leads to a memory leak, as exposed in [1] and [2].

Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.(CVE-2025-37951)

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

arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users

Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB.

In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.(CVE-2025-37963)

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

iio: light: opt3001: fix deadlock due to concurrent flag access

The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutexlock stage and false at the mutexunlock stage. This results in the mutex not being unlocked, resulting in a deadlock.

Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.(CVE-2025-37968)

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

crypto: ecdsa - Harden against integer overflows in DIVROUNDUP()

Herbert notes that DIVROUNDUP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8):

X / 8 + !!(X & 7)

Based on this formula, introduce a generic DIVROUNDUPPOW2() macro and use it in lieu of DIVROUNDUP() for ->keysize() return values.

Additionally, use the macro in eccdigitsfrombytes(), whose "nbytes" parameter is a ->keysize() return value in some instances, or a user-specified ASN.1 length in the case of ecdsagetsignature_rs().(CVE-2025-37984)

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

parisc: Fix double SIGFPE crash

Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.

When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.

The issue can be reproduced with this test program:

root@parisc:~# cat fpe.c

static void fpefunc(int sig, siginfot *i, void *v) { sigsett set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIGUNBLOCK, &set, NULL); printf("GOT signal %d with sicode %ld\n", sig, i->sicode); }

int main() { struct sigaction action = { .sasigaction = fpefunc, .saflags = SARESTART|SASIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FEOVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }

root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception

root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=81921024, rlimmax=RLIMINFINITY}) = 0 ... rtsigaction(SIGFPE, {sahandler=0x1110a, samask=[], saflags=SARESTART|SASIGINFO}, NULL, 8) = 0 --- SIGFPE {sisigno=SIGFPE, sicode=FPEFLTOVF, siaddr=0x1078f} --- --- SIGFPE {sisigno=SIGFPE, sicode=FPEFLTOVF, siaddr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)

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

HID: uclogic: Add NULL check in uclogicinputconfigured()

devmkasprintf() returns NULL when memory allocation fails. Currently, uclogicinput_configured() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)

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

nfs: handle failure of nfsgetlock_context in unlock path

When memory is insufficient, the allocation of nfslockcontext in nfsgetlockcontext() fails and returns -ENOMEM. If we mistakenly treat an nfs4unlockdata structure (whose lctx member has been set to -ENOMEM) as valid and proceed to execute rpcruntask(), this will trigger a NULL pointer dereference in nfs4locku_prepare. For example:

BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpcasyncschedule RIP: 0010:nfs4lockuprepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> _rpcexecute+0xbc/0x480 rpcasyncschedule+0x2f/0x40 processonework+0x232/0x5d0 workerthread+0x1da/0x3d0 ? _pfxworkerthread+0x10/0x10 kthread+0x10d/0x240 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---

Free the allocated nfs4unlockdata when nfsgetlockcontext() fails and return NULL to terminate subsequent rpcruntask, preventing NULL pointer dereference.(CVE-2025-38023)

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel that originates from a wrong parameter order, which may cause null pointers to be dereferenced.(CVE-2025-38034)

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

bpf: copyverifierstate() should copy 'loop_entry' field

The bpfverifierstate.loopentry state should be copied by copyverifierstate(). Otherwise, .loopentry values from unrelated states would poison env->cur_state.

Additionally, env->stack should not contain any states with .loopentry != NULL. The states in env->stack are yet to be verified, while .loopentry is set for states that reached an equivalent state. This means that env->curstate->loopentry should always be NULL after pop_stack().

See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix.

This change has some verification performance impact for selftests:

File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)

arenahtab.bpf.o arenahtabllvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arenahtabasm.bpf.o arenahtabasm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arenalist.bpf.o arenalistdel 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o itersubprogcheckstacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o itersubprogiters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loopstatedeps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmemcacheiter.bpf.o opencodediter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifierbitsiter.bpf.o maxwords 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifieriteratingcallbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)

And significant negative impact for sched_ext:

File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)

bpf.bpf.o lavdinit 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layereddispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layereddump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layeredenqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dqdispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dqinit 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refreshlayercpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rustyselectcpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scxcentral.bpf.o centraldispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scxnest.bpf.o nestinit 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scxqmap.bpf.o qmapdispatch
---truncated---(CVE-2025-38060)

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

orangefs: Do not truncate file size

'len' is used to store the result of isizeread(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)

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

rseq: Fix segfault on registration when rseq_cs is non-zero

The rseqcs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseqcs field doesn't point to a valid struct rseq_cs.

The correct solution to this would be to fail the rseq registration when the rseqcs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseqcs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseqcs does point to a valid struct rseqcs.

What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)

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

libnvdimm/labels: Fix divide error in ndlabeldata_init()

If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver:

Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ndlabeldata_init+0x10e/0x800 [libnvdimm]

Code and flow:

1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver):

drivers/cxl/pmem.c: .configsize = mds->lsasize,

3) max_xfer is set to zero (nvdimm driver):

drivers/nvdimm/label.c: maxxfer = mint(sizet, ndd->nsarea.maxxfer, config_size);

4) A subsequent DIVROUNDUP() causes a division by zero:

drivers/nvdimm/label.c: /* Make our initial read size a multiple of maxxfer size */ drivers/nvdimm/label.c: readsize = min(DIVROUNDUP(readsize, maxxfer) * maxxfer, drivers/nvdimm/label.c- configsize);

Fix this by checking the config size parameter by extending an existing check.(CVE-2025-38072)

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

vhost-scsi: protect vq->log_used with vq->mutex

The vhost-scsi completion path may access vq->logbase when vq->logused is already set to false.

vhost-thread                       QEMU-thread

vhostscsicompletecmdwork() -> vhostaddused() -> vhostaddusedn() if (unlikely(vq->logused)) QEMU disables vq->logused via VHOSTSETVRINGADDR. mutexlock(&vq->mutex); vq->logused = false now! mutex_unlock(&vq->mutex);

                  QEMU gfree(vq->log_base)
    log_used()
    -> log_write(vq->log_base)

Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.

The control queue path has the same issue.(CVE-2025-38074)

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

ALSA: pcm: Fix race of buffer access at PCM OSS layer

The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of sndpcmformatsetsilence() with runtime->dmaarea. But this may lead to a UAF because the accessed runtime->dmaarea might be freed concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078)

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

drm/amd/display: Increase block_sequence array size

[Why] It's possible to generate more than 50 steps in hwssbuildfastsequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the blocksequence buffer and corrupts blocksequencesteps, causing a crash.

[How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)

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

spi-rockchip: Fix register out of bounds access

Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.(CVE-2025-38081)

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

drivers/rapidio/rio_cm.c: prevent possible heap overwrite

In

riocmcdevioctl(RIOCMCHANSEND) -> cmchanmsgsend() -> riocmchsend()

cmchanmsgsend() checks that userspace didn't send too much data but riocmchsend() failed to check that userspace sent sufficient data. The result is that riocmchsend() can write to fields in the riochchanhdr which were outside the bounds of the space which cmchanmsg_send() allocated.

Address this by teaching riocmchsend() to check that the entire riochchan_hdr was copied in from userspace.(CVE-2025-38090)

A vulnerability was found in Linux Kernel up to 6.14.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.This is going to have an impact on availability.Upgrading to version 5.10.238, 5.15.184, 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 0772a608d799ac0d127c0a36047a2725777aba9d/64675a9c00443b2e8af42af08c38fc1b78b68ba2/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4/3e64d35475aa21d13dab71da51de51923c1a3a48/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19769).(CVE-2025-38094)

A vulnerability has been found in Linux Kernel up to 6.1.139/6.6.91/6.12.29/6.14.7 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 3becc659f9cb76b481ad1fb71f54d5c8d6332d3f/c9d2b9a80d06a58f37e0dc8c827075639b443927/fe1bebd0edb22e3536cbc920ec713331d1367ad4/08680c4dadc6e736c75bc2409d833f03f9003c51/72c7d62583ebce7baeb61acce6057c361f73be4a is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19768).(CVE-2025-38095)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.12.30/6.14.8 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 6.12.31 or 6.14.9 eliminates this vulnerability. Applying the patch f48ee562c095e552a30b8d9cc0566a267b410f8a/ec1f015ec0c6fd250a6564e8452f7bb3160b9cb1/14d17c78a4b1660c443bae9d38c814edea506f62 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19764).(CVE-2025-38099)

A vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38108)

A vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System) and classified as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 3c9aba9cbdf163e2654be9f82d43ff8a04273962/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be/9df3e5e7f7e4653fd9802878cedc36defc5ef42d/32aa2fbe319f33b0318ec6f4fceb63879771a286/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38118)

A vulnerability classified as critical has been found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 6bf529ce84dccc0074dbc704e70aee4aa545057e/4e9e45746b861ebd54c03ef301da2cb8fc990536/19bd9cde38dd4ca1771aed7afba623e7f4247c8e/7eeb3df6f07a886bdfd52757ede127a59a8784dc/25be318324563c63cbd9cb53186203a08d2f83a1 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38142)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-129. The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 4b9a086eedc1fddae632310386098c12155e3d0a/ad17eb86d042d72a59fd184ad1adf34f5eb36843/f26fe7c3002516dd3c288f1012786df31f4d89e0/8ebcd311b4866ab911d1445ead08690e67f0c488/69541e58323ec3e3904e1fa87a6213961b1f52f4/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38146)

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

remoteproc: core: Clear tablesz when rprocshutdown

There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.

When starting rproc with a firmware not have resource table, memcpy(loaded_table, rproc->cached_table, rproc->table_sz) will trigger dump, because rproc->cachetable is set to NULL during the last stop operation, but rproc->tablesz is still valid.

This issue is found on i.MX8MP and i.MX9.

Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _pimemcpygeneric+0x110/0x22c lr : rprocstart+0x88/0x1e0 Call trace: _pimemcpygeneric+0x110/0x22c (P) rprocboot+0x198/0x57c statestore+0x40/0x104 devattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x120/0x1cc vfswrite+0x240/0x378 ksyswrite+0x70/0x108 _arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x30/0xcc el0t64synchandler+0x10c/0x138 el0t64sync+0x198/0x19c

Clear rproc->table_sz to address the issue.(CVE-2025-38152)

A vulnerability classified as problematic has been found in Linux Kernel up to 5.15.185/6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1ee8ea6937d13b20f90ff35d71ccc03ba448182d/68a1037f0bac4de9a585aa9c879ef886109f3647/74e18211c2c89ab66c9546baa7408288db61aa0d/c13255389499275bc5489a0b5b7940ccea3aef04/9febcc8bded8be0d7efd8237fcef599b6d93b788/4c2c372de2e108319236203cce6de44d70ae15cd is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19785).(CVE-2025-38159)

A vulnerability was found in Linux Kernel up to 6.15.2 (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 49bc7bf38e42cfa642787e947f5721696ea73ac3/f1b743c1955151bd392539b739a3ad155296be13/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d/25f3776b58c1c45ad2e50ab4b263505b4d2378ca/a39cc43efc1bca74ed9d6cf9e60b995071f7d178/65b3f76592aed5a43c4d79375ac097acf975972b/ccc28c0397f75a3ec9539cceed9db014d7b73869/05872a167c2cab80ef186ef23cc34a6776a1a30c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19781).(CVE-2025-38163)

A vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch de89368de3894a8db27caeb8fd902ba1c49f696a/43be952e885476dafb74aa832c0847b2f4f650c6/6103f9ba51a59afb5a0f32299c837377c5a5a693/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3/d3eaab3c70905c5467e5c4ea403053d67505adeb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19774).(CVE-2025-38170)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc2 (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 3162d8235c8c4d585525cee8a59d1c180940a968/0f8df5d6f25ac17c52a8bc6418e60a3e63130550/e2b2b7cf6368580114851cb3932f2ad9fbf23386/8c8472855884355caf3d8e0c50adf825f83454b2 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38182)

A vulnerability was found in Linux Kernel (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-252. The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch b427d98d55217b53c88643579fbbd8a4c351a105/985f086f281b7bbb6644851e63af1a17ffff9277/b5c7397b7fd125203c60b59860c168ee92291272/ee084fa96123ede8b0563a1b5a9b23adc43cd50d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38195)

A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 5e8c658acd1b7c186aeffa46bf08795e121f401a/07d7b8e7ef7d1f812a6211ed531947c56d09e95e/a7b477b64ef5e37cb08dd536ae07c46f9f28262e/f3b840fb1508a80cd8a0efb5c886ae1995a88b24/4d71f2c1e5263a9f042faa71d59515709869dc79/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e/61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38197)

A vulnerability was found in Linux Kernel up to 6.1.141/6.6.94/6.12.34/6.15.3 (Operating System). It has been declared as problematic.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 2f8c69a72e8ad87b36b8052f789da3cc2b2e186c/7bf4461f1c97207fda757014690d55a447ce859f/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22/b522d4d334f206284b1a44b0b0b2f99fd443b39b/d4965578267e2e81f67c86e2608481e77e9c8569 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38202)

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

media: cxusb: no longer judge rbuf when the write fails

syzbot reported a uninit-value in cxusbi2cxfer. [1]

Only when the write operation of usbbulkmsg() in dvbusbgenericrw() succeeds and rlen is greater than 0, the read operation of usbbulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf.

In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized.

[1] BUG: KMSAN: uninit-value in cxusbgpiotuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusbi2cxfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusbgpiotuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusbi2cxfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 _i2ctransfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2ctransfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2ctransferbufferflags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2cmastersend include/linux/i2c.h:109 [inline] i2cdevwrite+0x210/0x280 drivers/i2c/i2c-dev.c:183 doloopreadvwritev fs/readwrite.c:848 [inline] vfswritev+0x963/0x14e0 fs/readwrite.c:1057 dowritev+0x247/0x5c0 fs/readwrite.c:1101 _dosyswritev fs/readwrite.c:1169 [inline] _sesyswritev fs/readwrite.c:1166 [inline] _x64syswritev+0x98/0xe0 fs/readwrite.c:1166 x64syscall+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls64.h:21 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2025-38229)

A vulnerability was found in Linux Kernel up to 6.15.2/fc2778c42f99c7de52fc004157b3c3ee4dcc208a (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch ac49b7560b4b08b1e4043a29214cc7ad77644c00/e2d2115e56c4a02377189bfc3a9a7933552a7b0f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38279)

A vulnerability, which was classified as problematic, was found in Linux Kernel (Operating System).CWE is classifying the issue as CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66/ef92b96530d1731d9ac167bc7c193c683cd78fff/6f639c25bfad17d9fd7379ab91ff9678ea9aac85/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0/0b9bb52796b239de6792d0d68cdc6eb505ebff96/86bc9c742426a16b52a10ef61f5b721aecca2344 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38280)

A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926).(CVE-2025-38320)

A vulnerability was found in Linux Kernel up to 6.15.3/6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f/b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38322)

A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38346)

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

jfs: fix slab-out-of-bounds read in ea_get()

During the "sizecheck" label in eaget(), the code checks if the extended attribute list (xattr) size matches easize. If not, it logs "eaget: invalid extended attribute" and calls printhexdump().

Here, EALISTSIZE(eabuf->xattr) returns 4110417968, which exceeds INTMAX (2,147,483,647). Then easize is clamped:

int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));

Although clampt aims to bound easize between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).

The "size" is then passed to printhexdump() (called "len" in printhexdump()), it is passed as type sizet (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hexdumptobuffer(). In printhexdump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hexdumpto_buffer() on each iteration:

for (i = 0; i < len; i += rowsize) {
    linelen = min(remaining, rowsize);
    remaining -= rowsize;

    hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
               linebuf, sizeof(linebuf), ascii);

    ...
}

The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hexdumptobuffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hexdumptobuffer() in the following for loop:

for (j = 0; j < len; j++) {
        if (linebuflen < lx + 2)
            goto overflow2;
        ch = ptr[j];
    ...
}

To fix this we should validate "EALISTSIZE(eabuf->xattr)" before it is utilised.(CVE-2025-39735)

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

objtool, spi: amd: Fix out-of-bounds stack access in amdsetspi_freq()

If speedhz < AMDSPIMINHZ, amdsetspifreq() iterates over the entire amdspi_freq array without breaking out early, causing 'i' to go beyond the array bounds.

Fix that by stopping the loop when it gets to the last entry, so the low speedhz value gets clamped up to AMDSPIMINHZ.

Fixes the following warning with an UBSAN kernel:

drivers/spi/spi-amd.o: error: objtool: amdsetspifreq() falls through to next function amdspisetopcode()(CVE-2025-40014)