The Linux Kernel, the operating system core itself.

Security Fix(es):

A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)

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

cdx: Fix possible UAF error in driveroverrideshow()

Fixed a possible UAF problem in driveroverrideshow() in drivers/cdx/cdx.c

This function driveroverrideshow() is part of DEVICEATTRRW, which includes both driveroverrideshow() and driveroverridestore(). These functions can be executed concurrently in sysfs.

The driveroverridestore() function uses driversetoverride() to update the driveroverride value, and driversetoverride() internally locks the device (devicelock(dev)). If driveroverrideshow() reads cdxdev->driveroverride without locking, it could potentially access a freed pointer if driveroverridestore() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users.

Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues.

This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations.(CVE-2025-21915)

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

fs/ntfs3: Prevent integer overflow in hdrfirstde()

The "deoff" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINTMAX - 16 then the check does work as intended because of an integer overflow.(CVE-2025-22080)

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

ext4: fix off-by-one error in do_split

Syzkaller detected a use-after-free issue in ext4insertdentry that was caused by out-of-bounds access due to incorrect splitting in do_split.

BUG: KASAN: use-after-free in ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4insertdentry+0x36a/0x6d0 fs/ext4/namei.c:2109 adddirenttobuf+0x3d9/0x750 fs/ext4/namei.c:2154 makeindexeddir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4addnondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfssymlink+0x137/0x2e0 fs/namei.c:4615 dosymlinkat+0x222/0x3a0 fs/namei.c:4641 _dosyssymlink fs/namei.c:4662 [inline] _sesyssymlink fs/namei.c:4660 [inline] _x64syssymlink+0x7a/0x90 fs/namei.c:4660 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f </TASK>

The following loop is located right above 'if' statement.

for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }

'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.

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

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

ext4: fix OOB read when checking dotdot dir

Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).

ext4emptydir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4checkdirentry() and then uses its reclen member to compute the location of '..' dir entry (in ext4nextentry). It assumes the '..' dir entry fits into the same data block.

If the reclen of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4direntry2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4checkdir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.

Fix this by extending _ext4checkdirentry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).

Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.

This issue was found by syzkaller tool.

Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in ext4checkdirentry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dumpstacklvl+0xa7/0xd0 [ 38.595325] printaddressdescription.constprop.0+0x2c/0x3f0 [ 38.595339] ? _ext4checkdirentry+0x67e/0x710 [ 38.595349] printreport+0xaa/0x250 [ 38.595359] ? _ext4checkdirentry+0x67e/0x710 [ 38.595368] ? kasanaddrtoslab+0x9/0x90 [ 38.595378] kasanreport+0xab/0xe0 [ 38.595389] ? _ext4checkdirentry+0x67e/0x710 [ 38.595400] _ext4checkdirentry+0x67e/0x710 [ 38.595410] ext4emptydir+0x465/0x990 [ 38.595421] ? _pfxext4emptydir+0x10/0x10 [ 38.595432] ext4rmdir.part.0+0x29a/0xd10 [ 38.595441] ? _dquotinitialize+0x2a7/0xbf0 [ 38.595455] ? _pfxext4rmdir.part.0+0x10/0x10 [ 38.595464] ? _pfxdquotinitialize+0x10/0x10 [ 38.595478] ? downwrite+0xdb/0x140 [ 38.595487] ? _pfxdownwrite+0x10/0x10 [ 38.595497] ext4rmdir+0xee/0x140 [ 38.595506] vfsrmdir+0x209/0x670 [ 38.595517] ? lookuponeqstrexcl+0x3b/0x190 [ 38.595529] dormdir+0x363/0x3c0 [ 38.595537] ? _pfxdormdir+0x10/0x10 [ 38.595544] ? strncpyfromuser+0x1ff/0x2e0 [ 38.595561] _x64sysunlinkat+0xf0/0x130 [ 38.595570] dosyscall64+0x5b/0x180 [ 38.595583] entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-37785)

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

scsi: ufs: mcq: Add NULL check in ufshcdmcqabort()

A race can occur between the MCQ completion path and the abort handler: once a request completes, _blkmqfreerequest() sets rq->mqhctx to NULL, meaning the subsequent ufshcdmcqreqtohwq() call in ufshcdmcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash.

Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcdcmdinflight() check is removed.

This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcdabortone racing issue").

