Fedora Account System
Red Hat Associate
Red Hat Customer
Tore Anderson (Redpill Linpro AS) reported a vulnerability in OpenStack Designate zone scheduling. The database uniqueness constraint on zone names is scoped to (name, deleted, pool_id) in designate/storage/sqlalchemy/tables.py:146, allowing the same zone name to exist in multiple pools. The _is_subzone() and _is_superzone() ownership checks in designate/central/service.py (lines 288-328) include pool_id in their query criteria, making them pool-scoped rather than global. When the AttributeFilter scheduler (designate/scheduler/filters/attribute_filter.py) is enabled, any authenticated tenant with the default create_zone policy (role:member) can supply zone attributes that match a non-default pool, directing their zone there and bypassing the ownership checks. This allows cross-tenant zone overlap, subzone ownership bypass, and superzone takeover. Omer Schwartz (Red Hat) discovered a related vulnerability in the mDNS handler. The _handle_notify() method in designate/mdns/handler.py (lines 90-171) performs a zone lookup using only {name, type='SECONDARY', deleted=False} without pool_id scoping. When colliding zones exist across pools, the storage layer's _find() method (designate/storage/sqlalchemy/base.py:270-280) finds 2 results and raises ZoneNotFound (it expects exactly 1 with one=True), causing all NOTIFY processing for the affected zone name to fail with NOTAUTH. This NOTIFY handler path is reachable via unauthenticated UDP on port 5354 (default: 0.0.0.0:5354) because the SerializationMiddleware creates an admin context with all_tenants=True for every request and TSIG enforcement is off by default. The QUERY and AXFR handlers were previously updated to be pool-aware via _zone_criterion_from_request(), but the NOTIFY handler was not updated. Affected versions: >=1.0.0 <20.0.2, >=21.0.0 <21.0.1, >=22.0.0 <22.0.1. Only deployments using the AttributeFilter scheduler with multiple pools are affected. The default configuration uses the default_pool filter and is not vulnerable to the zone overlap (Vuln 1), but remains vulnerable to the mDNS NOTIFY DoS (Vuln 2) if colliding zones are created by other means (e.g., admin using PoolIDAttributeFilter). Upstream patches provided for master, stable/2025.1, stable/2025.2, and stable/2026.1 branches. Proposed public disclosure: 2026-08-11 1500UTC. Original private report: https://launchpad.net/bugs/2160533 PSIRT Ticket: PSIRTSUPT-20989