CVE-2026-43086

What it actually does

This is a Linux kernel denial-of-service flaw in the IP Virtual Server (IPVS) service creation error path. When adding an IPVS service, the kernel can successfully bind a scheduler, clear a local scheduler pointer, then hit a later failure in estimator startup. The cleanup path passes the now-NULL scheduler pointer into ip_vs_unbind_scheduler(), which dereferences it and triggers a kernel general protection fault or panic. Successful exploitation does not provide code execution or data access; the primary impact is local kernel crash and system availability loss. Exploitation requires local ability to exercise IPVS configuration paths, typically through privileges or capabilities sufficient to modify IPVS/netfilter settings, such as CAP_NET_ADMIN in the relevant namespace.

Why it matters to the business

An attacker or misconfigured local workload with permission to manage IPVS can crash affected Linux systems, causing service interruption, node reboot, workload disruption, or loss of availability for systems using Linux load balancing, container networking, or IPVS-backed service routing. The currently reported exploitation likelihood is low, with no known KEV listing, no ransomware association, and stable low EPSS, but the operational impact can be high on systems where a kernel panic affects production traffic or clustered workloads.

How an attack unfolds

An attacker first obtains local access to an affected Linux host or a containerized context with sufficient network administration capability to configure IPVS. They then attempt to add an IPVS service in a way that causes ip_vs_bind_scheduler() to succeed but ip_vs_start_estimator() to fail. Because the vulnerable error path has cleared the local scheduler pointer, cleanup calls ip_vs_unbind_scheduler() with a NULL argument while the service still records an installed scheduler. The kernel dereferences the NULL scheduler pointer at the scheduler done_service callback offset, producing a general protection fault, Oops, or panic. The result is denial of service through host instability or reboot rather than persistent compromise.

How to fix it

Apply the vendor or distribution kernel update that includes the upstream IPVS fix for ip_vs_add_service cleanup handling. Because no exact fixed package versions were provided, use the latest supported kernel from the relevant Linux distribution or kernel vendor and confirm the changelog references the IPVS NULL dereference fix in ip_vs_add_service/ip_vs_unbind_scheduler. Reboot into the patched kernel after installation. If immediate patching is not possible, reduce exposure by disabling IPVS modules where unused, preventing untrusted users and containers from receiving CAP_NET_ADMIN, restricting creation of privileged containers and network namespaces, and limiting IPVS administration tools such as ipvsadm to trusted administrators only. On systems that rely on IPVS for load balancing or orchestration, test kernel updates in staging before production rollout to avoid networking regressions.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported patched build, not only that a package has been installed; verify with uname -a, package manager metadata, and vendor advisories or changelogs. Check whether IPVS is present or loaded using lsmod, /proc/modules, /proc/net/ip_vs, and ipvsadm -Ln where applicable. Validate that untrusted users and workloads do not have CAP_NET_ADMIN or privileged container permissions. After patching and rebooting, monitor dmesg, journald, and kernel logs for absence of crashes containing ip_vs_unbind_scheduler or ip_vs_add_service during IPVS service changes. In controlled test environments only, exercise normal IPVS service add/remove operations and confirm no kernel Oops or panic occurs.

Typical attack path

1. Gain local access to an affected Linux system or container environment.
2. Obtain or abuse permissions capable of modifying IPVS/netfilter configuration, commonly CAP_NET_ADMIN or equivalent administrative rights.
3. Trigger IPVS service creation using IPVS control interfaces, for example via ipvsadm or direct setsockopt/netfilter control paths.
4. Cause the service-add operation to enter the error path after scheduler binding but after estimator startup failure.
5. Kernel cleanup dereferences a NULL scheduler pointer in ip_vs_unbind_scheduler().
6. The host records a kernel Oops/general protection fault and may panic, reboot, or become unavailable.

How to detect it

Look for evidence of kernel crashes or panics involving the IPVS service creation path. Primary sources are dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, and hypervisor or cloud console reboot events. Search for stack traces containing ip_vs_unbind_scheduler, ip_vs_add_service, do_ip_vs_set_ctl, nf_setsockopt, and null pointer dereference messages around unexpected reboots. Correlate crash timing with audit logs or shell history showing IPVS administration, ipvsadm execution, changes to /proc/net/ip_vs, privileged container starts, namespace creation, or processes granted CAP_NET_ADMIN. Because this flaw results in a crash rather than a durable implant, post-exploitation artifacts are likely limited to kernel logs, crash dumps, command history, auditd records, and orchestration events showing privileged network configuration activity shortly before the outage.

• ip_vs_unbind_scheduler
• ip_vs_add_service
• do_ip_vs_set_ctl
• nf_setsockopt
• KASAN: null-ptr-deref
• null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
• Oops: general protection fault
• RIP: 0010:ip_vs_unbind_scheduler
• net/netfilter/ipvs/ip_vs_sched.c:69
• net/netfilter/ipvs/ip_vs_ctl.c:1500
• ipvsadm
• /proc/net/ip_vs
• /proc/net/ip_vs_stats
• ip_vs
• ip_vs_rr
• ip_vs_wrr
• ip_vs_lc
• ip_vs_wlc

What your security team should do

• Prioritize patching affected Linux kernels on systems where IPVS is enabled, where container workloads can receive CAP_NET_ADMIN, or where host availability is critical.
• Inventory hosts using IPVS through loaded modules, /proc/net/ip_vs, orchestration mode, or ipvsadm output.
• Remove CAP_NET_ADMIN and privileged-container access from untrusted workloads and users unless explicitly required.
• Disable or unload IPVS modules on systems that do not require Linux IPVS load balancing.
• Review kernel logs from the publication date onward for crashes referencing ip_vs_unbind_scheduler, ip_vs_add_service, KASAN null-ptr-deref, or general protection faults in IPVS code.
• Ensure kernel crash handling, automatic reboot behavior, and cluster failover policies are configured so a node panic does not create prolonged service outage.
• Track distribution-specific advisories because fixed package names and versions vary by vendor kernel stream.