[Discussion] CVE-2026-43456 — How are you detecting the bonding driver LPE in your environment?

[merlingo]

Hi all,

I've been digging into CVE-2026-43456 (the Linux net/bonding privilege escalation patched in June) and I'm curious how others are approaching detection—not just patching.

For those unfamiliar, the bug has been sitting in net/bonding since Linux 2.6.24 (2007). It requires CAP_NET_ADMIN and works by chaining exactly 329 GRE/FOU interfaces under a bond device. At that specific count, the accumulated needed_headroom hits an alignment that causes skb->data to overlap with skb_shared_info, which a Zero-Copy callback can then turn into a write primitive → root.

What makes it interesting from a detection standpoint:

• There's no anomalous code path—it's just "ip link add" called 329 times. Every individual syscall is completely legitimate.
• Static analysis and most fuzzers would never find it because the bug only triggers at a specific arithmetic alignment.
• The traditional IOC approach (hash, binary name, IP) is blind to it entirely.

Where I'm landing on detection:

The most reliable signal seems to be behavioral velocity — monitoring the rate of rtnetlink NEWLINK operations per PID over a sliding time window. A legitimate admin or provisioning script might create 5–10 interfaces in a session; an exploit creates 329 in seconds. The burst pattern is distinct.

Some approaches I've been evaluating:

• auditd SYSCALL records for ioctl/socket ops (noisy but no kernel module needed)
• eBPF kprobe/rtnl_newlink with a per-PID counter map (precise, low overhead)
• /proc/net/dev polling with interface diff (no special privileges, but 1–2s latency)

Questions for the community:

1. Has anyone built reliable detection for this beyond "just patch it"? Particularly interested in environments where kernel upgrades are slow (embedded, RHEL long-support, etc.)
2. For those using eBPF-based endpoint tooling — are your existing probes covering rtnl_newlink or does this fall through the gaps?
3. The mitigation of blacklisting the bonding module is aggressive — it breaks legitimate networking. What are others doing in environments where bonding is actively used?

I'm planning to write up a full detection analysis once I've validated a few approaches on a test kernel. Happy to share notes if others are working on the same problem.
github repo related with the vulnerabiility
Thanks

 

[f33dm3bits]

1. Has anyone built reliable detection for this beyond "just patch it"? Particularly interested in environments where kernel upgrades are slow (embedded, RHEL long-support, etc.)

RHEL and Debian do backported security patches on their kernel and other packages.