CVE-2024-44957

What it actually does

Use of a mutex in irqfd_wakeup() under spin_lock_irqsave() context from eventfd_release() causes deadlock instead of safe synchronization when handling EPOLLHUP wakeups in Xen privcmd.

Why it matters to the business

Systems running affected Xen-based Linux kernels may experience hangs or unresponsiveness during eventfd operations, disrupting virtual machine management and requiring reboots.

How an attack unfolds

An attacker with local access triggers eventfd_release() paths that invoke wake_up_poll under spinlock while the mutex-held irqfd_wakeup attempts to acquire the same lock, leading to deadlock; no public exploitation known.

How to fix it

Update to Linux kernel containing commit c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c or later stable releases; rebuild and deploy kernel packages across affected Xen hosts.

How to confirm the fix worked

Verify kernel source contains the spinlock conversion in drivers/xen/privcmd.c; test eventfd release paths under load to confirm absence of deadlock; check dmesg for related warnings pre- and post-update.

Typical attack path

1. Obtain local code execution on Xen guest or host
2. Open and configure eventfd associated with irqfd in privcmd context
3. Trigger release sequence that calls wake_up_poll under spin_lock_irqsave
4. Force concurrent irqfd_wakeup to contend on mutex, inducing deadlock

How to detect it

Inspect kernel logs for deadlock warnings or hung task messages involving privcmd or eventfd; review system call traces around eventfd_release in Xen environments; no post-exploitation artifacts expected.

What your security team should do

• Prioritize kernel upgrade on all Xen hosts within maintenance windows
• Monitor for upstream stable backports and apply via distribution channels
• Review Xen privilege command usage and limit untrusted guest access where feasible