CVE-2026-31502

What it actually does

CVE-2026-31502 is a Linux kernel type-confusion flaw in the team network driver when team devices are stacked over non-Ethernet or mixed virtual network devices such as GRE and bonding devices. The team driver can copy and later invoke lower-device header_ops callbacks with the wrong net_device context. Those callbacks may then interpret the team device private data as a different structure, such as bonding private data, causing kernel memory corruption and crashes. Because the issue occurs in kernel networking code, successful exploitation can affect confidentiality, integrity, and availability; the most direct demonstrated impact is a local kernel crash or denial of service, with elevated risk in configurations that allow low-privileged users to create network namespaces or virtual network devices.

Why it matters to the business

An attacker with local access and enough ability to configure virtual networking could crash affected Linux systems, causing service outages and potential workload disruption. Systems running container platforms, network virtualization, CI sandboxes, or environments that allow unprivileged user namespaces may face higher practical exposure because local users or workloads may be able to create complex stacked network interfaces. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS activity, but it affects kernel stability and should still be remediated through normal kernel patching, especially on multi-user or container-dense hosts.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host. They then create or influence a stacked virtual networking topology involving a team device and non-Ethernet lower devices, such as a GRE device layered through a bond into a team device. When traffic or packet-header operations cause the team device to call dev_hard_header() or dev_parse_header(), the team driver may invoke inherited header_ops callbacks using the team net_device instead of the actual lower device. The lower callback then treats the team device private memory as the wrong object type, producing type confusion in kernel space. In observed syzbot-style crashes, this results in a fault in bond_header_create(), but the root cause is the team driver passing the wrong device context. A practical exploit would likely aim to trigger a kernel oops or panic for denial of service; more advanced exploitation would require shaping the memory corruption into controlled privilege escalation, which is not publicly demonstrated based on the provided data.

How to fix it

Upgrade to a Linux kernel build that contains the upstream fix for the team driver header_ops wrapper behavior. Because no exact fixed package versions were provided, use the kernel version supplied by the relevant Linux distribution or appliance vendor that explicitly includes the fix for CVE-2026-31502. Prioritize patching systems that enable the team driver, bonding, GRE or other tunnel interfaces, container networking, user namespaces, or delegated network administration. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, preventing untrusted workloads from creating network namespaces or virtual links, and unloading or blacklisting the team driver if it is not required. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, is updated to a vendor build containing the fix. Validate with uname -r, distribution package metadata, and vendor advisories for the active kernel package. Check whether the team driver is loaded with lsmod or /sys/module/team, and inventory hosts using team, bond, GRE, tunnel, or stacked virtual interfaces with ip link show and network configuration management data. Where safe, confirm that untrusted users cannot create relevant network devices by testing namespace and CAP_NET_ADMIN restrictions in a controlled environment. After remediation, verify that the system has been rebooted into the patched kernel and that no unexpected kernel oops or panic occurs when legitimate team/bond/tunnel configurations are exercised.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Obtain the ability to create or manipulate virtual network devices, commonly through CAP_NET_ADMIN or user/network namespaces where enabled.
3. Create a stacked topology involving team and non-Ethernet or virtual lower devices, for example GRE, bonding, and team interfaces.
4. Trigger packet transmission or parsing paths that call dev_hard_header() or dev_parse_header() on the team device.
5. Cause the inherited lower-device header_ops callback to execute with the wrong net_device context.
6. Trigger kernel type confusion, leading to a kernel oops, panic, or potentially broader kernel memory corruption.

How to detect it

Look for evidence of prior exploitation primarily in kernel logs, crash dumps, audit records, shell history, and endpoint telemetry because this is a local kernel networking flaw and exploitation may leave few application-level traces. Review journald, dmesg, /var/log/kern.log, /var/log/messages, netconsole output, and kdump/vmcore data for oops or panic traces referencing team, bonding, GRE, bond_header_create(), dev_hard_header(), dev_parse_header(), header_ops, or type confusion around net_device private data. Correlate any crash with preceding local activity that created or modified network namespaces, team interfaces, bond interfaces, GRE tunnels, or stacked virtual links. Useful telemetry includes auditd execve logs, sudo logs, container runtime events, systemd-networkd or NetworkManager logs, teamd configuration changes, and commands such as ip link add, teamd, teamdctl, modprobe team, modprobe bonding, or creation of GRE and bond devices. Pay special attention to crashes shortly after untrusted users, containers, CI jobs, or sandboxed workloads gained CAP_NET_ADMIN or created network namespaces. There are no known public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should focus on local abuse patterns and kernel crash artifacts rather than network perimeter indicators.

• bond_header_create
• dev_hard_header
• dev_parse_header
• header_ops
• netdev_priv
• team_setup_by_port
• type confusion
• BUG: kernel NULL pointer dereference
• kernel BUG at
• Oops:
• Kernel panic
• Call Trace:
• /sys/module/team
• /sys/class/net/team
• teamd
• teamdctl
• modprobe team
• modprobe bonding
• ip link add name team
• ip link add team
• ip link add bond
• ip link add gre
• ip link add type team
• ip link add type bond
• ip link add type gre
• ip link set master team
• ip link set master bond

What your security team should do

• Patch affected Linux kernels through the appropriate vendor channel and reboot into the fixed kernel, prioritizing multi-user, container, virtualization, and network-heavy hosts.
• Inventory systems using the team driver, bonding, GRE, tunnels, or complex stacked virtual interfaces; treat these as higher-priority remediation targets.
• Restrict CAP_NET_ADMIN and disable or constrain unprivileged user namespaces where business requirements allow.
• If the team driver is not used, consider preventing it from loading via module blacklisting or kernel/module policy until patching is complete.
• Monitor kernel logs for oops, panic, or warning traces involving team, bonding, GRE, header_ops, bond_header_create, dev_hard_header, or dev_parse_header.
• Review audit and command telemetry for local users or containers creating unusual team, bond, GRE, or network namespace configurations before unexplained crashes.
• Ensure crash dump collection is enabled on critical Linux systems so suspected exploitation attempts can be forensically reviewed.
• Because EPSS is currently low and the issue is not in KEV, handle as a prioritized kernel stability and local-privilege-risk patch rather than an internet-edge emergency unless local untrusted workload exposure is high.