A pool-operator can cause a complete network outage across every host in the pool by setting Pool.other_config:vswitch-controller-fail-mode to "secure". This pool-level key serves as the default fail mode for every OVS bridge that does not have a per-network override. Without an SDN controller - the common case in most XAPI deployments - ALL network traffic is dropped on ALL bridges across ALL hosts pool-wide. This is the pool-scoped counterpart of the per-network NOC-2 vector (MOKSHA-2026-0012), with the critical difference that a single key write affects the entire pool rather than a single network.
Pool.other_config is the highest-scope other_config field in the XAPI data model. A single key write affects behavior across every host and VM in the pool. The vswitch-controller-fail-mode key at the pool level serves as the default for all OVS bridges that do not have a per-network override set in Network.other_config.
pool-operator calls Pool.add_to_other_config(pool, "vswitch-controller-fail-mode", "secure")
-> openvswitch-config-update reads Pool.other_config as default
-> For every bridge without a per-network override:
-> ovs-vsctl set-fail-mode <bridge> secure
-> No SDN controller configured (common case) -> ALL packets dropped
-> Pool-wide network outage: all VMs, all hosts, all management traffic
The openvswitch-config-update script reads the pool-level fail mode as the default and applies it to every OVS bridge on every host that does not have a per-network override. This creates a single point of failure controlled by a single API call.
Missing RBAC protection. Pool.other_config has zero map_keys_roles entries for infrastructure keys. The vswitch-controller-fail-mode key is writable by pool-operator.
Missing pre-condition validation. No check verifies that an SDN controller is configured before accepting secure as the pool-wide default. This combination is always destructive.
Pool-wide blast radius. A single key write propagates to every OVS bridge on every host in the pool, maximizing the impact of a single malicious or accidental change.
No rollback mechanism. Once the fail mode is applied to OVS bridges, restoring connectivity may require direct host console access if management traffic traverses an affected bridge.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Pool-wide network blackout | All traffic on all OVS bridges dropped | No SDN controller (default) | Modeled (code-traced, OVS behavior confirmed) |
| HA cascade | Heartbeat loss triggers fencing on all hosts | HA enabled, heartbeat on OVS | Modeled |
| Management lockout | All hosts become unreachable via API | Management on OVS bridge | Modeled |
| BOC-1 chain | vm-admin escalates to pool-operator via BOC-1 S3, then triggers pool-wide DoS | BOC-1 available | Modeled (two-step chain) |
Pool.other_config for writes to vswitch-controller-fail-modevswitch-controller-fail-mode=secure when no SDN controller is configuredovs-vsctl get-fail-mode <bridge>disclosure/vendor-detection-guidance.mdPool.other_config for unexpected vswitch-controller-fail-mode valuespool-operator role to trusted administratorsRBAC restriction. Add map_keys_roles entry for vswitch-controller-fail-mode in datamodel.ml at the Pool level requiring _R_POOL_ADMIN.
Pre-condition validation. Reject secure fail mode at the pool level when no SDN controller is configured. Require explicit per-network opt-in rather than pool-wide default.
Impact safeguard. Warn or block fail-mode changes that would affect management network connectivity.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
openvswitch-config-update (fail mode default application), datamodel.ml (Pool field definition)disclosure/advisories/ploc-security-advisory.md (PLOC-6)research/investigations/pool-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.