Linux Kernel CVE-2026-80617

Requires the target to be running the Linux Airoha Ethernet (airoha_eth) driver with the PPE flow-offload engine active - i.e., Airoha-SoC networking hardware, not a general-purpose x86 server. The overflow only triggers when airoha_ppe_foe_verify_entry() processes a flow whose hash is >= ppe_num_entries/2, so the attacker must cause enough distinct offloaded flows to reach the upper half of the FOE table. Limiting factors: the driver and flow-offload feature must be present and enabled; the written data is a timestamp (low attacker control), making the realistic outcome a kernel crash/DoS rather than controlled memory corruption; and non-Airoha platforms are entirely unaffected.

The signals conflict sharply. The supplied CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) reflects automated NVD scoring typical of Linux kernel CVEs and overstates real-world risk: the write is a fixed timestamp value with limited attacker control, the description states 'potential kernel crash' (denial of service) rather than confirmed code execution, and exploitation is confined to hardware actually running the Airoha PPE flow-offload driver. EPSS is low (0.18%, 8th percentile) and there is no KEV listing and no POC, consistent with a hard-to-weaponize, niche-hardware memory-safety bug. No SSVC decision was provided. Net assessment: legitimate memory-corruption defect worth patching on affected embedded/router platforms, but not a broad emergency - the AV:N/AC:L/CIA:H vector should be treated as inflated relative to the description, which implies a narrow trigger condition and DoS-dominant impact.

An attacker generates or induces network flows through an Airoha-SoC router running an affected kernel with PPE flow offload enabled, causing the driver to create and verify FOE entries. When an entry lands in a hash bucket at or above ppe_num_entries/2, airoha_ppe_foe_verify_entry() writes a timestamp beyond the undersized foe_check_time buffer, corrupting kernel heap memory and crashing the device (denial of service). No public exploit is currently identified, and turning the fixed timestamp corruption into reliable code execution would require significant additional heap-grooming research.