KernelScan.io

HIGH Introduced in 5.12

acrn Irqfd UAF

CVE-2026-97478

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI6.0MEDIUM

01

In the Linux kernel, the following vulnerability has been resolved: virt: acrn: Fix irqfd use-after-free during eventfd shutdown acrn_irqfd_deassign() and the eventfd EPOLLHUP wakeup can race and free the same struct hsm_irqfd: CPU0 CPU1 ---- ---- eventfd_release() wake_up_poll(EPOLLHUP) hsm_irqfd_wakeup() queue_work(&irqfd->shutdown) acrn_irqfd_deassign() hsm_irqfd_shutdown() list_del_init() eventfd_ctx_remove_wait_queue() eventfd_ctx_put() kfree(irqfd) hsm_irqfd_shutdown_work() container_of(work, ..., shutdown) irqfd->vm <-- use-after-free The deassign path freed the irqfd while a shutdown work item was already queued by EPOLLHUP (or vice versa), so the work item could resurrect a dangling pointer through container_of(). Switch to the lifetime model used by KVM irqfds: - Deassign/deinit only deactivate the irqfd: remove it from vm->irqfds under irqfds_lock and queue the cleanup work. - hsm_irqfd_shutdown_work() becomes the sole owner that unhooks the eventfd waitqueue entry, drops the eventfd reference and frees the irqfd. - A new HSM_IRQFD_FLAG_SHUTDOWN bit guarded by test_and_set_bit() ensures the cleanup work is queued at most once, no matter how many of {EPOLLHUP, deassign, deinit} fire concurrently. This is safe to call from the waitqueue callback, which runs with wqh->lock held and IRQs disabled and therefore cannot take irqfds_lock. - acrn_irqfd_deassign() flushes vm->irqfd_wq before returning so the eventfd is fully detached on return. acrn_irqfd_deinit() deactivates every irqfd, flushes the workqueue and only then destroys it, so no path can queue_work() onto a torn-down workqueue. - acrn_irqfd_assign() now installs the eventfd waitqueue entry and publishes the irqfd to vm->irqfds under irqfds_lock, so the irqfd is never visible to deassign/deinit before its waitqueue entry is in place, and any EPOLLHUP that fires in the assign window queues cleanup work that blocks on irqfds_lock until publication is done.

02

Engine v0.6.0

Risk summary

A race condition in the ACRN hypervisor driver's interrupt-fd mechanism allows a use-after-free when an eventfd is closed concurrently with an irqfd deassign operation. An attacker with root access to a system running the ACRN hypervisor could exploit this to corrupt kernel memory, potentially achieving code execution or causing a kernel panic.

Affecteddrivers/virt/acrn/irqfd.c (virt:acrn)

Vulnerability analysis

The ACRN hypervisor driver's interrupt-fd mechanism can free an internal object from one teardown path while a concurrent path still expects to use it. Closing an event descriptor can race with a manual removal request, so a pending cleanup task may run after the object has already been freed, causing the kernel to access released memory. The fix funnels all cleanup through a single background task that is guaranteed to run only once no matter how many events arrive, and ensures that task completes before the related resources are destroyed. A local attacker with access to the hypervisor management device can trigger this race; on typical systems that requires root privileges, and the target must be running the ACRN hypervisor.

03

BranchIntroducedFixed inPatch commit
6.125.126.12.1140e1152f68984
6.185.126.18.53d8156aacfcab
6.65.126.6.1606e9e007ee1df
mainline5.127.2666c7f9e0792

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Affected — no CIP fix yet (latest 6.12.112-cip33)
cip/6.1Affected — no CIP fix yet (latest 6.1.189-cip61)
cip/6.1-rtAffected — no CIP fix yet (latest 6.1.189-cip61-rt32)