CVE-2026-45970

What it actually does

This vulnerability is a race-condition use-after-free in the Linux kernel bonding driver when Adaptive Load Balancing/Adaptive Receive Load Balancing is in use. During bond interface teardown, the driver can free the receive load-balancing ARP hash table while the receive path is still processing ARP traffic through rlb_arp_recv(). A concurrent receive handler can then dereference freed or invalid memory, causing a kernel fault and potentially enabling broader kernel memory corruption. Because the flaw occurs in kernel context, successful exploitation could result in denial of service through a kernel crash and, depending on exploitability on a given kernel build and hardening configuration, possible local privilege escalation or compromise of kernel memory integrity.

Why it matters to the business

Systems using Linux bonding in ALB/TLB-style configurations may be vulnerable to crashes during interface state changes while ARP traffic is received. The most likely operational impact is unexpected host outage, loss of network connectivity, failover instability, and service disruption on servers that rely on bonded interfaces for availability. Although current public exploit maturity is listed as none and EPSS is low, the CVSS score reflects high potential impact because kernel memory corruption can affect the confidentiality, integrity, and availability of the entire host.

How an attack unfolds

An attacker needs local access or another path to influence network interface state changes, typically requiring privileges capable of changing link state or triggering bond reconfiguration. The vulnerable condition occurs when a bonded interface using receive load balancing is repeatedly brought up and down while ARP packets are being received. During teardown, rlb_deinitialize() frees bonding receive-balancing state, but rlb_arp_recv() may still be executing in the packet receive path. If the timing aligns, the receive handler accesses freed state, producing a use-after-free condition in kernel context. In practical terms, exploitation is most straightforward as a local denial-of-service attack against a host with vulnerable bonding configuration; more advanced exploitation would attempt to shape heap state and timing to convert the use-after-free into controlled kernel memory corruption.

How to fix it

Upgrade to a Linux kernel package from the relevant distribution or vendor that includes the bonding fix adding synchronization after clearing recv_probe and before freeing ALB/RLB receive state. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to confirm inclusion of the fix for CVE-2026-45970 or the corresponding bonding ALB/RLB use-after-free patch. Where immediate patching is not possible, reduce exposure by avoiding balance-alb configurations on vulnerable kernels, disabling unused bonding configurations, limiting who can change network interface state, restricting CAP_NET_ADMIN access in containers and local accounts, and avoiding automated workflows that rapidly flap bonded interfaces. Consider scheduling maintenance because kernel updates generally require rebooting into the fixed kernel.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed version, not merely that the package is installed. Validate with uname -r, package manager inventory, and the distribution advisory for the installed kernel stream. Check whether the bonding module is loaded and whether any active bond uses ALB/RLB behavior by inspecting /proc/net/bonding/* and looking for bonding mode values such as balance-alb. After remediation, verify that the host has rebooted into the patched kernel and that controlled bond up/down testing under ARP traffic no longer produces kernel oops, KASAN, or rlb_arp_recv traces. For mitigations, confirm that vulnerable bond modes are not configured and that untrusted users or containers do not have CAP_NET_ADMIN or equivalent permissions.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the bonding module enabled.
2. Confirm the system uses bonding mode involving ALB/RLB behavior, such as balance-alb.
3. Obtain local privileges sufficient to change bond interface state or trigger network reconfiguration events.
4. Generate or rely on incoming ARP traffic while repeatedly bringing the bond interface up and down.
5. Trigger the race between rlb_arp_recv() in the receive path and rlb_deinitialize() during bond teardown.
6. Cause a kernel oops, panic, loss of network connectivity, or potentially kernel memory corruption.

How to detect it

Look for evidence of kernel crashes or warnings involving the bonding driver, especially during bond interface flapping or ARP activity. Primary log sources include kernel ring buffer output, system journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump summaries, kdump/vmcore metadata, audit logs for network administration commands, and EDR telemetry showing ip or network-management tools changing bond state. Search for call traces mentioning rlb_arp_recv, bond_handle_frame, rlb_deinitialize, bond_alb_deinitialize, KASAN null pointer dereference, use-after-free, or general protection fault. Correlate those events with interface state changes such as ip link set bond interfaces up or down, NetworkManager/systemd-networkd activity, ifup/ifdown events, and bursts of ARP traffic. Existing exploitation is most likely to appear as repeated host crashes, kernel oops events, or network interface resets rather than a durable file-based artifact. If a crash dump is available, inspect the stack trace for rlb_arp_recv and bonding receive-path functions.

• rlb_arp_recv
• bond_handle_frame
• rlb_deinitialize
• bond_alb_deinitialize
• bond_alb_initialize
• KASAN: null-ptr-deref
• KASAN: use-after-free
• Oops: general protection fault
• RIP: 0010:rlb_arp_recv
• __pfx_rlb_arp_recv
• process_backlog
• net_rx_action
• bonding: alb
• /proc/net/bonding/
• Bonding Mode: adaptive load balancing
• Bonding Mode: balance-alb
• ip link set bond0 up
• ip link set bond0 down
• ifup bond0
• ifdown bond0

What your security team should do

• Prioritize patching Linux servers that use bonded interfaces, especially those configured for balance-alb or receive load balancing.
• Inventory systems with the bonding module loaded and review /proc/net/bonding/* for vulnerable bonding modes.
• Restrict CAP_NET_ADMIN and other privileges that allow local users, containers, or automation to bring bond interfaces up or down.
• Monitor kernel logs for rlb_arp_recv, bonding, KASAN, general protection fault, or kernel oops messages until patched.
• If patching is delayed, migrate affected bonds away from ALB/RLB modes or disable unnecessary bonded interfaces.
• Review network automation and failover scripts for rapid bond up/down cycles that could accidentally trigger the race.
• Because the vulnerability is not currently in CISA KEV and EPSS is low, prioritize based on exposure: externally critical hosts, virtualization/container platforms, and systems with multi-user local access should be handled first.