CVE-2026-52975

What it actually does

This is a Linux kernel race condition in the bonding driver’s IEEE 802.3ad/LACP handling. The vulnerable code accesses the bonding port-to-aggregator pointer without proper RCU synchronization while one path updates aggregator state and another path reads active aggregator information through rtnetlink. Under concurrent bond state changes and network link information queries, the kernel may observe inconsistent or stale state. The practical impact is most likely kernel warning, instability, incorrect bonding state reporting, network-interface disruption, or a crash; there is no public evidence of reliable privilege escalation or remote code execution.

Why it matters to the business

Systems using Linux bonding in 802.3ad/LACP mode may experience network instability or host disruption if the race is triggered. This is most relevant for servers, virtualization hosts, appliances, and storage or compute nodes that rely on bonded interfaces for availability or throughput. Current exploitation likelihood appears low: EPSS is 0.00139, it is not listed in CISA KEV, it is not associated with ransomware, and no mature public exploit is indicated. However, because kernel networking faults can affect availability, organizations using LACP bonding should still remediate through normal kernel update cycles, with higher priority for multi-tenant or containerized environments where untrusted workloads may receive CAP_NET_ADMIN or network namespace control.

How an attack unfolds

An attacker would need local ability to influence Linux network configuration or network namespace state, typically through CAP_NET_ADMIN, privileged container permissions, or another administrative pathway. They would target a host using the Linux bonding driver in 802.3ad mode, then repeatedly cause bond state transitions while concurrently querying or changing link information through rtnetlink/netlink interfaces. The objective is to win the timing window between the bonding state machine updating the port aggregator pointer and another kernel path reading active aggregator information. If successful, the kernel may process inconsistent bonding state, producing warnings, corrupted interface state, network disruption, or a denial-of-service condition. There is no indication from the provided data that this issue is remotely exploitable over the network without local network-administration privileges.

How to fix it

Apply the Linux kernel update from the relevant operating-system or appliance vendor that includes the bonding 802.3ad RCU synchronization fix for port->aggregator. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to confirm the patch is included. Reboot into the fixed kernel after installation. Where immediate patching is not possible, reduce exposure by avoiding 802.3ad/LACP bonding on untrusted or multi-tenant systems, restricting CAP_NET_ADMIN, avoiding privileged containers unless required, disabling unprivileged user namespaces where operationally feasible, and limiting who can create or modify network namespaces and bond interfaces.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build that contains the bonding driver fix implementing proper RCU handling for port->aggregator. Validate that the system has rebooted into the patched kernel, not merely installed it. Review vendor package metadata, kernel changelogs, or source patches for changes in drivers/net/bonding/bond_3ad.c involving __rcu and RCU accessors around port->aggregator. On systems that use bonding, enumerate bonded interfaces and identify those using mode 4 / 802.3ad. After patching, monitor dmesg, journald, and kernel logs during normal bond failover or link-change testing to ensure no KCSAN, WARN, oops, panic, or bonding-driver instability messages recur.

Typical attack path

1. Obtain local code execution with network-administration capability, such as CAP_NET_ADMIN, privileged container access, or control of a network namespace.
2. Identify or create a Linux bonding interface configured for IEEE 802.3ad/LACP mode.
3. Generate repeated bond link-state or aggregator-selection changes to exercise the bonding state machine.
4. Concurrently issue rtnetlink/netlink operations that request or modify link information for the bonded interface.
5. Attempt to trigger the unsynchronized read/write race on the port aggregator pointer.
6. Observe whether the host logs kernel warnings, loses bonded-interface stability, or crashes/reboots.

How to detect it

There are no known public exploitation campaigns, named threat actors, or ransomware use associated with this issue in the provided data. Detection should focus on signs that the vulnerable kernel path was exercised or that a local actor attempted to stress bonding and rtnetlink behavior. Review kernel logs from dmesg, journald, syslog, crash dumps, and hypervisor or appliance event logs for bonding-driver warnings, KCSAN data-race reports, kernel oopses, panics, unexpected reboots, and repeated link-state changes involving bonded interfaces. Also review audit logs and container orchestration logs for unexpected use of CAP_NET_ADMIN, privileged containers, creation or modification of bond interfaces, network namespace manipulation, and high-volume rtnetlink activity by non-standard processes. Because the likely outcome is instability rather than a persistent implant, absence of durable artifacts does not rule out an attempted trigger.

• BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler
• bond_3ad_get_active_agg_info
• bond_3ad_state_machine_handler
• ad_port_selection_logic
• drivers/net/bonding/bond_3ad.c
• drivers/net/bonding/bond_netlink.c
• bond_fill_info
• rtnl_newlink
• rtnetlink_rcv_msg
• netlink_sendmsg
• mode 802.3ad
• mode 4
• bond0: link status definitely down
• bond0: link status definitely up
• bond0: Warning: No 802.3ad response from the link partner

What your security team should do

• Inventory Linux systems using bonding mode 802.3ad/LACP, prioritizing virtualization hosts, storage nodes, network appliances, and high-availability servers.
• Patch affected Linux kernels through the appropriate vendor channel and schedule reboots into the fixed kernel.
• Prioritize remediation for systems where containers, tenants, CI jobs, or non-administrative users may receive CAP_NET_ADMIN or privileged network namespace access.
• Restrict CAP_NET_ADMIN, privileged containers, and bond-interface management to trusted administrative workflows only.
• Monitor kernel logs for bonding-driver warnings, KCSAN race reports, netlink-triggered interface errors, unexplained bond failovers, and host crashes.
• If patching is delayed, consider temporarily avoiding 802.3ad bonding on exposed multi-tenant systems or moving critical workloads to already patched hosts.
• Track vendor advisories because exact fixed package versions were not provided in the input.