UBUNTU-CVE-2026-99251: Medium severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: Avoid infinite retry loop in initvpindex() There is a retry loop in initvpindex() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HKTYPEMANAGEDIRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HKTYPEMANAGEDIRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of initvpindex(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel function init_vp_index(), update the early-abort check to test whether any housekeeping CPU is online, and skip NUMA nodes with no housekeeping CPU in the inner while loop to prevent an infinite retry loop.
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
The issue affects the listed Ubuntu Linux kernel packages, including standard, cloud, Oracle, Azure, GCP, AWS, and FIPS variants. It requires a NUMA-node CPU layout in which a particular node has no CPUs in the HK_TYPE_MANAGED_IRQ housekeeping CPU mask.
What is the operational impact if the condition is triggered?
The kernel can enter an infinite retry loop in init_vp_index() while attempting to allocate CPUs for a NUMA node. This is a denial-of-service or hang condition rather than a described privilege-escalation or data-disclosure issue.
Is this likely to affect typical configurations?
The description states that the condition should rarely occur. It depends on a specific mismatch between NUMA-node CPUs and the managed-IRQ housekeeping CPU mask, so systems without that configuration are not described as triggering the loop.
What can be done if a fixed kernel cannot be deployed immediately?
Avoid configurations where a NUMA node has no online CPU in the HK_TYPE_MANAGED_IRQ housekeeping CPU mask. The fix changes the kernel to skip such nodes and to check for the absence of online housekeeping CPUs.