This is found by our static analysis tool KNighter.(CVE-2025-37828)

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

mm/hugetlb: unshare page tables during VMA split, not before

Currently, _splitvma() triggers hugetlb page table unsharing through vmops->maysplit(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split.

Fix it by explicitly calling into the hugetlb unshare logic from _splitvma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked.

An annoying detail is that we can now call into the helper hugetlbunsharepmds() from two different locking contexts:

1. from hugetlb_split(), holding:
   • mmap lock (exclusively)
   • VMA lock
   • file rmap lock (exclusively)
2. hugetlbunshareall_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock

Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back.

[(CVE-2025-38084)

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

x86/iopl: Cure TIFIOBITMAP inconsistencies

iobitmapexit() is invoked from exitthread() when a task exists or when a fork fails. In the latter case the exitthread() cleans up resources which were allocated during fork().

iobitmapexit() invokes taskupdateiobitmap(), which in turn ends up in tssupdateiobitmap(). tssupdateiobitmap() operates on the current task. If current has TIFIOBITMAP set, but no bitmap installed, tssupdateiobitmap() crashes with a NULL pointer dereference.

There are two issues, which lead to that problem:

1) iobitmapexit() should not invoke taskupdateio_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork().

2) A task should not have TIFIOBITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated.

 This happens when a kernel thread is created in the context of
 a user space thread, which has TIF_IO_BITMAP set as the thread
 flags are copied and the IO bitmap pointer is cleared.

 Other than in the failed fork() case this has no impact because
 kernel threads including IO workers never return to user space and
 therefore never invoke tss_update_io_bitmap().

Cure this by adding the missing cleanups and checks:

1) Prevent iobitmapexit() to invoke taskupdateio_bitmap() if the to be cleaned up task is not the current task.

2) Clear TIFIOBITMAP in copythread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in iobitmap_share().

For paranoia sake, add a warning into tssupdateio_bitmap() to catch the case, when that code is invoked with inconsistent state.(CVE-2025-38100)

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

crypto: marvell/cesa - Handle zero-length skcipher requests

Do not access random memory for zero-length skcipher requests. Just return 0.(CVE-2025-38173)

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

fbdev: Fix fbsetvar to prevent null-ptr-deref in fbvideomodeto_var

If fbaddvideomode() in fbsetvar() fails to allocate memory for fbvideomode, later it may lead to a null-ptr dereference in fbvideomodetovar(), as the fbinfo is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fbinfo->var.

================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fbvideomodetovar+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: displaytovar+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbconresize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resizescreen drivers/tty/vt/vt.c:1176 [inline] vcdoresize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbconmodechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbconupdatevcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 dofbioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fbioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfsioctl fs/ioctl.c:48 [inline] _dosysioctl fs/ioctl.c:753 [inline] _sesysioctl fs/ioctl.c:739 [inline] _x64sysioctl+0x19a/0x210 fs/ioctl.c:739 dosyscall_64+0x33/0x40 arch/x86/entry/common.c:46

entrySYSCALL64afterhwframe+0x67/0xd1

The reason is that fbinfo->var is being modified in fbsetvar(), and then fbvideomodetovar() is called. If it fails to add the mode to fbinfo->modelist, fbsetvar() returns error, but does not restore the old value of fbinfo->var. Restore fb_info->var on failure the same way it is done earlier in the function.

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

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

crypto: ccp - Fix crash when rebind ccp device for ccp.ko

When CONFIGCRYPTODEVCCPDEBUGFS is enabled, rebinding the ccp device causes the following crash:

$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind

