OESA-2025-2773

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

media: davinci: vpif: fix use-after-free on driver unbind

The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind.

This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns.

Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors.

Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names.(CVE-2021-47653)

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

mmc: core: use sysfs_emit() instead of sprintf()

sprintf() (still used in the MMC core for the sysfs output) is vulnerable to the buffer overflow. Use the new-fangled sysfs_emit() instead.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2022-49267)

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

Bluetooth: btmtksdio: fix use-after-free at btmtksdiorecvevent

We should not access skb buffer data anymore after hcirecvframe was called.

[ 39.634809] BUG: KASAN: use-after-free in btmtksdiorecvevent+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dumpbacktrace+0x0/0x3b8 [ 39.634999] showstack+0x20/0x2c [ 39.635016] dumpstacklvl+0x60/0x78 [ 39.635040] printaddressdescription+0x70/0x2f0 [ 39.635062] kasanreport+0x154/0x194 [ 39.635079] asanreportload1noabort+0x44/0x50 [ 39.635099] btmtksdiorecvevent+0x1b0/0x1c4 [ 39.635129] btmtksdiotxrxwork+0x6cc/0xac4 [ 39.635157] processonework+0x560/0xc5c [ 39.635177] workerthread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] retfromfork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasansavestack+0x38/0x68 [ 39.635319] kasansettrack+0x28/0x3c [ 39.635338] kasansetfreeinfo+0x28/0x4c [ 39.635357] kasanslabfree+0x104/0x150 [ 39.635374] _kasanslabfree+0x18/0x28 [ 39.635391] slabfreefreelisthook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skbfreehead+0x58/0x98 [ 39.635447] skbreleasedata+0x2f4/0x410 [ 39.635464] skbreleaseall+0x50/0x60 [ 39.635481] kfreeskb+0xc8/0x25c [ 39.635498] hcieventpacket+0x894/0xca4 [bluetooth] [ 39.635721] hcirxwork+0x1c8/0x68c [bluetooth] [ 39.635925] processonework+0x560/0xc5c [ 39.635951] workerthread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] retfromfork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)(CVE-2022-49470)

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

scsi: ufs: core: Fix handling of lrbp->cmd

ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes:

• In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths.

• In ufshcdreleasescsi_cmd(), do not clear lrbp->cmd.

See also scsisendeh_cmnd().

This commit prevents that the following appears if a command times out:

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcdqueuecommand+0x6f8/0x9a8 Call trace: ufshcdqueuecommand+0x6f8/0x9a8 scsisendehcmnd+0x2c0/0x960 scsiehtestdevices+0x100/0x314 scsiehreadydevs+0xd90/0x114c scsierror_handler+0x2b4/0xb70 kthread+0x16c/0x1e0(CVE-2023-53510)

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

soc: qcom: socinfo: Avoid out of bounds read of serial number

On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always:

db410c:/sys/devices/soc0$ cat serial_number 2644893864

The firmware used on MSM8916 exposes SOCINFOVERSION(0, 8), which does not have support for the serialnum field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the itemsize returned by SMEM, we need to make sure the *end* of the serialnum is within bounds, instead of comparing with the start offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM.

Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.(CVE-2024-58007)

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

jfs: add check read-only before txBeginAnon() call

Added a read-only check before calling txBeginAnon in extAlloc and extRecord. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes.

Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfsextent.c:78 jfsgetblock+0x340/0xb98 fs/jfs/inode.c:248 _blockwritebeginint+0x580/0x166c fs/buffer.c:2128 _blockwritebegin fs/buffer.c:2177 [inline] blockwritebegin+0x98/0x11c fs/buffer.c:2236 jfswritebegin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)

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

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]https://lkml.kernel.org/(CVE-2025-21693)

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

ksmbd: fix use-after-free in smb2_lock

If smblock->zerolen has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine.(CVE-2025-21945)

In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsatreesetup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After complete becomes true, dsatreesetupcpuports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user s PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsalinktouch(), will remain there, and will lead touse-after-free if dereferenced.If dsatreesetupswitches() returns -EPROBEDEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxxsetupupstreamport+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: _asanreportload8noabort+0x20/0x30 mv88e6xxxsetupupstreamport+0x240/0x568 mv88e6xxxsetup+0xebc/0x1eb0 dsaregisterswitch+0x1af4/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattachdriver+0x274/0x350Allocated by task 42: _kasankmalloc+0x84/0xa0 _kmalloccachenoprof+0x298/0x490 dsaswitchtouchports+0x174/0x3d8 dsaregisterswitch+0x800/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattachdriver+0x274/0x350Freed by task 42: _kasanslabfree+0x48/0x68 kfree+0x138/0x418 dsaregisterswitch+0x2694/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattachdriver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsatreesetuproutingtable() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsalinktouch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsatreeteardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsalink elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.(CVE-2025-37786)

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

