The Linux Kernel, the operating system core itself.

Security Fix(es):

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

xen: Fix the issue of resource not being properly released in xenbusdevprobe()

This patch fixes an issue in the function xenbusdevprobe(). In the xenbusdevprobe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.

To fix this issue, we followed the resource release logic of the xenbusdevremove() function by adding a new block failremove before the failput block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.

This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)

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

bpf: check changespktdata property for extension programs

When processing calls to global sub-programs, verifier decides whether to invalidate all packet pointers in current state depending on the changespktdata property of the global sub-program.

Because of this, an extension program replacing a global sub-program must be compatible with changespktdata property of the sub-program being replaced.

This commit: - adds changespktdata flag to struct bpfprogaux: - this flag is set in checkcfg() for main sub-program; - in jitsubprogs() for other sub-programs; - modifies bpfcheckattachbtfid() to check changespktdata flag; - moves call to checkattachbtfid() after the call to checkcfg(), because it needs changespktdata flag to be set:

bpf_check:
  ...                             ...
- check_attach_btf_id             resolve_pseudo_ldimm64
  resolve_pseudo_ldimm64   -->    bpf_prog_is_offloaded
  bpf_prog_is_offloaded           check_cfg
  check_cfg                     + check_attach_btf_id
  ...                             ...

The following fields are set by checkattachbtfid(): - env->ops - prog->aux->attachbtftrace - prog->aux->attachfuncname - prog->aux->attachfuncproto - prog->aux->dsttrampoline - prog->aux->mod - prog->aux->saveddstattachtype - prog->aux->saveddstprogtype - prog->expectedattachtype

Neither of these fields are used by resolvepseudoldimm64() or bpfprogoffloadverifierprep() (for netronome and netdevsim drivers), so the reordering is safe.(CVE-2024-58100)

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

efi: Don't map the entire mokvar table to determine its size

Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/earlyioremap.c:139 _earlyioremap+0xef/0x220 ... Call Trace: <TASK> ? _earlyioremap+0xef/0x220 ? _warn.cold+0x93/0xfa ? _earlyioremap+0xef/0x220 ? reportbug+0xff/0x140 ? earlyfixupexception+0x5d/0xb0 ? earlyidthandlercommon+0x2f/0x3a ? _earlyioremap+0xef/0x220 ? efimokvartableinit+0xce/0x1d0 ? setuparch+0x864/0xc10 ? startkernel+0x6b/0xa10 ? x8664startreservations+0x24/0x30 ? x8664startkernel+0xed/0xf0 ? commonstartup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.

Mapping the entire structure isn't actually necessary, as we don't ever need more than one entry header mapped at once.

Changes efimokvartable_init() to only map each entry header, not the entire table, when determining the table size. Since we're not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempting to verify it in place.(CVE-2025-21872)

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

llc: do not use skbget() before devqueue_xmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKB_SHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKB_SHARING, this is an orthogonal change.

We need to audit other skb_get() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> _skbpad+0x18a/0x610 net/core/skbuff.c:2466 _skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 _netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 _devxmitskb net/core/dev.c:4045 [inline] _devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsg_nosec net/socket.c:718 inline

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

dm-flakey: Fix memory corruption in optional corruptbiobyte feature

Fix memory corruption due to incorrect parameter being passed to bio_init(CVE-2025-21966)

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

md: fix mddev uaf while iterating all_mddevs list

While iterating allmddevs list from mdnotifyreboot() and mdexit(), listforeachentrysafe is used, and this can race with deletint the next mddev, causing UAF:

t1: spinlock //listforeachentrysafe(mddev, n, ...) mddevget(mddev1) // assume mddev2 is the next entry spinunlock t2: //remove mddev2 ... mddevfree spinlock listdel spinunlock kfree(mddev2) mddevput(mddev1) spinlock //continue dereference mddev2->allmddevs

The old helper foreachmddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex.

Hence switch to use listforeachentry, in this case mddevput() can free the mddev1 and it's not safe as well. Refer to mdseqshow(), also factor out a helper mddevputlocked() to fix this problem.(CVE-2025-22126)

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

dlm: prevent NPD when writing a positive value to event_done

douevent returns the value written to eventdone. In case it is a positive value, newlockspace would undo all the work, and lockspace would not be set. _dlmnewlockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 ("dlm: fix use count with multiple joins").

Down the line, devicecreatelockspace would pass that NULL lockspace to dlmfindlockspace_local, leading to a NULL pointer dereference.

Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.(CVE-2025-23131)

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

soc: samsung: exynos-chipid: Add NULL pointer check in exynoschipidprobe()

socdevattr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.(CVE-2025-23148)

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

media: venus: hfi_parser: refactor hfi packet parsing logic

wordscount denotes the number of words in total payload, while data points to payload of various property within it. When wordscount reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities.(CVE-2025-23156)

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

