CVE-2026-72409

Status: UPDATED  |  Advisory ID: CVE-2026-72409

Key Details

Affected Products, Subsystems & Sectors

What to Know

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

net: mvneta: re-enable percpu interrupt on resume

On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu

IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls

disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules

NAPI poll, which calls enable_percpu_irq() on completion to unmask.

If suspend occurs while NAPI poll is pending (between

disable_percpu_irq in the ISR and enable_percpu_irq in poll

completion), the interrupt is never re-enabled:

1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule()

=> MPIC masked, percpu_enabled cpumask bit cleared

2. NAPI poll does not complete before suspend proceeds

(on PREEMPT_RT this is highly likely since softirqs run in

ksoftirqd which gets frozen; on non-RT it can happen when

softirq processing is deferred to ksoftirqd)

3. mvneta_stop_dev => napi_disable(): cancels the pending poll

without executing the completion path

4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC

(already masked, but records IRQS_SUSPENDED)

5. Resume: mpic_resume checks irq_percpu_is_enabled() => false

(bit was cleared in step 1) => skips unmask

6. mvneta_start_dev only restores device-level INTR_NEW_MASK,

does not touch the MPIC per-CPU mask

Result: MPIC per-CPU interrupt stays masked permanently. The NIC

generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never

receives them, causing complete loss of network connectivity.

Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path

to unconditionally unmask the MPIC per-CPU interrupt regardless of

pre-suspend state. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References