Skip to main content

OSSA-2026-022: Nova scheduler hint injection bypasses Placement resource claims and scheduling constraints

PropertyValue
Date2026-06-16
CVECVE-2026-46448
SeverityHigh
Affected ProjectNova
ReporterErichen (Institute of Computing Technology, Chinese Academy of Sciences)

Summary​

A vulnerability was discovered in OpenStack Nova where the server create API does not strip internal scheduler hints. By injecting the internal _nova_check_type hint (set to rebuild) into os:scheduler_hints when creating a server, an authenticated user can make Nova treat the create request as an in-place rebuild. This skips the Placement resource claim and bypasses scheduling constraint enforcement, including availability zone, host aggregate, and image trait restrictions. The resulting instance has no Placement allocation, which can lead to compute node resource exhaustion and cross-tenant data persistence on local NVMe devices after instance deletion.

Every OSISM deployment running an unpatched Nova version is affected. Exploitation only requires an authenticated user who is allowed to create servers; no special configuration is needed and there is no configuration that makes a deployment immune.

Affected Versions​

All released Nova versions from 18.0.0 (Rocky) onwards are affected. The vulnerability was introduced with the Placement allocation skip for rebuilds in Nova 18.0.0.

At the time of this advisory there is no fixed Nova release available upstream for any series. The upstream fixes are still under review on OpenDev and have not been released yet. Once merged, they are expected to appear in Epoxy 31.3.1, Flamingo 32.2.1, Gazpacho 33.0.2, and the Hibiscus development branch.

OpenStack ReleaseLatest Released Nova VersionUpstream Status
Caracal (2024.1)29.4.0Vulnerable — end of maintenance, no upstream fix
Dalmatian (2024.2)30.3.0Vulnerable — end of life, no upstream fix
Epoxy (2025.1)31.3.0Vulnerable — fix proposed (31.3.1), not yet released
Flamingo (2025.2)32.2.0Vulnerable — fix proposed (32.2.1), not yet released
Gazpacho (2026.1)33.0.1Vulnerable — fix proposed (33.0.2), not yet released

Caracal (2024.1) has reached end of maintenance and Dalmatian (2024.2) end of life upstream; neither will receive an official fixed release.

OSISM already ships container images with the fix backported as downstream patches for all supported OpenStack releases — 2024.1 (Caracal), 2024.2 (Dalmatian), 2025.1 (Epoxy), and 2025.2 (Flamingo) — and these patched images are available now. For Epoxy and Flamingo the images carry the proposed upstream patch ahead of its official upstream release; for Caracal and Dalmatian, which will receive no official upstream fix, OSISM provides community-curated backports.

Impact on OSISM​

Unlike most Nova advisories, this issue is not limited to specific configurations: every OSISM deployment running an unpatched Nova version is affected. Any authenticated user who is allowed to create servers can exploit it, and there is no configuration that makes a deployment immune.

How to Check if You Are Affected​

Check the Running Nova Version​

docker exec nova_api nova-manage --version 2>/dev/null || \
  docker exec nova_api pip show nova 2>/dev/null | grep -i version

Because no fixed Nova release exists upstream yet, your deployment is affected unless you have deployed an OSISM container image that includes the backported fix (see Remediation).

Vulnerability Details​

Nova's POST /servers API accepts user-supplied scheduling hints via os:scheduler_hints. The JSON schema for these hints allows additional properties and does not filter Nova's internal, _nova_-prefixed hints, and the hints are forwarded to the scheduler without sanitization.

By supplying _nova_check_type with the value rebuild, an attacker causes the scheduler to treat the server create as an in-place rebuild. (The DictOfListOfStringsField object field coerces the scalar string "rebuild" into the list ["rebuild"], which exactly matches the scheduler's rebuild check.) Because rebuilds reuse the existing host, the scheduler skips the Placement resource claim and bypasses the regular scheduling filters.

As a result:

  • No Placement allocation is created for the instance, leaving Placement and Nova in an inconsistent state.
  • Resource exhaustion becomes possible, because unaccounted instances can be packed onto compute nodes beyond their tracked capacity.
  • Scheduling constraints are bypassed, including availability zone mapping, host aggregate tenant isolation, and image trait restrictions.
  • Cross-tenant data persistence can occur: with no allocation, cleanup reservations may be skipped, potentially leaving tenant data on local NVMe storage across instance boundaries.
  • Expensive devices (e.g. GPUs, NVMe) can be consumed without proper accounting or billing.

The fix strips all _nova_-prefixed scheduler hints at the API boundary before the request is processed, while leaving legitimate hints untouched.

Remediation​

For OSISM Releases​

Because no fixed Nova release is available upstream, OSISM provides the fix as downstream patches for the Nova container images via the following change:

This change adds the patch for all four supported releases (2024.1, 2024.2, 2025.1, 2025.2).

A fix will be included in upcoming OSISM releases that ship the patched Nova container images. Consult the OSISM Release Notes for version information and availability.

The fix is applied at the API boundary, so it is sufficient to override the nova-api container image. Using rolling tags, configure the following in environments/kolla/images.yml:

nova_api_tag: "2025.1"  # or "2024.1", "2024.2", "2025.2", depending on your OpenStack release

Mitigation​

Because all deployments are affected and exploitation requires only an authenticated user that can create servers, applying the patched container image is the only effective remediation. Until the fix is deployed, consider the following measures:

  1. Restricting who is allowed to create servers and to pass scheduler hints via policy overrides
  2. Auditing instances for missing Placement allocations (for example with nova-manage placement audit) and reconciling any inconsistencies
  3. Monitoring for instances that were placed in violation of availability zone, host aggregate, or image trait constraints

References​