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 btmtksdio_recv_event

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

[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dump_backtrace+0x0/0x3b8 [ 39.634999] show_stack+0x20/0x2c [ 39.635016] dump_stack_lvl+0x60/0x78 [ 39.635040] print_address_description+0x70/0x2f0 [ 39.635062] kasan_report+0x154/0x194 [ 39.635079] __asan_report_load1_noabort+0x44/0x50 [ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4 [ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4 [ 39.635157] process_one_work+0x560/0xc5c [ 39.635177] worker_thread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] ret_from_fork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasan_save_stack+0x38/0x68 [ 39.635319] kasan_set_track+0x28/0x3c [ 39.635338] kasan_set_free_info+0x28/0x4c [ 39.635357] ____kasan_slab_free+0x104/0x150 [ 39.635374] __kasan_slab_free+0x18/0x28 [ 39.635391] slab_free_freelist_hook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skb_free_head+0x58/0x98 [ 39.635447] skb_release_data+0x2f4/0x410 [ 39.635464] skb_release_all+0x50/0x60 [ 39.635481] kfree_skb+0xc8/0x25c [ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth] [ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth] [ 39.635925] process_one_work+0x560/0xc5c [ 39.635951] worker_thread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] ret_from_fork+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 ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.

See also scsi_send_eh_cmnd().

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

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_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 SOCINFO_VERSION(0, 8), which does not have support for the serial_num 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 item_size returned by SMEM, we need to make sure the end of the serial_num 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/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+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 zswap_compress() and zswap_decompress(), 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 acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).

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

Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.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 cpus_read_lock() [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 acomp_ctx. 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 smb_lock->zero_len 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 dsa_tree_setup(), 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, dsa_tree_setup_cpu_ports() 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 dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), 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 addeddsa_link 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 smb2_sess_setup 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 ucsi_displayport_work 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: ahash_bucket_start(), ahash_bucket_end() 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, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). 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 __split_vma() 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 hugetlb_unshare_pmds() from two different locking contexts:

1. from hugetlb_split(), holding:
   • mmap lock (exclusively)
   • VMA lock
   • file rmap lock (exclusively)
2. hugetlb_unshare_all_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: sch_qfq: Fix race condition on qfq_aggregate

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

This patch addresses the issue by:

1. Moved qfq_destroy_class into the critical section.

2. Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats.(CVE-2025-38477)

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

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

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

BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0

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

T1 T2 lookup_open ->lookup simple_lookup 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 cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.

A typical race condition is illustrated below:

CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.

A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep 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 open_by_handle_at() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfs_get_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 get_netdev_for_sock() function. This function is called during setsockopt() operations without RCU protection. Using sk_dst_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 sk_setup_caps(), sk_dst_gso_max_size(), ip6_dst_mtu_maybe_forward(), ip_dst_mtu_maybe_forward(), and ip4_dst_hoplimit(). 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)