OESA-2025-2270

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

cifs: Fix integer overflow while processing closetimeo mount option

User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.

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

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

ksmbd: fix use-after-free in ksmbdfreework_struct

->interimentry of ksmbdwork could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)

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

ksmbd: fix use-after-free in kerberos authentication

Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbdfreeuser. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbdfreeuser but before sess->user is set to NULL.(CVE-2025-37924)

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

VMCI: fix race between vmcihostsetupnotify and vmcictxunsetnotify

During our test, it is found that a warning can be trigger in trygrabfolio as follow:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 trygrabfolio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:trygrabfolio+0x106/0x130 Call Trace: <TASK> followhugepmd+0x240/0x8e0 followpmdmask.constprop.0.isra.0+0x40b/0x5c0 followpudmask.constprop.0.isra.0+0x14a/0x170 followpagemask+0x1c2/0x1f0 _getuserpages+0x176/0x950 _guplongtermlocked+0x15b/0x1060 ? gupfast+0x120/0x1f0 gupfastfallback+0x17e/0x230 getuserpagesfast+0x5f/0x80 vmcihostunlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---

Digging into the source, context->notifypage may init by getuserpagesfast and can be seen in vmcictxunsetnotify which will try to putpage. However getuserpagesfast is not finished here and lead to following trygrab_folio warning. The race condition is shown as follow:

cpu0 cpu1 vmcihostdosetnotify vmcihostsetupnotify getuserpagesfast(uva, 1, FOLLWRITE, &context->notifypage); locklesspagesfrommm guppgdrange guphugepmd // update &context->notifypage vmcihostdosetnotify vmcictxunsetnotify notifypage = context->notifypage; if (notifypage) putpage(notifypage); // page is freed _guplongtermlocked _getuserpages followtranshugepmd trygrab_folio // warn here

To slove this, use local variable page to make notifypage can be seen after finish getuserpagesfast.(CVE-2025-38102)

In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcderrhandlingprepare() calls ufshcdrpmgetsync(). The latter function can only succeed if UFSHCDEHINPROGRESS is not set because resuming involves submitting a SCSI command and ufshcdqueuecommand() returns SCSIMLQUEUEHOSTBUSY if UFSHCDEHINPROGRESS is set. Fix this hang by setting UFSHCDEHINPROGRESS after ufshcdrpmgetsync() has been called instead of before.(CVE-2025-38119)

In the Linux kernel's vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member 'si' after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)

In the Linux kernel, a recursive locking issue was identified in the ptpvclockinuse() function. When reading ptp->nvclocks through ptp->nvclocksmux, it triggers a recursive lock call chain starting from nvclocksstore(), leading to a potential deadlock. The root cause is the redundant check for ptp->nvclocks in ptpvclockinuse(), as other functions already ensure ptp->n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)

In the Linux kernel, a vulnerability has been identified in the fbdev core component's fbcvt module. When mode->refresh is set to 0x80000000, in the fbfindmodecvt() function, cvt.frefresh becomes 0 due to overflow. This value is then passed to fbcvthperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)

In the Linux kernel's x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page->poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)

A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function corescsi3decodespeciport() unconditionally calls corescsi3lunaclundependitem() passing a potentially NULL destse_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)

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

bpf: Fix oob access in cgroup local storage

Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpfcgrunctx holds an bpfprogarrayitem which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpfgetlocal_storage() pick this up from the runtime context:

ctx = containerof(current->bpfctx, struct bpfcgrunctx, runctx); storage = ctx->progitem->cgroupstorage[stype];

if (stype == BPFCGROUPSTORAGESHARED) ptr = &READONCE(storage->buf)->data[0]; else ptr = thiscpuptr(storage->percpu_buf);

For the second program which was called from the originally attached one, this means bpfgetlocal_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.

To fix this issue, we need to extend bpfmapowner with an array of storagecookie[] to match on i) the exact maps from the original program if the second program was using bpfgetlocalstorage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)

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

pptp: ensure minimal skb length in pptp_xmit()

Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on pppsynctxmung") fixed pppsynctxmunge()

We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.

BUG: KMSAN: uninit-value in pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2290 [inline] pppinput+0x1d6/0xe60 drivers/net/ppp/pppgeneric.c:2314 pppoercvcore+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 pppoesendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x330/0x3d0 net/socket.c:727 _syssendmsg+0x893/0xd80 net/socket.c:2566 _syssendmsg+0x271/0x3b0 net/socket.c:2620 _syssendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)

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

padata: Fix pd UAF once and for all

There is a race condition/UAF in padatareorder that goes back to the initial commit. A reference count is taken at the start of the process in padatadoparallel, and released at the end in padataserial_worker.

This reference count is (and only is) required for padatareplace to function correctly. If padatareplace is never called then there is no issue.

In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock is released.

In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)

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

net/mlx5e: Remove skb secpath if xfrm state is not found

Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.

Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.

Subsequently, functions like _xfrmpolicycheck() attempt to access fields such as xfrminput_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.

This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.

BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7forupstreammindebug202505272244 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:_xfrmpolicycheck+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? trytowakeup+0x108/0x4c0 ? udp4liblookup2+0xbe/0x150 ? udpliblportinuse+0x100/0x100 ? _udp4liblookup+0x2b0/0x410 _xfrmpolicycheck2.constprop.0+0x11e/0x130 udpqueuercvoneskb+0x1d/0x530 udpunicastrcvskb+0x76/0x90 _udp4librcv+0xa64/0xe90 ipprotocoldeliverrcu+0x20/0x130 iplocaldeliverfinish+0x75/0xa0 iplocaldeliver+0xc1/0xd0 ? ipprotocoldeliverrcu+0x130/0x130 ipsublistrcv+0x1f9/0x240 ? iprcvfinishcore+0x430/0x430 iplistrcv+0xfc/0x130 _netifreceiveskblistcore+0x181/0x1e0 netifreceiveskblistinternal+0x200/0x360 ? mlx5ebuildrxskb+0x1bc/0xda0 [mlx5core] groreceiveskb+0xfd/0x210 mlx5ehandlerxcqempwrq+0x141/0x280 [mlx5core] mlx5epollrxcq+0xcc/0x8e0 [mlx5core] ? mlx5ehandlerxdim+0x91/0xd0 [mlx5core] mlx5enapipoll+0x114/0xab0 [mlx5core] _napipoll+0x25/0x170 netrxaction+0x32d/0x3a0 ? mlx5eqcompint+0x8d/0x280 [mlx5core] ? notifiercallchain+0x33/0xa0 handlesoftirqs+0xda/0x250 irqexitrcu+0x6d/0xc0 commoninterrupt+0x81/0xa0 </IRQ>(CVE-2025-38590)

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

Bluetooth: hcisync: fix double free in 'hcidiscoveryfilterclear()'

Function 'hcidiscoveryfilter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race:

'hcicmdsync_work()'

'updatepassivescan_sync()'

'hciupdatepassivescansync()'

 'hci_discovery_filter_clear()'
   kfree(uuids);

   <-------------------------preempted-------------------------------->
                                       'start_service_discovery()'

                                         'hci_discovery_filter_clear()'
                                           kfree(uuids); // DOUBLE FREE

   <-------------------------preempted-------------------------------->

  uuids = NULL;

To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires:

[ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOTMODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : _slabfree+0xf8/0x348 [ ] lr : _slabfree+0x48/0x348 ... [ ] Call trace: [ ] _slabfree+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] startservicediscovery+0x1d0/0x2c0 [ ] hcisocksendmsg+0x518/0x924 [ ] _socksendmsg+0x54/0x60 [ ] sockwriteiter+0x98/0xf8 [ ] doiterreadvwritev+0xe4/0x1c8 [ ] vfswritev+0x128/0x2b0 [ ] dowritev+0xfc/0x118 [ ] _arm64syswritev+0x20/0x2c [ ] invokesyscall+0x68/0xf0 [ ] el0svccommon.constprop.0+0x40/0xe0 [ ] doel0svc+0x1c/0x28 [ ] el0svc+0x30/0xd0 [ ] el0t64synchandler+0x100/0x12c [ ] el0t64sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)

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

md: make rdev_addable usable for rcu mode

Our testcase trigger panic:

BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: mdmisc mdstartsync RIP: 0010:rdevaddable+0x4d/0xf0 ... Call Trace: <TASK> mdstartsync+0x329/0x480 processonework+0x226/0x6d0 workerthread+0x19e/0x340 kthread+0x10f/0x250 retfromfork+0x14d/0x180 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0

mdsparesneedchange in mdstartsync will call rdevaddable which protected by rcureadlock/rcureadunlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronizercu in mdkickrdevfromarray. Fix this by using READONCE and check does rdev->mddev still alive.(CVE-2025-38621)

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

clk: davinci: Add NULL check in davincilpscclk_register()

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

Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.(CVE-2025-38635)

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

net/mlx5: Check device memory pointer before usage

Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5initonce() fails.(CVE-2025-38645)

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

comedi: fix race between polling and detaching

syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the waitqueuehead inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the waitqueuehead has been freed. We need to check there are no tasks queued on any of the subdevices' wait queues before allowing the device to be detached by the COMEDI_DEVCONFIG ioctl.

Tasks will read-lock dev->attach_lock before adding themselves to the subdevice wait queue, so fix the problem in the COMEDI_DEVCONFIG ioctl handler by write-locking dev->attach_lock before checking that all of the subdevices are safe to be deleted. This includes testing for any sleepers on the subdevices' wait queues. It remains locked until the device has been detached. This requires the comedi_device_detach() function to be refactored slightly, moving the bulk of it into new function comedi_device_detach_locked().

Note that the refactor of comedi_device_detach() results in comedi_device_cancel_all() now being called while dev->attach_lock is write-locked, which wasn't the case previously, but that does not matter.

Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.(CVE-2025-38687)

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

ftrace: Also allocate and copy hash for reading of filter files

Currently the reader of setftracefilter and setftracenotrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.

Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)