CVE-2026-80617 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: airoha: fix foe_check_time allocation size
foe_check_time is declared as u16 pointer but was allocated with only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2, it writes beyond the allocated buffer, causing heap buffer overflow and potential kernel crash.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The identified vulnerability resides within the Linux kernel networking subsystem, specifically in the Airoha Ethernet switch driver implementation. This flaw represents a classic memory allocation error where the size of dynamically allocated memory does not match the requirements of the data structure being stored. The variable foe_check_time is declared as a pointer to unsigned 16-bit integers (u16), indicating that it is intended to hold an array of such values. However, during initialization or processing, the kernel allocates memory for this buffer using only ppe_num_entries bytes rather than the correct size calculated by multiplying ppe_num_entries by sizeof(u16). Since a u16 typically occupies two bytes on most architectures, this results in allocating exactly half the required amount of memory. This discrepancy creates an undersized heap buffer that is insufficient to hold the full array as intended by the driver logic.
The operational impact of this vulnerability manifests when the function airoha_ppe_foe_verify_entry() executes with specific input parameters. Specifically, if the hash value provided exceeds half of ppe_num_entries, the code attempts to access indices within foe_check_time that fall outside the bounds of the allocated memory region. Because the buffer is only large enough for approximately half the expected entries, any write operation targeting an index greater than or equal to ppe_num_entries divided by two results in a heap buffer overflow. This out-of-bounds write corrupts adjacent memory on the kernel heap, which can lead to unpredictable behavior including data corruption, privilege escalation if exploitable, or immediate system instability resulting in a kernel panic and subsequent denial of service for the affected host.
From a classification perspective, this vulnerability aligns with CWE-122, Heap-based Buffer Overflow, as it involves writing beyond the allocated heap memory boundary due to an incorrect size calculation during allocation. It also relates closely to CWE-131, Incorrect Calculation of Buffer Size, which is the root cause of the insufficient memory reservation. In terms of attack vectors and techniques, this flaw could potentially be leveraged within the ATT&CK framework under Tactic TA0004 (Privilege Escalation) or TA0005 (Defense Evasion), specifically mapping to technique T1203 Exploitation for Privilege Escalation if an attacker can trigger the condition through crafted network packets. The vulnerability allows for arbitrary write primitives on the kernel heap, which is a critical primitive in many exploitation chains targeting Linux systems.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary fix involves correcting the allocation size calculation to ensure that foe_check_time receives ppe_num_entries multiplied by sizeof(u16) bytes of memory. This ensures the buffer capacity matches the array dimensions expected by subsequent access patterns in airoha_ppe_foe_verify_entry(). Beyond this specific patch, developers should enforce strict bounds checking before any array index is used to write data. Implementing static analysis tools that detect mismatched allocation and usage sizes can help prevent similar errors in future development cycles. Additionally, enabling kernel hardening features such as KASAN (Kernel Address Sanitizer) during testing phases would have likely detected this out-of-bounds access early in the development lifecycle, preventing it from reaching production environments.