Skip to main content

Linux Kernel CVE-2025-39966

HIGH
Race Condition (CWE-362)
2025-10-15 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.0
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.0 HIGH
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Local iommufd access with low privileges (AV:L/PR:L), timing-dependent workqueue race gives AC:H, and kernel heap UAF yields high C/I/A within an unchanged scope.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
6.1 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Red Hat
7.4 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:13 vuln.today
CVE Published
Oct 15, 2025 - 08:15 nvd
HIGH 7.0

DescriptionNVD

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

iommufd: Fix race during abort for file descriptors

fput() doesn't actually call file_operations release() synchronously, it puts the file on a work queue and it will be released eventually.

This is normally fine, except for iommufd the file and the iommufd_object are tied to gether. The file has the object as it's private_data and holds a users refcount, while the object is expected to remain alive as long as the file is.

When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount.

Fix this by putting the core code in charge of the file lifetime, and call __fput_sync() during abort to ensure that release() is called before kfree. __fput_sync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle.

If the object is successfully allocated then the file will hold a users refcount and the iommufd_object cannot be destroyed.

It is worth noting that close(); ioctl(IOMMU_DESTROY); doesn't have an issue because close() is already using a synchronous version of fput().

The UAF looks like this:

BUG: KASAN: slab-use-after-free in iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164

CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline] __refcount_dec include/linux/refcount.h:455 [inline] refcount_dec include/linux/refcount.h:476 [inline] iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 __fput+0x402/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f

AnalysisAI

Local privilege escalation via memory corruption in the Linux kernel's iommufd subsystem allows a low-privileged local user to trigger a use-after-free by racing the abort path of IOMMU object allocation. Because fput() defers file release to a workqueue while the code immediately kfree()s the tied iommufd_object, the deferred release() decrements a users refcount on already-freed memory, corrupting the slab. Only pre-release 6.17-rc kernels are affected; EPSS is 0.10% (1st percentile) and there is no public exploit identified at time of analysis.

Technical ContextAI

The flaw lives in iommufd, the modern Linux IOMMU userspace framework (drivers/iommu/iommufd/) that exposes IOMMU objects to userspace as file descriptors. Each iommufd_object is bound to a struct file: the file holds the object as private_data and a users refcount, and the object is expected to outlive nothing longer than the file. The root cause is CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization / race condition): fput() does not call file_operations->release() synchronously but queues it on a workqueue. When object allocation aborts before the fd is installed, the code fput()s the file and then immediately kfree()s the object, so the later workqueue-driven iommufd_eventq_fops_release() writes to freed memory (the KASAN report shows the refcount_dec on the users counter at eventq.c:376). The fix hands file lifetime to the iommufd core and uses __fput_sync() during abort so release() runs before kfree(); normal close()/IOMMU_DESTROY was never affected because close() already uses synchronous fput.

RemediationAI

Patch available per vendor advisory: update to a Linux kernel build that includes the iommufd abort fix, which moves file lifetime to the iommufd core and calls __fput_sync() during abort. Apply the upstream commits referenced at git.kernel.org (17195a7d754a5c6a31888702ca93f6f08f3383ad, 4e034bf045b12852a24d5d33f2451850818ba0c1, e4825368285e33d6360c6c6a6a10d2d83da06e55) or move off the 6.17-rc series to a fixed stable release; since only release candidates are affected, the simplest remediation is to not run 6.17-rc kernels in exposed environments. If you must run an unpatched affected kernel, the practical compensating control is to restrict access to the iommufd device (/dev/iommu) to trusted users or disable/unload the iommufd path where not required - the trade-off is loss of userspace IOMMU/VFIO functionality for workloads such as device passthrough. Because the vector is local and complexity is high, standard multi-tenant hardening (limiting untrusted local users) also reduces exposure.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Liberty Linux 10 Fixed
SUSE Liberty Linux 9 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

CVE-2025-39966 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy