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.
Security readout for executives and security teams
Plain-English summary
A Linux Airoha networking driver allocates only half the memory needed for a timing array. Under the documented condition, the kernel writes past that allocation, potentially corrupting memory and crashing the system. Systems without the affected driver or code path are unlikely to be exposed.
Executive priority
Treat as an urgent validation and patching issue for appliances or servers using Airoha networking. A kernel crash could interrupt critical network services, while heap corruption creates broader theoretical impact. Avoid assuming every Linux host is exposed; prioritize confirmed driver use and vendor-confirmed vulnerable builds.
Technical view
foe_check_time is a u16 pointer, but its allocation used ppe_num_entries bytes instead of ppe_num_entries multiplied by sizeof(u16). In airoha_ppe_foe_verify_entry(), a hash at or above half the entry count can therefore cause a heap buffer overflow. The cited stable-kernel commits correct the allocation size.
Likely exposure
Exposure depends on running an affected Linux build with the Airoha networking driver and vulnerable PPE flow-entry verification path present. The supplied version data is ambiguous and may not reflect downstream backports, so kernel version alone is insufficient. Confirm driver use and vendor patch status.
Exploitation context
The bundle assigns CVSS 9.8 with network reachability, low complexity, and no required privileges or interaction. However, it provides no exploit-path analysis beyond the vulnerable function condition. The CVE is not listed as KEV, and the supplied sources do not report active exploitation or public weaponization.
Researcher notes
The allocation defect and out-of-bounds condition are clearly described, but the supplied affected-version records are difficult to interpret and include commit identifiers alongside release numbers. The sources establish potential kernel crash, not demonstrated code execution. Researchers should verify reachability, configuration prerequisites, and downstream backports without inferring exploitation.
Mitigation direction
Install a vendor-supported kernel containing the applicable referenced stable fix.
Check distribution or device-vendor guidance for downstream backport status.
Prioritize internet-facing or availability-critical systems using the Airoha driver.
If updating is delayed, assess whether the affected driver or feature can be safely disabled.
Validation and detection
Inventory kernel versions and identify systems loading or using the Airoha networking driver.
Compare each kernel build with vendor advisories and downstream patch records.
Verify the applicable stable fix is present in the deployed kernel source or package metadata.
Monitor affected systems for unexplained kernel crashes or memory-corruption reports.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-80617 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.