Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2026-31502 is a high-severity Type Confusion (CWE-843) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31502 is a type confusion vulnerability (CWE-843) in the Linux kernel's team driver, affecting the handling of header_ops for non-Ethernet ports. The issue arises in team_setup_by_port(), which copies port_dev->header_ops directly to the team net_device. When callbacks like dev_hard_header() or dev_parse_header() are invoked, they execute with the team net_device context instead of the underlying lower device, leading netdev_priv(dev) to interpret the wrong private data type. This mirrors a prior bonding driver flaw and was demonstrated by syzbot in a topology of gre -> bond -> team, where bond_header_create() crashed due to misinterpreting team private data.
A local attacker with low privileges (AV:L/AC:L/PR:L) can exploit this vulnerability without user interaction (UI:N) in unprivileged scope (S:U). Triggering the flawed header operations in stacked non-Ethernet topologies causes kernel crashes via type confusion, with potential for high impacts on confidentiality, integrity, and availability (CVSS 7.8). The CVSS vector indicates reliable exploitation leading to severe disruption or data compromise through incorrect private data handling.
Mitigation is provided through kernel patches in stable trees, such as commits 0a7468ed49a6b65d34abcc6eb60e15f7f6d34da0, 20491d384d973a63fbdaf7a71e38d69b0659ea55, 425000dbf17373a4ab8be9428f5dc055ef870a56, and 6d3161fa3eee64d46b766fb0db33ec7f300ef52d. These introduce team header_ops wrappers for create and parse operations, which select the correct team port under RCU, invoke lower device callbacks with the proper port->dev context, and pass the lower device to parse callbacks to bound recursion in stacked topologies.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-24879
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: team: fix header_ops type confusion with non-Ethernet ports Similar to commit 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") team has the same class of header_ops type confusion. For non-Ethernet ports,…
more
team_setup_by_port() copies port_dev->header_ops directly. When the team device later calls dev_hard_header() or dev_parse_header(), these callbacks can run with the team net_device instead of the real lower device, so netdev_priv(dev) is interpreted as the wrong private type and can crash. The syzbot report shows a crash in bond_header_create(), but the root cause is in team: the topology is gre -> bond -> team, and team calls the inherited header_ops with its own net_device instead of the lower device, so bond_header_create() receives a team device and interprets netdev_priv() as bonding private data, causing a type confusion crash. Fix this by introducing team header_ops wrappers for create/parse, selecting a team port under RCU, and calling the lower device callbacks with port->dev, so each callback always sees the correct net_device context. Also pass the selected lower device to the lower parse callback, so recursion is bounded in stacked non-Ethernet topologies and parse callbacks always run with the correct device context.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V3.2.3V15.3.5
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and type-aware analysis) directly finds type-confusion flaws before deployment.
Engineering principles can require use of type-safe languages, static typing, and runtime type checks that structurally avoid allocating one type and accessing another.
Memory-protection controls limit the blast radius when a type-confusion access occurs but do not stop the flaw itself.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent type-confusion flaws via safe typing, static analysis, and code review while the control itself addresses many additional weaknesses.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect type-confusion vulnerabilities through fuzzing and static analysis.
Secure SDLC mandates type-safe design and review that can catch type-confusion flaws.
Application security requirements can specify strong typing and interface contracts that reduce type confusion.
Secure architecture principles promote type-safe languages and memory-safety mechanisms that mitigate type confusion.
Secure coding standards directly forbid unsafe type casts and require static-analysis checks for type confusion.