data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-43456 in the interactive tracker

CVE-2026-43456

bonding: fix type confusion in bond_setup_by_slave()

7.8 EPSS 0.2% AV:L

Published 2026-05-08 (5 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-43456 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormvulnerable6.1.190-1No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixiefixed6.12.85-1Update the kernel and reboot. Fixed in 6.12.85-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed6.19.10-1Update the kernel and reboot. Fixed in 6.19.10-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed6.19.10-1Update the kernel and reboot. Fixed in 6.19.10-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: <TASK> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/bonding/bond_main.c

What this is
BONDING DRIVERMAINTAINERS section matched on drivers/net/bonding/ · netdev@vger.kernel.org · Maintained
Kernel module
bonding

Check it on the machine

grep -w CONFIG_BONDING /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w bonding

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

  • bookworm, trixie, forky, sidm
m
a loadable module on every flavour - check lsmod, can be blacklisted
Build switch
CONFIG_BONDING

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-05-08 (5 months ago)source
CVSS
7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.16%, higher than 4.8% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
2.6.246.6.1455d0fb9806ab6
2.6.246.12.789baf26a91565
2.6.246.18.196ac890f1d60a
2.6.246.19.995597d11dc8b
2.6.247.0950803f72547

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The vulnerable path is reached through local rtnetlink/AF_PACKET operations: creating/enslaving a non-Ethernet slave to a bond and then causing `dev_hard_header()` on the bond device. Remote packets are not sufficient without the vulnerable local device configuration.
AC:LAttack complexity, low
No race or special external timing is required; the attacker can deterministically create the bond/GRE setup and trigger the confused header callback. Required modules/configuration are common and autoloadable through rtnetlink in normal deployments.
PR:LPrivileges required, low
The setup requires `CAP_NET_ADMIN` and the AF_PACKET trigger requires `CAP_NET_RAW`, but both are obtainable by an unprivileged local user inside a user/network namespace. Therefore this is low privilege rather than real init-namespace root only.
UI:NUser interaction, none
Exploitation does not require a victim user to perform an action. The attacker can perform the setup and trigger locally.
S:UScope, unchanged
The impact is within the kernel security authority on the same system. This is not a VM escape, IOMMU bypass, or cross-authority boundary violation.
C:HConfidentiality impact, high
The bug is kernel type confusion where bonding private data is interpreted as another device's private structure, and the confused callback can read kernel data using the wrong layout. Following the required higher-severity rule for type confusion, confidentiality impact is High.
I:HIntegrity impact, high
The confused header callback uses bogus private-data fields to construct and push protocol headers into an skb, making this a kernel memory/type confusion condition rather than a pure NULL dereference. Type confusion is scored as High integrity impact.
A:HAvailability impact, high
The reported failure is a kernel BUG/oops in `pskb_expand_head()` reachable through the confused `ipgre_header()` call. This provides a reliable local kernel crash/DoS.