Look up another CVE · open CVE-2026-72409 in the interactive tracker
CVE-2026-72409
net: mvneta: re-enable percpu interrupt on resume
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72409 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/marvell/mvneta.c
- What this is
- MARVELL MVNETA ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/marvell/mvneta* · netdev@vger.kernel.org · Maintained
- Kernel module
- mvneta
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_MVNETA|CONFIG_NET_VENDOR_MARVELL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w mvnetaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_MVNETA, CONFIG_NET_VENDOR_MARVELL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.72%, higher than 52.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.4 | 5.10.261 | bf88cd3b649b |
| 4.4 | 5.15.212 | 8c7a489aa71d |
| 4.4 | 6.1.178 | 82c13027ed28 |
| 4.4 | 6.6.145 | be626ac1faad |
| 4.4 | 6.12.97 | 1cc312dc8bc7 |
| 4.4 | 6.18.40 | b84dd48f9da1 |
| 4.4 | 7.1.5 | 5bdb33ff6e58 |
| 4.4 | 7.2 | fd398d648098 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- Remote traffic on internet-facing Marvell Armada 370/XP/38x routers, NAS, and gateways drives mvneta_percpu_isr/NAPI (race step 1); the highest-impact scenario pairs sustained RX/TX load with automatic suspend/resume, so the attack is initiated from the network.
- AC:LAttack complexity, low
- On PREEMPT_RT (called highly likely in the fix) or when softirq is deferred to ksoftirqd, an attacker can sustain traffic to keep NAPI pending across suspend; no uncontrollable memory layout or rare one-shot victim state is required beyond routine PM cycles.
- PR:NPrivileges required, none
- Sending packets to the mvneta interface requires no credentials; in the strongest scenario suspend/resume is driven by automatic system power management rather than privileged manual action, so no account or capability on the victim is needed.
- UI:NUser interaction, none
- No victim user action is required beyond normal operation; remote traffic and automatic suspend/resume (or scheduled PM) suffice without anyone mounting devices or confirming prompts.
- S:UScope, unchanged
- The bug leaves the MPIC per-CPU IRQ permanently masked on the same host kernel/driver boundary; it does not cross VM, container, or IOMMU security domains.
- C:NConfidentiality impact, none
- This is a driver/IRQ state-management logic error with no out-of-bounds access, use-after-free, or memory disclosure; interrupts stay masked but no kernel memory is read.
- I:NIntegrity impact, none
- No data structures or packets are corrupted; the failure mode is a permanently masked interrupt with no write primitive or control-flow hijack potential.
- A:HAvailability impact, high
- After resume the MPIC per-CPU interrupt remains permanently masked, so the NIC never delivers packets despite hardware activity, causing complete and lasting loss of network connectivity until reboot.