[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.

 

[Rocky10x1]

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?

As I spend a lot of time working with AI modules, I took a brief look at CVE-2026-43456, focusing on a detection layer based on AI-assisted behavioural analysis. I had considered an approach that is non-invasive, requires no kernel modifications and does not disrupt ongoing operations.

So how might one go about this...
One could develop a behaviour monitor that tracks the "velocity" at which network interfaces are created. Rather than relying on static analyses, it monitors /proc/net/dev for rapid changes. If the difference in the number of new interfaces exceeds a threshold (e.g. 50 interfaces within 5 seconds), an anomaly is reported.

Like I said, I haven't really looked into it that much. If you'd like, we can certainly discuss this topic further, how a detection tool (perhaps one that also uses AI analysis) should work. Maybe some other users will join in and share their ideas as well.