CVE-2026-74670: ipvs: stop estimator after disabled calc phase
In the Linux kernel, the following vulnerability has been resolved:
ipvs: stop estimator after disabled calc phase
IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ipvsestcalcphase() can return without installing positive limits.
The kthread can then continue into its main loop and drain esttemplist with zero chainmax, tickmax and estmaxcount values. Each enqueue consumes one available tick row, but estcount never reaches the zero estmaxcount value. After all rows are consumed, the row lookup returns IPVSESTNTICKS and ipvsenqueueestimator() writes past the ticks and ticklen arrays.
Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize.
Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthreadstopput(), so kd->task remains valid until the stop paths consume that reference.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel systems using IPVS can be affected when IPVS is disabled as part of network namespace teardown while estimator kthread 0 is still in its initial calculation phase.
What failure can occur when the race is triggered?
The estimator thread can continue with zero-valued limits and eventually write past the ticks and tick_len arrays after exhausting available tick rows.
What does the fix change during teardown or reload?
The estimator kthread now exits after its calculation phase if it is stopping or IPVS has been disabled. The change also retains a task reference so the task remains valid until teardown or reload stop paths consume it.