CVE-2024-50192

What it actually does

Race condition in GICv4 IRQ handling permits userspace to issue VMOVP affinity change on a VPE after vmapp_count indicates it is unmapped but while the doorbell interrupt remains visible.

Why it matters to the business

May cause interrupt misrouting or instability for virtual machines on ARM systems using GICv4, increasing operational risk until kernels are updated.

How an attack unfolds

An attacker manipulates VPE state to trigger the narrow window between unmapping and doorbell cleanup, bypassing the missing vmapp_count check to alter affinity on a dying VPE.

How to fix it

Apply the upstream fix in commit b7d7b7fc876f836f40bf48a87e07ea18756ba196 and update to a kernel release containing this change; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the vmapp_count check exists before any VMOVP operation in irqchip/gic-v4 code and verify the running kernel contains commit b7d7b7fc876f836f40bf48a87e07ea18756ba196 or equivalent.

Typical attack path

1. Obtain userspace access to VPE management interfaces
2. Unmap the target VPE while leaving its doorbell IRQ visible
3. Issue VMOVP affinity change before vmapp_count is consulted
4. Observe or trigger resulting interrupt state inconsistency

How to detect it

Inspect kernel logs for VPE unmap and affinity change sequences occurring without proper vmapp_count validation; correlate with /proc/irq entries for doorbell interrupts on unmapped VPEs.

What your security team should do

• Prioritize kernel updates on all GICv4-enabled systems
• Review virtualization workloads for exposure to VPE affinity changes
• Harden userspace interfaces that can manipulate VPE state