CVE-2026-53270

What it actually does

This is a Linux kernel use-after-free flaw in IP Virtual Server (IPVS) service editing. When an IPVS virtual service scheduler is replaced, the old scheduler can remain referenced after its scheduler-specific data has already been released following an RCU grace period. Under concurrent packet processing, traffic may still dereference the stale scheduler pointer, potentially causing kernel memory corruption, kernel crashes, or other undefined behavior. Practical exploitation likely requires the ability to modify IPVS service configuration, such as privileges equivalent to CAP_NET_ADMIN, and a race with live packet handling.

Why it matters to the business

Systems using Linux IPVS for load balancing, high-availability routing, or container networking could be destabilized if an attacker or compromised privileged workload can change IPVS scheduler settings while traffic is active. The most likely operational consequence is denial of service through kernel crashes or impaired load balancing. There is no indication that this vulnerability is in CISA KEV, used in ransomware campaigns, or currently has public exploit maturity; EPSS is low, so urgency is highest for internet-facing load balancers, Kubernetes nodes using IPVS mode, and multi-tenant systems where network administration privileges may be delegated.

How an attack unfolds

An attacker first needs sufficient privileges to administer IPVS configuration, typically through ipvsadm, netlink-based tooling, a compromised load-balancer management plane, or a privileged container or process with CAP_NET_ADMIN in a relevant network namespace. The attacker identifies or creates an IPVS virtual service receiving traffic, then repeatedly edits the service to replace its scheduler while packets are being processed. In the vulnerable kernel path, the old scheduler can schedule RCU cleanup while the service still exposes a pointer to it. After the grace period, scheduler data can be freed, but packet processing may still follow the stale pointer. A successful race can trigger a use-after-free condition in kernel context, commonly leading to an oops, panic, or service disruption; more advanced memory-corruption exploitation is theoretically possible but not evidenced by the available maturity data.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the IPVS fix for clearing the service scheduler pointer early during scheduler unbind. Because no exact affected or fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor and verify the changelog includes the IPVS scheduler pointer fix. If immediate patching is not possible, reduce exposure by disabling IPVS where it is not required, unloading unused ip_vs modules, switching affected load-balancing components to a non-IPVS mode where operationally safe, restricting CAP_NET_ADMIN and privileged container access, limiting use of ipvsadm or equivalent IPVS netlink tooling to trusted administrators, and avoiding scheduler changes on active services until patched.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that a package is installed; reboot if required so the patched kernel is active. Review vendor changelogs or source patches for the fix described as clearing the IPVS service scheduler pointer early in ip_vs_unbind_scheduler or similar wording. Check exposure by verifying whether IPVS is loaded or configured using sources such as /proc/net/ip_vs, lsmod output for ip_vs modules, ipvsadm -Ln, and container networking or kube-proxy configuration for IPVS mode. After remediation, monitor for absence of kernel oops, panic, KASAN use-after-free reports, and IPVS instability during controlled scheduler-change testing in non-production environments.

Typical attack path

1. Obtain IPVS administration capability, such as root, CAP_NET_ADMIN, or control of a privileged network-management component.
2. Confirm IPVS is enabled and an IPVS virtual service is configured or create one if permissions allow.
3. Generate or wait for live traffic through the affected IPVS service.
4. Repeatedly edit the virtual service scheduler, for example by changing scheduling algorithms, while traffic is being processed.
5. Win the race where packet processing uses the old scheduler after scheduler-specific data has been freed.
6. Trigger kernel instability, crash, or potentially broader memory-corruption effects.

How to detect it

To determine whether this was already exploited or accidentally triggered, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts from IPVS-enabled systems for kernel oops, panic, KASAN, slab, or RCU-related failures occurring near IPVS service edits. Correlate those events with audit logs, shell history, EDR process telemetry, sudo logs, and orchestration logs showing use of ipvsadm, modprobe of IPVS modules, or privileged network-configuration activity. In Kubernetes or containerized environments, review kube-proxy logs, privileged container activity, and capability grants involving CAP_NET_ADMIN. Look for repeated scheduler changes on active IPVS services, especially by unexpected users or processes. Because no public exploit indicators or actor-specific artifacts are known from the provided data, detection should focus on behavioral evidence: unauthorized IPVS configuration changes followed by kernel memory-corruption symptoms or host reboots.

• BUG: KASAN: use-after-free
• use-after-free in ip_vs
• ip_vs_edit_service
• ip_vs_unbind_scheduler
• IPVS
• ipvsadm
• /proc/net/ip_vs
• ip_vs
• ip_vs_rr
• ip_vs_wrr
• ip_vs_lc
• ip_vs_wlc
• ip_vs_sh
• ip_vs_dh
• ip_vs_sed
• ip_vs_nq
• ip_vs_fo
• ip_vs_ovf
• general protection fault
• kernel panic
• Oops:
• RCU callback
• Unable to handle kernel paging request

What your security team should do

• Prioritize patching Linux systems that use IPVS for production load balancing, Kubernetes IPVS mode, network appliances, or high-availability routing.
• Inventory hosts with IPVS enabled by checking loaded ip_vs modules, /proc/net/ip_vs, ipvsadm output, and orchestration platform network proxy modes.
• Restrict CAP_NET_ADMIN, privileged containers, and access to IPVS management tools to the smallest practical set of trusted administrators and services.
• Add monitoring for IPVS scheduler changes, ipvsadm execution, privileged netlink configuration activity, and kernel crash signatures on systems where IPVS is enabled.
• If patching must be delayed, avoid changing IPVS schedulers on live services and consider temporarily disabling IPVS or moving to an alternative load-balancing mode where feasible.
• Treat unexplained kernel oops or panic events on IPVS-enabled systems as potentially security-relevant until logs and administrative activity are reviewed.