CVE-2026-80610: Linux Kernel Divide-by-Zero Vulnerability

CVE-2026-80610 Overview

CVE-2026-80610 is a divide-by-zero flaw in the Linux kernel net: enetc driver. The issue lives in enetc4_default_rings_allocation(), which distributes rings between the physical function (PF) and virtual functions (VFs). On NXP i.MX94 series hardware, all standalone ENETCs do not support SR-IOV, so pf->caps.num_vsi is zero. When the allocation routine divides by num_vsi, it triggers undefined behavior under the C standard.

On ARM64, the UDIV/SDIV instructions silently return zero rather than raising an exception, so the defect does not produce a visible crash on that platform. However, the behavior is not portable and represents a latent kernel bug.

Critical Impact
Undefined behavior in kernel ring allocation on hardware without SR-IOV support, with cross-platform compatibility risk when the ENETC driver runs outside ARM64.

Affected Products

Linux kernel net: enetc driver
NXP i.MX94 series platforms using standalone ENETC controllers
Systems where pf->caps.num_vsi evaluates to zero at ring allocation time

Discovery Timeline

2026-08-28 - CVE-2026-80610 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-80610

Vulnerability Analysis

The Enhanced Network Controller (ENETC) driver in the Linux kernel allocates transmit and receive rings across the PF and any available VFs at initialization. The routine enetc4_default_rings_allocation() calculates per-VF ring counts by dividing the remaining ring pool by pf->caps.num_vsi, the number of virtual station interfaces reported by the hardware capability register.

On i.MX94 standalone ENETC instances, SR-IOV is not implemented, so num_vsi is zero. The division operation therefore executes with a zero divisor. Under the C language specification, integer division by zero is undefined behavior, and kernel code must not rely on architecture-specific handling of such operations.

Root Cause

The driver assumes at least one virtual station interface is present when performing ring distribution. It does not validate num_vsi before using it as a divisor. The upstream fix adds an explicit check for num_vsi == 0 and returns early after the PF's rings have been configured, avoiding the division entirely.

Attack Vector

The defect is triggered at driver initialization on affected hardware and does not require an authenticated network attacker. Practical impact is limited to hardware configurations where num_vsi is zero. On ARM64, the ENETC driver continues to operate because UDIV/SDIV returns zero silently. On other architectures, the same code path could raise a divide-by-zero exception and destabilize the kernel. The vulnerability described is a correctness and portability defect rather than a remotely exploitable primitive.

See the upstream commits Kernel Git Commit 5da6553 and Kernel Git Commit cd37bcb for the technical fix.

Detection Methods for CVE-2026-80610

Indicators of Compromise

Kernel logs referencing enetc4_default_rings_allocation on i.MX94 or other ENETC-equipped platforms
Absence of expected VF ring configuration on ENETC PFs where SR-IOV is not supported
Unexpected divide-by-zero traps on non-ARM64 kernels running the ENETC driver

Detection Strategies

Inventory kernel versions across Linux hosts and identify systems shipping the ENETC driver without the upstream fix applied
Compare running kernel commit identifiers against 5da65537792b68b6052ffcab65e04c27aea6dfe4 and cd37bcb67f909a8683cc8c38a63ac7367a7f6161 to confirm patch status
Review boot-time dmesg output for anomalies during ENETC probe on affected NXP hardware

Monitoring Recommendations

Track kernel panic and oops events on embedded and networking appliances that use ENETC
Enable kernel undefined-behavior sanitizer (UBSan) in development and validation builds to catch division-by-zero regressions
Alert on driver initialization failures reported by systemd or platform boot logs

How to Mitigate CVE-2026-80610

Immediate Actions Required

Apply the upstream kernel commits that add the num_vsi == 0 guard in enetc4_default_rings_allocation()
Rebuild and redeploy vendor kernels for NXP i.MX94 and any other platforms shipping standalone ENETC controllers
Validate ENETC ring configuration after patching by inspecting ethtool -l <iface> output

Patch Information

The fix is available in the stable Linux kernel tree via commits 5da65537792b and cd37bcb67f90. The patch adds an explicit check for num_vsi == 0 and returns early after configuring PF rings, avoiding the division entirely.

Workarounds

No runtime configuration workaround exists; the divisor is derived from a hardware capability register
Restrict deployment of unpatched kernels to ARM64 platforms where the silent-zero behavior avoids kernel exceptions, and treat this as a temporary measure only
Prioritize patching before porting the ENETC driver or affected kernels to non-ARM64 architectures

bash

# Verify kernel commit inclusion after updating
git -C /usr/src/linux log --oneline | grep -E "5da65537|cd37bcb6"

# Confirm ENETC ring configuration on the affected interface
ethtool -l <enetc_interface>