[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: errorcode(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] startcreating+0x9f/0x1c0 [ 205.001533] debugfscreatedir+0x1f/0x170 [ 205.002769] ? srsoreturnthunk+0x5/0x5f [ 205.004000] ccp5debugfssetup+0x87/0x170 [ccp] [ 205.005241] ccp5init+0x8b2/0x960 [ccp] [ 205.006469] ccpdevinit+0xd4/0x150 [ccp] [ 205.007709] spinit+0x5f/0x80 [ccp] [ 205.008942] sppciprobe+0x283/0x2e0 [ccp] [ 205.010165] ? srsoreturnthunk+0x5/0x5f [ 205.011376] localpciprobe+0x4f/0xb0 [ 205.012584] pcideviceprobe+0xdb/0x230 [ 205.013810] reallyprobe+0xed/0x380 [ 205.015024] _driverprobedevice+0x7e/0x160 [ 205.016240] devicedriverattach+0x2f/0x60 [ 205.017457] bindstore+0x7c/0xb0 [ 205.018663] drvattrstore+0x28/0x40 [ 205.019868] sysfskfwrite+0x5f/0x70 [ 205.021065] kernfsfopwriteiter+0x145/0x1d0 [ 205.022267] vfswrite+0x308/0x440 [ 205.023453] ksyswrite+0x6d/0xe0 [ 205.024616] _x64syswrite+0x1e/0x30 [ 205.025778] x64syscall+0x16ba/0x2150 [ 205.026942] dosyscall64+0x56/0x1e0 [ 205.028108] entrySYSCALL64after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5

This patch sets ccpdebugfsdir to NULL after destroying it in ccp5debugfsdestroy, allowing the directory dentry to be recreated when rebinding the ccp device.

Tested on AMD Ryzen 7 1700X.(CVE-2025-38581)

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

drm/amd/pm: fix null pointer access

Writing a string without delimiters (' ', '\n', '\0') to the under gpuod/fanctrl sysfs or pppowerprofile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)

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

net: kcm: Fix race condition in kcm_unattach()

syzbot found a race condition when kcmunattach(psock) and kcmrelease(kcm) are executed at the same time.

kcmunattach() is missing a check of the flag kcm->txstopped before calling queue_work().

If the kcm has a reserved psock, kcmunattach() might get executed between cancelworksync() and unreservepsock() in kcmrelease(), requeuing kcm->txwork right before kcm gets freed in kcm_done().

Remove kcm->txstopped and replace it by the less error-prone disablework_sync().(CVE-2025-38717)

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

ALSA: usb-audio: Validate UAC3 power domain descriptors, too

UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)

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

smb: server: split ksmbdrdmastoplistening() out of ksmbdrdma_destroy()

We can't call destroyworkqueue(smbdirectwq); before stopsessions()!

Otherwise already existing connections try to use smbdirectwq as a NULL pointer.(CVE-2025-39692)

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

s390/sclp: Fix SCCB present check

Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation.

If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping.

Fix this by introducing a function that handles the NULL case before address translation.(CVE-2025-39694)

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

net, hsr: reject HSR frame if skb can't hold tag

Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG):

[ 45.390915] skbuff: skbunderpanic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridgeslave1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skbpanic+0x15b/0x1d0

<snip registers, remove unreliable trace>

[ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skbpush+0xcd/0xf0 [ 45.404726] brdevqueuepushxmit+0x7c/0x6c0 [ 45.406513] brforwardfinish+0x128/0x260 [ 45.408483] _brforward+0x42d/0x590 [ 45.409464] maybedeliver+0x2eb/0x420 [ 45.409763] brflood+0x174/0x4a0 [ 45.410030] brhandleframefinish+0xc7c/0x1bc0 [ 45.411618] brhandleframe+0xac3/0x1230 [ 45.413674] _netifreceiveskbcore.constprop.0+0x808/0x3df0 [ 45.422966] _netifreceiveskbonecore+0xb4/0x1f0 [ 45.424478] _netifreceiveskb+0x22/0x170 [ 45.424806] processbacklog+0x242/0x6d0 [ 45.425116] _napipoll+0xbb/0x630 [ 45.425394] netrxaction+0x4d1/0xcc0 [ 45.427613] handlesoftirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ>

This issue was found by syzkaller.

The panic happens in brdevqueuepushxmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skbpush() call, there's not enough headroom and skbpush() panics.

The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG).

Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers.

Alternative fix would be to check for enough headroom before skbpush() in brdevqueuepush_xmit().

In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network.

Further Details:

In the reproducer, the following network interface chain is set up:

┌────────────────┐ ┌────────────────┐ │ veth0tohsr ├───┤ hsrslave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1tohsr ┼───┤ hsrslave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘

To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---(CVE-2025-39703)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751)

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

crypto: afalg - Set merge to zero early in afalg_sendmsg

If an error causes afalgsendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into afalgsendmsg when it attempts to do a merge that can't be done.

Fix this by setting ctx->merge to zero near the start of the loop.(CVE-2025-39931)

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

ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed

If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "daidata->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apmlpassdaiprepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception:

qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at sndsocpcmdaiprepare on TXCODECDMATX3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apmgraphmediaformatpcm+0x48/0x120 (P) q6apmlpassdaiprepare+0x110/0x1b4 sndsocpcmdaiprepare+0x74/0x108 _socpcmprepare+0x44/0x160 dpcmbedai_prepare+0x124/0x1c0(CVE-2025-39938)

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

dm-stripe: fix a possible integer overflow

There's a possible integer overflow in stripeiohints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->iomin and limits->ioopt;(CVE-2025-39940)

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

crypto: afalg - Disallow concurrent writes in afalg_sendmsg

Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state.

Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.(CVE-2025-39964)

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

mm: swap: check for stable address space before operating on the VMA

It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XAZEROENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault

The issue is manifested from the below race between the fork() on a process and swapoff: fork(dupmmap()) swapoff(unusemm) --------------- ----------------- 1) Identical mtree is built using _mtdup().

2) copypterange()--> copynonpresentpte(): The dst mm is added into the mmlist to be visible to the swapoff operation.

3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XAZEROENTRY as a marker for this process that helps during exit_mmap().

                 4) swapoff is tried on the
                'mm' added to the 'mmlist' as
                part of the 2.

                 5) unuse_mm(), that iterates
                through the vma's of this 'mm'
                will hit the non-NULL zero entry
                and operating on this zero entry
                as a vma is resulting into the
                oops.

The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMFUNSTABLE, as it is set if mmstruct is not fully initialized in dup_mmap().

Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.(CVE-2025-39992)

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

net/smc: fix warning in smcrxsplice() when calling get_page()

smcloregisterdmb() allocates DMB buffers with kzalloc(), which are later passed to getpage() in smcrxsplice(). Since kmalloc memory is not page-backed, this triggers WARNONONCE() in getpage() and prevents holding a refcount on the buffer. This can lead to use-after-free if the memory is released before spliceto_pipe() completes.

Use folioalloc() instead, ensuring DMBs are page-backed and safe for getpage().

WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smcrxsplice+0xaf8/0xe20 [smc] CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE Hardware name: IBM 3931 A01 704 (z/VM 7.4.0) Krnl PSW : 0704e00180000000 000793161032696c (smcrxsplice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8 Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11 Call Trace: smcrxsplice+0xafc/0xe20 [smc] smcrxsplice+0x756/0xe20 [smc]) smcrxrecvmsg+0xa74/0xe00 [smc] smcspliceread+0x1ce/0x3b0 [smc] sockspliceread+0xa2/0xf0 dospliceread+0x198/0x240 splicefiletopipe+0x7e/0x110 dosplice+0x59e/0xde0 _dosplice+0x11a/0x2d0 _s390xsyssplice+0x140/0x1f0 _dosyscall+0x122/0x280 systemcall+0x6e/0x90 Last Breaking-Event-Address: smcrxsplice+0x960/0xe20 [smc] ---[ end trace 0000000000000000 ]---(CVE-2025-40012)

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

Input: uinput - zero-initialize uinputffupload_compat to avoid info leak

Struct ffeffectcompat is embedded twice inside uinputffuploadcompat, contains internal padding. In particular, there is a hole after struct ffreplay to satisfy alignment requirements for the following union member. Without clearing the structure, copytouser() may leak stack data to userspace.

Initialize ffupcompat to zero before filling valid fields.(CVE-2025-40035)

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

net: nfc: nci: Add parameter validation for packet data

Syzbot reported an uninitialized value bug in nciinitreq, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").

This bug arises due to very limited and poor input validation that was done at nicvalidsize(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of skb_buff->data which is not assigned anything yet.

Following the same silent drop of packets of invalid sizes at nic_valid_size(), add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in nci_nft_packet and effectively do a silent drop

Possible TODO: because we silently drop the packets, the call to nci_request will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export nci_request_cancel (or propagate error handling from the nft packets handlers).(CVE-2025-40043)

In the Linux kernel, a race condition vulnerability exists in the uiohvgeneric driver. The driver's default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang.

Specifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there's already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely.

The fix removes all instances where interruptmask is changed, while keeping the one in setevent() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048)

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

net: dlink: handle copy_thresh allocation failure

The driver did not handle failure of netdev_alloc_skb_ip_align(). If the allocation failed, dereferencing skb->protocol could lead to a NULL pointer dereference.

