CVE-2026-80610 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: fix potential divide-by-zero when num_vsi is zero
For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so pf->caps.num_vsi is zero. This leads to a divide-by-zero in enetc4_default_rings_allocation() when distributing rings among PF and VFs.
Division by zero is undefined behavior in C. On ARM64, the UDIV/SDIV instructions silently return zero rather than raising an exception, so the issue does not cause a visible crash. However, relying on this behavior is incorrect and poses a cross-platform compatibility risk.
Add an explicit check for num_vsi == 0 and return early after the PF's rings have been configured.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel driver enetc contains a logic flaw that can lead to undefined behavior during ring buffer allocation, specifically when dealing with hardware configurations where Single Root I/O Virtualization is not supported. This issue primarily affects systems based on the i.MX94 series of processors, where all standalone Ethernet controllers lack SR-IOV capabilities. In such environments, the capability field pf->caps.num_vsi is initialized to zero because there are no virtual functions available for allocation. The vulnerability manifests within the enetc4_default_rings_allocation function, which is responsible for distributing network rings between physical and virtual functions. When this routine attempts to calculate ring distribution using num_vsi as a divisor without first verifying that it is non-zero, it triggers a division by zero operation.
From a technical perspective, dividing by zero constitutes undefined behavior in the C programming language standard. While many modern architectures handle integer division errors gracefully on an instruction level, relying on this implicit handling is poor practice and introduces significant portability risks. On ARM64 architecture, which powers the i.MX94 series, the UDIV and SDIV instructions are designed to silently return zero when a divide-by-zero condition occurs rather than raising a hardware exception or fault. Consequently, in these specific environments, the bug does not result in an immediate kernel panic or system crash. The driver may continue operating with incorrect ring counts, potentially leading to subtle performance degradation or misconfiguration of network interfaces. However, on other architectures such as x86 or older ARM variants, a divide-by-zero typically triggers a fatal exception that crashes the kernel, making this vulnerability a latent stability threat across diverse hardware platforms.
This flaw aligns with CWE-369, which describes Divide By Zero vulnerabilities where an operation divides by zero without proper validation of input values. It also relates to CWE-754, Improper Check for Unusual or Exceptional Conditions, as the code fails to validate a critical parameter before using it in arithmetic operations. In terms of attack surface and detection, this is not directly exploitable for remote code execution but represents a reliability issue that could be triggered by specific hardware configurations during driver initialization. It falls under the ATT&CK category of Defense Evasion or Impact if an attacker can force the system into a state where network functionality is degraded due to incorrect ring allocation, although in practice, it primarily affects local stability rather than providing direct exploitation vectors for external adversaries.
The resolution involves adding an explicit conditional check within the enetc4_default_rings_allocation function to verify that num_vsi is not equal to zero before performing any division operations. If num_vsi is found to be zero, indicating a non-SR-IOV capable device, the function returns early after completing the configuration of rings for the physical function only. This ensures that no invalid arithmetic operation occurs and maintains consistent behavior across all supported hardware platforms. To mitigate this risk in deployed systems, administrators should ensure they are running kernel versions where this patch is applied. For organizations managing large fleets of i.MX94-based devices, verifying driver versioning and applying security updates promptly is essential to maintain network stack integrity and prevent potential instability issues arising from undefined behavior in low-level hardware drivers.