scsi: st: Fix array overflow in st_setup()

Change the array size to follow parms size instead of a fixed value.(CVE-2025-37857)

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

pdscore: remove write-after-free of clientid

A use-after-free error popped up in stress testing:

[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdscauxbusdevdel+0xef/0x160 [pdscore] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdscauxbusdevdel+0xef/0x160 [pdscore] [Mon Apr 21 21:21:33 2025] pdscremove+0xc0/0x1b0 [pdscore] [Mon Apr 21 21:21:33 2025] pcideviceremove+0x24/0x70 [Mon Apr 21 21:21:33 2025] devicereleasedriverinternal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driverdetach+0x45/0x80 [Mon Apr 21 21:21:33 2025] busremovedriver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pciunregisterdriver+0x1a/0x80

The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the client_id at this point, so simply remove the offending code.(CVE-2025-37916)

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

vxlan: vnifilter: Fix unlocked deletion of default FDB entry

When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").

Reproducer:

# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0

Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.

[1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlancore.c:417 vxlanfindmac+0x17f/0x1a0 [...] RIP: 0010:vxlanfindmac+0x17f/0x1a0 [...] Call Trace: <TASK> vxlanfdbdelete+0xbe/0x560 vxlanvnideletegroup+0x2ba/0x940 vxlanvnidel.isra.0+0x15f/0x580 vxlanprocessvnifilter+0x38b/0x7b0 vxlanvnifilterprocess+0x3bb/0x510 rtnetlinkrcvmsg+0x2f7/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 _socksendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _syssendmsg+0xfc/0x180 _syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2025-37921)

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

tracing: Fix oob write in traceseqto_buffer()

syzbot reported this bug:

BUG: KASAN: slab-out-of-bounds in traceseqtobuffer kernel/trace/trace.c:1830 [inline] BUG: KASAN: slab-out-of-bounds in tracingsplicereadpipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260

CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0xef/0x1a0 mm/kasan/generic.c:189 _asanmemcpy+0x3c/0x60 mm/kasan/shadow.c:106 traceseqtobuffer kernel/trace/trace.c:1830 [inline] tracingsplicereadpipe+0x6be/0xdd0 kernel/trace/trace.c:6822

....

It has been reported that traceseqtobuffer() tries to copy more data than PAGESIZE to buf. Therefore, to prevent this, we should use the smaller of traceseqused(&iter->seq) and PAGE_SIZE as an argument.(CVE-2025-37923)

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

ksmbd: fix use-after-free in ksmbdsessionrpc_open

A UAF issue can occur due to a race condition between ksmbdsessionrpcopen() and _sessionrpcclose(). Add rpc_lock to the session to protect it.(CVE-2025-37926)

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

mm/huge_memory: fix dereferencing invalid pmd migration entry

When migrating a THP, concurrent access to the PMD migration entry during a deferred split scan can lead to an invalid address access, as illustrated below. To prevent this invalid access, it is necessary to check the PMD migration entry and return early. In this context, there is no need to use pmdtoswpentry and pfnswapentryto_page to verify the equality of the target folio. Since the PMD migration entry is locked, it cannot be served as the target.

Mailing list discussion and explanation from Hugh Dickins: "An anonvma lookup points to a location which may contain the folio of interest, but might instead contain another folio: and weeding out those other folios is precisely what the "folio != pmdfolio((*pmd)" check (and the "risk of replacing the wrong folio" comment a few lines above it) is for."

BUG: unable to handle page fault for address: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:splithugepmdlocked+0x3b5/0x2b60 Call Trace: <TASK> trytomigrateone+0x28c/0x3730 rmapwalkanon+0x4f6/0x770 unmapfolio+0x196/0x1f0 splithugepagetolisttoorder+0x9f6/0x1560 deferredsplitscan+0xac5/0x12a0 shrinkerdebugfsscanwrite+0x376/0x470 fullproxywrite+0x15c/0x220 vfswrite+0x2fc/0xcb0 ksyswrite+0x146/0x250 dosyscall64+0x6a/0x120 entrySYSCALL64afterhwframe+0x76/0x7e

The bug is found by syzkaller on an internal kernel, then confirmed on upstream.(CVE-2025-37958)

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

iio: imu: stlsm6dsx: fix possible lockup in stlsm6dsxreadtagged_fifo

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

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

module: ensure that kobject_put() is safe for module type kobjects

In 'lookuporcreatemodulekobject()', an internal kobject is created using 'modulektype'. So call to 'kobjectput()' on error handling path causes an attempt to use an uninitialized completion pointer in 'modulekobjectrelease()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)

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

md/raid10: wait barrier before returning discard request with REQ_NOWAIT

raid10handlediscard should wait barrier before returning a discard bio which has REQNOWAIT. And there is no need to print warning calltrace if a discard bio has REQNOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace.(CVE-2025-40325)