This patch tries to allocate skb. If the allocation fails, it falls back to the normal path.

Tested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053)

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

ocfs2: fix double free in userclusterconnect()

userclusterdisconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free.(CVE-2025-40055)

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

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290

CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1b0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x5f0 mm/kasan/report.c:482 kasanreport+0xca/0x100 mm/kasan/report.c:595 hfsplusuni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfspluslistxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfslistxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filenamelistxattr fs/xattr.c:958 [inline] pathlistxattrat+0x143/0x360 fs/xattr.c:988 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcb/0x4c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIGRAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK>

Allocated by task 14290: kasansavestack+0x24/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4333 [inline] _kmallocnoprof+0x219/0x540 mm/slub.c:4345 kmallocnoprof include/linux/slab.h:909 [inline] hfsplusfindinit+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfspluslistxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfslistxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filenamelistxattr fs/xattr.c:958 [inline] pathlistxattrat+0x143/0x360 fs/xattr.c:988 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcb/0x4c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64after_hwframe+0x77/0x7f

When hfsplusuni2asc is called from hfspluslistxattr, it actually passes in a struct hfsplusattrunistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory.

This patch introduces two warpper functions hfsplusuni2ascxattrstr and hfsplusuni2ascstr to process two unicode buffers, struct hfsplusattrunistr* and struct hfsplusunistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size.(CVE-2025-40082)

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

ksmbd: transport_ipc: validate payload size before reading handle

handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing.

This is a minimal fix to guard the initial handle read.(CVE-2025-40084)

In the Linux kernel, a buffer overflow vulnerability exists in the hfsplusstrcasecmp() function of the hfsplus filesystem. When the hfsplusstrcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088)

In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure setent is always present. Ensure that setent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109)

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

drm/vmwgfx: Fix a null-ptr access in the cursor snooper

Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it.

vmwcmdrescheck allows explicit invalid (SVGA3DINVALIDID) identifiers because some svga commands accept SVGA3DINVALIDID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmwcmdrescheck) but also check that the actual resource exists before trying to do something with it.

Fixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110)

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

net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock

Prevent USB runtime PM (autosuspend) for AX88772* in bind.

usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend.

The real hazard is that with runtime PM enabled, ndoopen() (under RTNL) may synchronously trigger autoresume (usbautopmgetinterface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues.

To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pmruntime_allow/forbid), making this approach robust against sysfs overrides.

Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.(CVE-2025-40120)

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

bpf: Enforce expectedattachtype for tailcall compatibility

Yinhao et al. recently reported:

Our fuzzer tool discovered an uninitialized pointer issue in the bpfprogtestrunxdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.

The test initializes two programs of BPFPROGTYPEXDP: progA acts as the entry point for bpfprogtestrunxdp() and its expectedattachtype can neither be of be BPFXDPDEVMAP nor BPFXDPCPUMAP. progA calls into a slot of a tailcall map it owns. progB's expectedattachtype must be BPFXDPDEVMAP to pass xdpisvalidaccess() validation. The program returns struct xdpmd's egressifindex, and the latter is only allowed to be accessed under mentioned expectedattachtype. progB is then inserted into the tailcall which progA calls.

The underlying issue goes beyond XDP though. Another example are programs of type BPFPROGTYPECGROUPSOCKADDR. sockaddrisvalidaccess() as well as sockaddrfuncproto() have different logic depending on the programs' expectedattachtype. Similarly, a program attached to BPFCGROUPINET4GETPEERNAME should not be allowed doing a tailcall into a program which calls bpfbind() out of BPF which is only enabled for BPFCGROUPINET4_CONNECT.

In short, specifying expectedattachtype allows to open up additional functionality or restrictions beyond what the basic bpfprogtype enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expectedattachtype in _bpfprogmapcompatible().

Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through devmapbpfprogrun() and cpu_map_bpf_prog_run() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123)

In the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blkmqsysfsregisterhctxs() is not checked in _blkmqupdatenrhwqueues() function. If sysfs creation for hctx fails, later changing the number of hwqueues or removing disk will trigger kernel warnings. The issue occurs because kobjectdel() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125)

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

sunrpc: fix null pointer dereference on zero-length checksum

In xdrstreamdecodeopaqueauth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gsskrb5verifymicv2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129)

In the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q->tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134)

