CVE-2026-43456

What it actually does

This is a Linux kernel type-confusion flaw in the bonding network driver. When a non-Ethernet network device such as a GRE tunnel is enslaved to a bonding interface, the bond device can incorrectly inherit the slave device's header operation callbacks. Later packet transmission through the bond can call a tunnel-specific header function with the bond device as its argument, causing netdev_priv() to interpret bonding-private data as tunnel-private data. That incorrect object interpretation can lead to invalid memory reads, kernel BUG/Oops conditions, and potentially broader kernel memory corruption depending on layout and execution context. The published crash trace shows failure in pskb_expand_head() reached through ipgre_header(), dev_hard_header(), and AF_PACKET sendmsg handling. The CVSS vector indicates local exploitation with low complexity and low privileges, no user interaction, and potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems or destabilize kernel networking, causing service outages on servers, appliances, containers, virtualization hosts, and network-heavy platforms that expose bonding and tunnel configuration. In higher-impact scenarios, a local attacker with sufficient ability to create or manipulate network interfaces may be able to escalate privileges or compromise the host kernel. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is not indicated; however, kernel-level bugs remain high priority on multi-user systems, container hosts, and environments where untrusted users can obtain network administration capabilities.

How an attack unfolds

An attacker first needs local access and the ability to configure network interfaces, commonly through CAP_NET_ADMIN, a privileged container, a network namespace configuration path, or another local administrative foothold. They create or use a non-Ethernet device whose header operations expect a device-specific private structure, such as a GRE or IPv6 GRE tunnel. They then enslave that device to a Linux bonding interface. Because the vulnerable bonding code directly copies the slave's header_ops into the bond device, subsequent traffic sent through the bond can invoke the slave's header-construction callback with the wrong net_device object. The callback reads the bond driver's private data as though it were tunnel-private data, producing type confusion and invalid memory access. Triggering packet transmission, including through AF_PACKET or normal interface activity, can then crash the kernel and may create conditions for further kernel memory corruption exploitation.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the bonding driver fix for this issue. The corrected implementation uses bonding-specific wrapper header operations that delegate to the active slave while passing the slave's own net_device object, preventing tunnel callbacks from interpreting bonding-private data as tunnel-private data. No fixed package versions were provided in the input, so use the appropriate security advisory from the Linux distribution or kernel vendor and confirm the patch references the bonding fix for bond_setup_by_slave() header_ops type confusion. If immediate patching is not possible, reduce exposure by preventing untrusted users, containers, and automation from creating bonds, tunnels, or assigning tunnel devices as bond slaves. Restrict CAP_NET_ADMIN, disable unprivileged user namespaces where feasible, limit privileged containers, and enforce configuration policy that blocks GRE/IP6GRE or other non-Ethernet tunnel devices from being enslaved to bonding interfaces until patched.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed release for this vulnerability, not merely that an updated package is installed. Reboot into the fixed kernel where required. Review the vendor changelog or source package to verify the bonding driver contains the wrapper-based bond_header_ops behavior rather than directly assigning slave_dev->header_ops to the bond device. On test systems only, validate that creating a GRE or similar non-Ethernet slave under a bond no longer causes a kernel BUG/Oops when the bond is brought up and traffic is sent. Also validate that policy controls prevent untrusted principals from obtaining CAP_NET_ADMIN or running privileged containers capable of creating tunnel and bond devices.

Typical attack path

1. Obtain local access to an affected Linux system with enough privileges to create or reconfigure network interfaces.
2. Create or identify a non-Ethernet network device with specialized header operations, such as a GRE or IPv6 GRE tunnel.
3. Create or identify a bonding interface, commonly in active-backup mode.
4. Enslave the non-Ethernet tunnel device to the bond interface.
5. Bring the slave and bond interfaces up and assign addresses or otherwise cause packet transmission through the bond.
6. Trigger dev_hard_header() on the bond so that tunnel-specific header operations execute against the bond device's private data.
7. Cause a kernel Oops, BUG, system crash, or potentially exploitable kernel memory corruption.

How to detect it

To determine whether this issue may already have been exploited, review kernel logs, crash dumps, audit logs, command histories, and network configuration management records. Key evidence includes kernel Oops, BUG, panic, or KASAN reports with stack traces that include bonding and tunnel header functions, especially pskb_expand_head(), ipgre_header(), ip6gre_header(), dev_hard_header(), packet_sendmsg(), or bond_setup_by_slave(). Review /var/log/kern.log, /var/log/messages, journalctl -k, dmesg archives, kdump/vmcore records, pstore, systemd-coredump metadata, and hypervisor reset events for unexplained crashes shortly after network interface reconfiguration. In auditd or EDR telemetry, look for iproute2 commands that create GRE/IP6GRE tunnel interfaces, create bond interfaces, set a tunnel as a bond master/slave relationship, bring those interfaces up, or assign addresses to the bond. Also review container runtime and orchestration logs for privileged containers, host networking, or CAP_NET_ADMIN grants immediately preceding host kernel crashes. Absence of a crash trace does not prove non-exploitation because kernel panics can truncate logs; correlate with unexpected reboots and network configuration changes.

• kernel BUG at net/core/skbuff.c:2306
• Oops: invalid opcode
• RIP: 0010:pskb_expand_head
• ipgre_header+
• ip6gre_header+
• dev_hard_header
• packet_snd
• packet_sendmsg+
• bond_setup_by_slave
• netdev_priv
• ip link add gre
• ip link add gre1 type gre
• ip link add bond
• type bond mode active-backup
• ip link set gre1 master bond1
• ip link set bond1 up
• ip addr add fe80::1/64 dev bond1
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /sys/fs/pstore
• /proc/vmcore
• CAP_NET_ADMIN

What your security team should do

• Prioritize kernel updates on multi-user Linux systems, container hosts, virtualization hosts, network appliances, CI runners, and systems where users or workloads may have CAP_NET_ADMIN.
• Inventory hosts using Linux bonding together with GRE, IP6GRE, GRETAP, SIT, or other tunnel interfaces, and treat those as higher exposure until patched.
• Restrict CAP_NET_ADMIN from untrusted users and containers; review Kubernetes, container runtime, and service configurations for privileged mode, host networking, and added network capabilities.
• If patching is delayed, enforce network configuration policy that prevents non-Ethernet tunnel devices from being enslaved to bond interfaces.
• Monitor kernel logs for Oops, BUG, panic, or crash traces involving bonding, ipgre_header(), ip6gre_header(), dev_hard_header(), packet_sendmsg(), or pskb_expand_head().
• Review audit, shell history, orchestration logs, and network management logs for suspicious creation of GRE tunnels and bonding interfaces by non-administrative users or unexpected automation.
• Because EPSS is low and there is no KEV listing, balance urgency against other actively exploited issues, but do not defer indefinitely on shared or privilege-boundary systems because the impact is kernel-level.