CVE-2026-45917

What it actually does

This is a Linux kernel race condition in the IPVS load-balancing subsystem. When a network device is going down, IPVS may drop an old cached destination route while another code path obtains and attaches a new route for the same closing device. That can leave a stale destination cache holding a leaked network-device reference. The primary impact is availability: affected systems can accumulate unreleased device references, interfere with network-device teardown, and potentially degrade or exhaust kernel/network resources. The flaw requires local access and privileges sufficient to manipulate relevant IPVS/networking state; it does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Systems that use Linux IPVS for load balancing, container networking, service routing, or high-availability traffic distribution may experience network instability, failed interface cleanup, stuck virtual devices, degraded node reliability, or denial of service. The current public risk signal is low: EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported. However, kernel availability bugs can still be operationally significant in dense container, Kubernetes, or load-balancing environments where network devices are frequently created and destroyed.

How an attack unfolds

An attacker with local access and the ability to influence IPVS configuration and network-device lifecycle repeatedly creates or modifies IPVS destinations associated with a network interface, then races route caching against the interface shutdown path. If the timing is successful, IPVS may cache a route for a device that is already going down after the notifier has cleared the previous cached route. The cached destination retains a device reference that is not released until the IPVS destination is removed. Repeating this condition can cause leaked references, delayed or failed device teardown, and cumulative availability degradation. Practical exploitation is most plausible where an attacker can obtain CAP_NET_ADMIN-like capabilities, control a network namespace, operate container networking primitives, or run tooling that changes IPVS state such as service load-balancer configuration.

How to fix it

Upgrade to a kernel version or vendor-maintained kernel package that includes the upstream fix for the IPVS change titled "ipvs: do not keep dest_dst if dev is going down." Because no exact fixed versions were provided, use the relevant Linux distribution, appliance, cloud image, or kernel vendor advisory to identify the patched package. After updating the kernel, reboot into the patched kernel and verify the running kernel version, not just the installed package version. If immediate patching is not possible, reduce exposure by disabling or unloading IPVS modules where unused, removing unused IPVS services and destinations, limiting CAP_NET_ADMIN and network-namespace creation rights, restricting privileged containers, and minimizing workflows that rapidly create/delete virtual network devices on affected systems.

How to confirm the fix worked

Confirm whether the host is exposed by checking whether IPVS is enabled or loaded, such as the presence of /proc/net/ip_vs, loaded ip_vs modules, active ipvsadm output, or kube-proxy/IPVS mode. Confirm remediation by verifying the running kernel package includes the vendor backport or upstream patch for "ipvs: do not keep dest_dst if dev is going down" and that the system has rebooted into that patched kernel. Operationally validate by exercising normal IPVS and network-interface lifecycle operations and confirming there are no recurring kernel messages about network devices waiting to be freed, no increasing unreleased virtual-interface counts, and no abnormal IPVS destination persistence after interface shutdown.

Typical attack path

1. Gain local execution on a Linux host or inside a context with permission to manipulate network namespaces, IPVS, routes, or network interfaces.
2. Confirm the IPVS subsystem is present and active, for example through loaded ip_vs modules or populated IPVS service tables.
3. Create or modify IPVS services and destinations bound to a network device or virtual interface.
4. Repeatedly bring the associated network device down or trigger device deletion while forcing route lookups or IPVS destination cache updates.
5. Win the race between the IPVS destination-cache update path and the network-device shutdown notifier.
6. Accumulate leaked device references, causing network-device teardown delays, resource retention, or denial-of-service conditions.
7. Repeat the cycle to increase operational impact until IPVS destinations are removed, the node is remediated, or the system is rebooted.

How to detect it

To assess possible prior exploitation, review kernel logs, audit logs, command execution telemetry, EDR events, and container/runtime logs for suspicious correlation between IPVS changes and network-device shutdowns. Key sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd execve records, shell history where available, container runtime logs, Kubernetes node logs, kube-proxy logs when using IPVS mode, and network automation logs. Look for repeated or unusual use of ipvsadm, ip link set down/delete operations, namespace creation/deletion, privileged container starts, or CAP_NET_ADMIN grants followed by kernel messages indicating network devices cannot be freed. There is no known public exploit signature and successful exploitation may leave only operational artifacts such as stuck virtual interfaces, unreleased device references, or repeated kernel warnings. Treat the listed indicators as leads for triage rather than definitive proof of compromise.

• unregister_netdevice: waiting for
• Usage count =
• ipvsadm
• ip_vs
• /proc/net/ip_vs
• ip link set
• ip link delete
• ip netns add
• ip netns delete
• CAP_NET_ADMIN
• kube-proxy --proxy-mode=ipvs
• modprobe ip_vs

What your security team should do

• Inventory Linux systems using IPVS, especially load balancers, Kubernetes nodes using IPVS mode, container hosts, and systems with frequent virtual-interface churn.
• Prioritize patching exposed IPVS-enabled systems in production networking paths even though the CVE is not in KEV and has low EPSS, because availability impact can affect service reliability.
• Apply vendor kernel updates that contain the IPVS race-condition fix and reboot systems into the patched kernel.
• Temporarily disable IPVS where it is not required, or switch affected systems to a supported alternative networking mode if operationally acceptable.
• Restrict local users, containers, and automation from obtaining CAP_NET_ADMIN or equivalent privileges unless strictly required.
• Review privileged container workloads and network automation that can create/delete interfaces or change IPVS rules.
• Monitor kernel logs for device-reference leak symptoms and repeated interface teardown failures.
• Add detection for unusual bursts of ipvsadm, ip link, network namespace, or virtual-device lifecycle operations from non-administrative contexts.
• If symptoms are observed, preserve kernel logs, audit logs, process execution telemetry, and IPVS state before rebooting or clearing configurations.