CVE-2026-80610: net: enetc: fix potential divide-by-zero when num_vsi is zero
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: fix potential divide-by-zero when numvsi is zero
For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so pf->caps.numvsi is zero. This leads to a divide-by-zero in enetc4defaultringsallocation() 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 numvsi == 0 and return early after the PF's rings have been configured.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the enetc4_default_rings_allocation() logic (net: enetc) to explicitly check for num_vsi == 0 and return early after distributing rings to the PF, preventing undefined behavior/divide-by-zero when pf->caps.num_vsi is zero.
Linux kernel - net: enetc num_vsi handling in enetc4_default_rings_allocation() = Add explicit check for num_vsi == 0 and return early after the PF's; ensure divide-by-zero is avoided when pf->caps.num_vsi is zero
Event History
Frequently Asked Questions
Which systems are affected by this condition?
The issue applies to standalone ENETC devices on the i.MX94 series, where SR-IOV is not supported and pf->caps.num_vsi is zero. It occurs during default ring allocation when rings are distributed between the physical function and virtual functions.
Does this necessarily cause a system crash?
No. On ARM64, UDIV and SDIV silently return zero for this condition rather than raising an exception, so a visible crash may not occur. The code nevertheless relies on undefined C behavior and creates a cross-platform compatibility risk.
What does the fix change?
The fix explicitly checks whether num_vsi is zero. When it is, processing returns after configuring the physical function's rings, avoiding the division used for PF/VF ring distribution.