CVE-2026-80640 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
cxl/fwctl: Fix __fortify_panic
Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier.
memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified in the cxl/fwctl subsystem involves a false positive runtime assertion triggered by fortification checks during buffer operations. Specifically, the function cxlctl_get_supported_features() was flagged for a potential array overflow due to improper initialization of the num_entries variable used with __counted_by_le attributes. This issue manifests as a memcpy detected buffer overflow warning indicating a 48-byte write attempt against a zero-sized buffer, which halts execution through __fortify_panic and disrupts normal system operation despite being technically benign in context.
The root cause lies in the timing of variable initialization within cxlctl_get_supported_features(). The num_entries field was not initialized before being used to determine array bounds for subsequent memory operations. When fortification mechanisms detect that an array access might exceed declared limits based on uninitialized or zeroed count values, they trigger defensive panic routines designed to prevent actual buffer overflows from causing security breaches. In this case, the warning represents a false positive because the underlying logic does not actually permit out-of-bounds writes under normal execution paths, but the static analysis and runtime checks cannot distinguish between intentional initialization delays and genuine unsafe coding patterns without explicit early assignment of boundary variables.
This vulnerability impacts system stability by causing unexpected kernel panics or warnings during feature enumeration processes in CXL (Compute Express Link) firmware control interfaces. While it does not directly enable privilege escalation or remote code execution, the resulting denial-of-service condition can disrupt management operations and require manual intervention to restore functionality. The incident highlights how aggressive security hardening features like fortify_source may inadvertently flag legitimate programming patterns when developers defer initialization for logical reasons rather than oversight.
From a standards perspective, this issue relates to CWE-190 Integer Overflow or Wraparound in the context of array bound calculations and CWE-787 Out-of-bounds Write where uninitialized data leads to incorrect boundary assessments. In terms of MITRE ATT&CK mapping, while not exploitable for attack purposes here, such patterns could theoretically be leveraged if combined with other vulnerabilities to manipulate control flow through buffer manipulation techniques categorized under T1203 Exploitation for Defense Evasion or similar categories involving memory corruption exploitation strategies.
Mitigation involves ensuring that all variables used in array bound calculations are explicitly initialized before their first use in conditional statements or loop constructs governing memory operations. Developers should adopt defensive programming practices by setting default values for count fields at declaration time rather than relying on later assignment within function logic blocks. Additionally, code review processes should prioritize verification of __counted_by_le annotated structures to prevent similar false positives that degrade system reliability without addressing actual security risks.
System administrators encountering this issue may temporarily disable fortification checks in non-production environments if stability is prioritized over strict runtime validation, though this approach reduces overall protection against genuine buffer overflow attacks. Long-term resolution requires upstream kernel patches that correct the initialization sequence within cxlctl_get_supported_features() to align with modern security expectations while preserving functional correctness of CXL feature enumeration procedures across supported hardware platforms.