In the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver's rtl8150setmulticast function. The vulnerability occurs because rtl8150setmulticast incorrectly calls netifstopqueue and netifwakequeue, causing TX queue synchronization issues. When rtl8150setmulticast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150startxmit, resulting in warnings and potential system instability.(CVE-2025-40140)

In the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in scoconnfree where if conn->sk is not set to NULL, it may lead to use-after-free in isoconnfree.(CVE-2025-40141)

A vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153)

In the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smpprocessorid() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smpprocessorid() function in the usbnetskbreturn function within preemptible context.(CVE-2025-40164)

In the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUGON in ext4escacheextent(). The issue is that the filesystem has an inode with both the INLINEDATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINEDATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4hasinlinedata() to return true, skipping extent tree validation in _ext4iget(). The unvalidated out-of-order extents then trigger a BUGON in ext4escache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167)

In the Linux kernel, the checkaluop() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the 'offset' field is a signed 16-bit integer. The original check condition 'insn->off > 1' was intended to ensure the offset is either 0 or 1 (for BPFMOD/BPFDIV operations). However, since 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169)

In the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from _nvmetfcsendls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171)

In the Linux kernel, a vulnerability has been identified in the net/ip6tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev->neededheadroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173)

In the Linux kernel, during asynchronous decryption in the TLS module, the tlsstrpmsg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176)

In the Linux kernel, there is a NULL pointer dereference vulnerability in the pidnrns function. When taskactivepidns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when taskactivepidns returns null in the pidnrns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is 'Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058', ultimately causing kernel panic and system crash.(CVE-2025-40178)

In the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179)

In the Linux kernel, a memory leak vulnerability exists. Cilium's BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpfredirectneigh() helper to forward packets, vxlan allocates metadatadst objects and attaches them to skb through fake dst entries. However, since bpfredirectneigh() only sets new dst entries without first dropping existing ones, the metadatadst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183)

In the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When newasoc->peer.adaptationind=0 and sctpulpeventmakeauthkey=0, and sctpulpeventmakeauthkey() returns 0, the variable aiev remains zero and this zero value will be dereferenced in the sctpulpevent_free() function.(CVE-2025-40187)

In the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4xattrinodeupdateref() reads an EA inode refcount that is already <= 0 and then applies refchange (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: eainode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4errorinode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190)

In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected". This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192)

In the Linux kernel, the following vulnerability has been resolved: cpufreq: intelpstate: Fix object lifecycle issue in updateqosrequest(). The cpufreqcpuput() call in updateqosrequest() takes place too early because the latter subsequently calls freqqosupdaterequest() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, updateqosrequest() is called under intelpstatedriverlock, so this issue does not matter for changing the intelpstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying updateqosrequest() to drop the reference to the policy later.(CVE-2025-40194)

In the Linux kernel, a buffer over-read vulnerability has been discovered in the parseapplysbmountoptions() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure smountopts is NUL terminated. The parseapplysbmountoptions() function has been hardened by treating smountopts as a potential __nonstring.(CVE-2025-40198)

In the Linux kernel, a vulnerability has been identified in the Squashfs filesystem's squashfsreadinode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a "WARNING in ovlcopyup_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200)

In the Linux kernel, the sysprlimit64() path has a race condition issue with the usage of tasklock(tsk->groupleader). When tsk != current and tsk is not a leader, this process can exit/exec and tasklock(tsk->groupleader) may use the already freed taskstruct. Another problem is that sysprlimit64() can race with mt-exec which changes ->groupleader. In this case doprlimit() may take the wrong lock, or (worse) ->groupleader may change between tasklock() and taskunlock(). The fix changes sysprlimit64() to take tasklistlock when necessary.(CVE-2025-40201)

In the Linux kernel, the IPMI subsystem's user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202)

In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)

In the Linux kernel, the netfilter nftobjref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFTOBJECT_SYNPROXY object type requires validation.(CVE-2025-40206)

In the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switchbrightnesswork delayed work accesses device->brightness and device->backlight, which are freed by acpivideodevunregisterbacklight() during device removal. If the work executes after acpivideobusunregisterbacklight() frees these resources, it causes a use-after-free when acpivideoswitchbrightness() dereferences device->brightness or device->backlight. The issue is fixed by calling canceldelayedworksync() for each device's switchbrightnesswork in acpivideobusremovenotify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211)