Cloudanix VulnDB

CVE-2026-80896

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in Linux kernel code that manages virtual machine interrupts could let a local attacker crash the system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in mshv_irqfd_deassign omits required pt->pt_irqfds_lock during hlist traversal of pt_irqfds_list and uses hlist_del() instead of hlist_del_init(), allowing concurrent mshv_irqfd_wakeup paths to perform double deletion on poisoned pointers after the is_active guard fails.

Why it matters to the business

Kernel instability or crashes in Linux environments using mshv for virtualization, potentially disrupting hypervisor IRQ handling and guest operations with moderate operational impact given 25 days since publication and no known exploitation.

How an attack unfolds

An attacker with local access triggers concurrent IRQFD deassign and EPOLLHUP wakeup paths on the same irqfd; the missing lock permits the hlist traversal to race, and the poisoned node after hlist_del causes mshv_irqfd_is_active to return true, enabling a second hlist_del and memory corruption.

How to fix it

Update to a kernel containing the fix that adds spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign and replaces hlist_del with hlist_del_init; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Inspect mshv_irqfd.c source to confirm spin_lock_irq protection around pt_irqfds_list traversal in mshv_irqfd_deassign and verify hlist_del_init usage; test by exercising concurrent IRQFD deassign and wakeup paths under lockdep.

Typical attack path

  1. Obtain local code execution on affected Linux kernel
  2. Create and register multiple IRQFDs via mshv interface
  3. Trigger concurrent deassign and EPOLLHUP events on the same irqfd
  4. Exploit resulting double hlist_del to corrupt kernel memory structures

How to detect it

Review kernel logs for mshv_irqfd related warnings, oops, or use-after-free traces; correlate with processes exercising mshv ioctls around the time of crashes.

What your security team should do

  • Prioritize kernel upgrade on all systems using mshv within the next patch cycle
  • Monitor for upstream stable releases incorporating the race fix
  • Restrict unprivileged access to mshv ioctl interfaces where possible

The record

In the Linux kernel, the following vulnerability has been resolved: mshv: Fix race in mshv_irqfd_deassign mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign() omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(), which does take the lock before calling mshv_irqfd_deactivate(). Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons the node pointers rather than resetting them. Since mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev == NULL), a poisoned node still appears active. If a concurrent path calls mshv_irqfd_deactivate() again on the same irqfd, the guard fails to prevent a double hlist_del() on poisoned pointers. Fix both issues: - Add the missing spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release(). - Use hlist_del_init() instead of hlist_del() so the node is properly marked as unhashed after removal, making the is_active guard reliable.

Affected packages

Ecosystem Package Introduced Fixed