CVE-2026-43086
Description
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix NULL deref in ip_vs_add_service error path When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local variable sched is set to NULL. If ip_vs_start_estimator() subsequently fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched) with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL check (because svc->scheduler was set by the successful bind) but then dereferences the NULL sched parameter at sched->done_service, causing a kernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: <TASK> ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..] Fix by simply not clearing the local sched variable after a successful bind. ip_vs_unbind_scheduler() already detects whether a scheduler is installed via svc->scheduler, and keeping sched non-NULL ensures the error path passes the correct pointer to both ip_vs_unbind_scheduler() and ip_vs_scheduler_put(). While the bug is older, the problem popups in more recent kernels (6.2), when the new error path is taken after the ip_vs_start_estimator() call.
How to fix
- linux linux_kernel6.6.136, 6.12.83, 6.18.24, 6.19.14 or later
Affected products
| Product | Affected versions | Fixed in |
|---|---|---|
| linux linux_kernel | 6.2.1 ≤ v < 6.6.136, 6.7 ≤ v < 6.12.83, 6.13 ≤ v < 6.18.24, 6.19 ≤ v < 6.19.14, 6.2, 7.0 | 6.6.136, 6.12.83, 6.18.24, 6.19.14 |
Check your version
Choose the product and enter the version you run to see whether it falls in the affected range.
Attack Surface Management
See the assets tied to your domains, the technologies they run and known vulnerabilities in one list.