ksmbd: fix use-after-free in session logoff

The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2sesssetup function which makes use of sess->user.(CVE-2025-37899)

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

usb: typec: ucsi: displayport: Fix NULL pointer access

This patch ensures that the UCSI driver waits for all pending tasks in the ucsidisplayportwork workqueue to finish executing before proceeding with the partner removal.(CVE-2025-37994)

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

netfilter: ipset: fix region locking in hash types

Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahashbucketstart(), ahashbucketend() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.(CVE-2025-37997)

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:

net/sched: schqfq: Fix race condition on qfqaggregate

A race condition can occur when 'agg' is modified in qfqchangeagg (called during qfqenqueue) while other threads access it concurrently. For example, qfqdumpclass may trigger a NULL dereference, and qfqdelete_class may cause a use-after-free.

This patch addresses the issue by:

1. Moved qfqdestroyclass into the critical section.

2. Added schtreelock protection to qfqdumpclass and qfqdumpclass_stats.(CVE-2025-38477)

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

efivarfs: Fix slab-out-of-bounds in efivarfsdcompare

Observed on kernel 6.6 (present on master as well):

BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasancheckrange+0xe8/0x190 _asanloadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfsdcompare+0x68/0xd8 _dlookuprcuopcompare+0x178/0x218 _dlookuprcu+0x1f8/0x228 dallocparallel+0x150/0x648 lookupopen.isra.0+0x5f0/0x8d0 openlastlookups+0x264/0x828 pathopenat+0x130/0x3f8 dofilpopen+0x114/0x248 dosysopenat2+0x340/0x3c0 _arm64sys_openat+0x120/0x1a0

If dentry->dname.len < EFIVARIABLEGUIDLEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename:

T1 T2 lookupopen ->lookup simplelookup d_add // invalid dentry is added to hash list

        lookup_open
         d_alloc_parallel
          __d_lookup_rcu
           __d_lookup_rcu_op_compare
            hlist_bl_for_each_entry_rcu
            // invalid dentry can be retrieved
             ->d_compare
              efivarfs_d_compare
              // oob

Fix it by checking 'guid' before cmp.(CVE-2025-39817)

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

media: tuner: xc5000: Fix use-after-free in xc5000_release

The original code uses canceldelayedwork() in xc5000release(), which does not guarantee that the delayed work item timersleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000release() may free the xc5000priv while timersleep is still active and attempts to dereference the xc5000priv.

A typical race condition is illustrated below:

CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000release() | xc5000dotimersleep() canceldelayedwork() | hybridtunerreleasestate(priv) | kfree(priv) | | priv = containerof() // UAF

Replace canceldelayedwork() with canceldelayedworksync() to ensure that the timersleep is properly canceled before the xc5000_priv memory is deallocated.

A deadlock concern was considered: xc5000release() is called in a process context and is not holding any locks that the timersleep work item might also need. Therefore, the use of the _sync() variant is safe here.

This bug was initially identified through static analysis.

hverkuil: fix typo in Subject: tunner -> tuner

In the Linux kernel, the Squashfs filesystem contains an uninitialized value vulnerability. When openbyhandleat() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfsget_parent() accesses the uninitialized parent member field, causing an uninitialized value access. The fix initializes the parent field with the invalid inode 0.(CVE-2025-40049)

In the Linux kernel, a use-after-free vulnerability exists in the TLS module's getnetdevforsock() function. This function is called during setsockopt() operations without RCU protection. Using skdst_get(sk)->dev could trigger use-after-free, potentially causing program crashes, unexpected value usage, or arbitrary code execution.(CVE-2025-40149)

A security vulnerability was discovered in the Linux kernel network subsystem involving inadequate RCU (Read-Copy-Update) protection for accesses to dst->dev. The affected functions include sksetupcaps(), skdstgsomaxsize(), ip6dstmtumaybeforward(), ipdstmtumaybeforward(), and ip4dsthoplimit(). An attacker could potentially exploit this vulnerability to cause privilege escalation or system crashes.(CVE-2025-40170)

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)