The Linux Kernel, the operating system core itself.
Security Fix(es):
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:
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:
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:
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:
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:
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:
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:
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:
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)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios
A kernel crash was observed when replacing free hugetlb folios:
BUG: kernel NULL pointer dereference, address: 0000000000000028 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 28 UID: 0 PID: 29639 Comm: testcma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary) RIP: 0010:allocanddissolvehugetlbfolio+0x1d/0x1f0 RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000 RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000 RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000 R10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000 R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004 FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0 Call Trace: <TASK> replacefreehugepagefolios+0xb6/0x100 alloccontigrangenoprof+0x18a/0x590 ? srsoreturnthunk+0x5/0x5f ? downread+0x12/0xa0 ? srsoreturnthunk+0x5/0x5f cmarangealloc.constprop.0+0x131/0x290 _cmaalloc+0xcf/0x2c0 cmaallocwrite+0x43/0xb0 simpleattrwritexsigned.constprop.0.isra.0+0xb2/0x110 debugfsattrwrite+0x46/0x70 fullproxywrite+0x62/0xa0 vfswrite+0xf8/0x420 ? srsoreturnthunk+0x5/0x5f ? filpflush+0x86/0xa0 ? srsoreturnthunk+0x5/0x5f ? filpclose+0x1f/0x30 ? srsoreturnthunk+0x5/0x5f ? dodup2+0xaf/0x160 ? srsoreturnthunk+0x5/0x5f ksyswrite+0x65/0xe0 dosyscall64+0x64/0x170 entrySYSCALL64afterhwframe+0x76/0x7e
There is a potential race between _updateandfreehugetlbfolio() and replacefreehugepagefolios():
CPU1 CPU2 _updateandfreehugetlbfolio replacefreehugepagefolios foliotesthugetlb(folio) -- It's still hugetlb folio.
_folioclearhugetlb(folio) hugetlbfreefolio(folio) h = foliohstate(folio) -- Here, h is NULL pointer
When the above race condition occurs, foliohstate(folio) returns NULL, and subsequent access to this NULL pointer will cause the system to crash. To resolve this issue, execute foliohstate(folio) under the protection of the hugetlblock lock, ensuring that foliohstate(folio) does not return NULL.(CVE-2025-38050)
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:
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)
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macbhalttx.
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.(CVE-2025-38094)
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: insert memory barrier before updating num_fences
smpstoremb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.(CVE-2025-38095)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Disable SCO support if READVOICESETTING is unsupported/broken
A SCO connection without the proper voice_setting can cause the controller to lock up.(CVE-2025-38099)
In the Linux kernel, the following vulnerability has been resolved:
netsched: red: fix a race in _red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 | | [5]: lock root | [6]: rehash | [7]: qdisctreereduce_backlog() | This can be abused to underflow a parent's qlen.
Calling qdiscpurgequeue() instead of qdisctreeflush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38108)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete
This reworks MGMTOPREMOVEADVMONITOR to not use mgmtpendingadd to avoid crashes like bellow:
================================================================== BUG: KASAN: slab-use-after-free in mgmtremoveadvmonitorcomplete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341
CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xd2/0x2b0 mm/kasan/report.c:521 kasanreport+0x118/0x150 mm/kasan/report.c:634 mgmtremoveadvmonitorcomplete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hcicmdsyncwork+0x261/0x3a0 net/bluetooth/hcisync.c:334 processonework kernel/workqueue.c:3238 [inline] processscheduledworks+0xade/0x17b0 kernel/workqueue.c:3321 workerthread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 5987: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x93/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x230/0x3d0 mm/slub.c:4358 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1039 [inline] mgmtpendingnew+0x65/0x240 net/bluetooth/mgmtutil.c:252 mgmtpendingadd+0x34/0x120 net/bluetooth/mgmtutil.c:279 removeadvmonitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x219/0x270 net/socket.c:727 sockwriteiter+0x258/0x330 net/socket.c:1131 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x548/0xa90 fs/readwrite.c:686 ksyswrite+0x145/0x250 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64after_hwframe+0x77/0x7f
Freed by task 5989: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x46/0x50 mm/kasan/generic.c:576 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x62/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2380 [inline] slabfree mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmtpendingforeach+0xc9/0x120 net/bluetooth/mgmtutil.c:242 mgmtindexremoved+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hcisockbind+0xbe9/0x1000 net/bluetooth/hcisock.c:1314 _sysbindsocket net/socket.c:1810 [inline] _sysbind+0x2c3/0x3e0 net/socket.c:1841 _dosysbind net/socket.c:1846 [inline] _sesysbind net/socket.c:1844 [inline] _x64sysbind+0x7a/0x90 net/socket.c:1844 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2025-38118)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (asus-ec-sensors) check sensor index in read_string()
Prevent a potential invalid memory access when the requested sensor is not found.
findecsensorindex() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to getsensor_info().
Add a proper check to return -EINVAL if sensor_index is negative.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
groeck: Return error code returned from findecsensor_index
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '_be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: <IRQ> showstack+0x52/0x5c dumpstacklvl+0x4a/0x63 dumpstack+0x10/0x16 ubsanepilogue+0x9/0x36 _ubsanhandleoutofbounds.cold+0x44/0x49 keyextractl3l4+0x82a/0x840 [openvswitch] ? kfreeskbmem+0x52/0xa0 keyextract+0x9c/0x2b0 [openvswitch] ovsflowkeyextract+0x124/0x350 [openvswitch] ovsvportreceive+0x61/0xd0 [openvswitch] ? kernelinitfreepages.part.0+0x4a/0x70 ? getpagefromfreelist+0x353/0x540 netdevportreceive+0xc4/0x180 [openvswitch] ? netdevportreceive+0x180/0x180 [openvswitch] netdevframehook+0x1f/0x40 [openvswitch] _netifreceiveskbcore.constprop.0+0x23a/0xf00 _netifreceiveskblistcore+0xfa/0x240 netifreceiveskblistinternal+0x18e/0x2a0 napicompletedone+0x7a/0x1c0 bnxtpoll+0x155/0x1c0 [bnxten] _napipoll+0x30/0x180 netrxaction+0x126/0x280 ? bnxtmsix+0x67/0x80 [bnxten] handlesoftirqs+0xda/0x2d0 irqexitrcu+0x96/0xc0 common_interrupt+0x8e/0xa0 </IRQ>(CVE-2025-38146)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
Set the size to 6 instead of 2, since 'para' array is passed to 'rtwfwbtwificontrol(rtwdev, para[0], ¶[1])', which reads 5 bytes:
void rtwfwbtwificontrol(struct rtwdev *rtwdev, u8 opcode, u8 *data) { ... SETBTWIFICONTROLDATA1(h2cpkt, *data); SETBTWIFICONTROLDATA2(h2cpkt, *(data + 1)); ... SETBTWIFICONTROLDATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.(CVE-2025-38159)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on sbi->totalvalidblock_count
syzbot reported a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:decvalidblockcount+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fstruncatedatablocksrange+0xc8c/0x11a0 fs/f2fs/file.c:695 truncatednode+0x417/0x740 fs/f2fs/node.c:973 truncatenodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fstruncateinodeblocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fsdotruncateblocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fstruncateblocks+0x10d/0x300 fs/f2fs/file.c:838 f2fstruncate+0x417/0x720 fs/f2fs/file.c:888 f2fssetattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notifychange+0xbca/0xe90 fs/attr.c:552 dotruncate+0x222/0x310 fs/open.c:65 handletruncate fs/namei.c:3466 [inline] doopen fs/namei.c:3849 [inline] pathopenat+0x2e4f/0x35d0 fs/namei.c:4004 dofilpopen+0x284/0x4e0 fs/namei.c:4031 dosysopenat2+0x12b/0x1d0 fs/open.c:1429 dosysopen fs/open.c:1444 [inline] _dosyscreat fs/open.c:1522 [inline] _sesyscreat fs/open.c:1516 [inline] _x64syscreat+0x124/0x170 fs/open.c:1516 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/syscall_64.c:94
The reason is: in fuzzed image, sbi->totalvalidblock_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.(CVE-2025-38163)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: Discard stale CPU state when handling SME traps
The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIFSME set and TIFFOREIGNFPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from dosmeacc() where SME traps are not expected while TIFSME is set:
| /* With TIFSME userspace shouldn't generate any traps */ | if (testandsetthreadflag(TIFSME)) | WARN_ON(1);
This is very similar to the SVE issue we fixed in commit:
751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")
The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g.
| void dosmeacc(unsigned long esr, struct ptregs *regs) | { | // Trap on CPU 0 with TIFSME clear, SME traps enabled | // task->fpsimdcpu is 0. | // percpuptr(&fpsimdlaststate, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIFFOREIGNFPSTATE is set. | | getcpufpsimdcontext(); | | /* With TIFSME userspace shouldn't generate any traps */ | if (testandsetthreadflag(TIFSME)) | WARNON(1); | | if (!testthreadflag(TIFFOREIGNFPSTATE)) { | unsigned long vqminusone = | svevqfromvl(taskgetsmevl(current)) - 1; | smesetvq(vqminusone); | | fpsimdbindtasktocpu(); | } | | putcpufpsimdcontext(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimdcpu is still 0 | // If percpuptr(&fpsimdlaststate, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIFFOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }
Fix the case where the state is not live and TIFFOREIGNFPSTATE is set by calling fpsimdflushtaskstate() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIFFOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
Note: this was originallly posted as [1].
Rutland: rewrite commit message
In the Linux kernel, the following vulnerability has been resolved:
ublk: santizize the arguments from userspace when adding a device
Sanity check the values for queue depth and number of queues we get from userspace when adding a device.(CVE-2025-38182)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix panic caused by NULL-PMD in hugepteoffset()
ERROR INFO:
CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] hugepteoffset+0x3c/0x58 [<900000000057fd4c>] hugetlbfollowpagemask+0x74/0x438 [<900000000051fee8>] _getuserpages+0xe0/0x4c8 [<9000000000522414>] faultinpagerange+0x84/0x380 [<9000000000564e8c>] madvisevmabehavior+0x534/0xa48 [<900000000056689c>] domadvise+0x1bc/0x3e8 [<9000000000566df4>] sysmadvise+0x24/0x38 [<90000000015b9e88>] dosyscall+0x78/0x98 [<9000000000221f18>] handlesyscall+0xb8/0x158
In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.(CVE-2025-38195)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcureadlocktraceheld() in bpfmaplookuppercpuelem()
bpfmaplookuppercpuelem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpfmaplookuppercpuelem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpfmaplookuppercpuelem(), because the bpf program only holds rcureadlock_trace lock. Therefore, add the missed check.(CVE-2025-38202)
{ "severity": "High" }
{ "src": [ "kernel-6.6.0-100.0.0.103.oe2403sp1.src.rpm" ], "x86_64": [ "bpftool-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "bpftool-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-debugsource-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-devel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-headers-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-source-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-tools-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-tools-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "kernel-tools-devel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "perf-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "python3-perf-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm", "python3-perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm" ], "aarch64": [ "bpftool-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "bpftool-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-debugsource-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-devel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-headers-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-source-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-tools-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-tools-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "kernel-tools-devel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "perf-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "python3-perf-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm", "python3-perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm" ] }