netavark: container name resolution falls through to host search domains and reaches external servers

Impact

netavark stopped adding the dns.podman search domain, so a container resolving its own name (or a sibling's) now walks the host's /etc/resolv.conf search list. If any configured search domain holds a matching A/AAAA record, traffic a workload intended for a peer container on the same node is answered by an external server and leaves the box. On a shared GPU node where pod and container names come from tenant-supplied job names, that is a way to steer intra-job traffic - and whatever it carries - off the node. Impact is confidentiality-only and requires the attacker to already control a record under a search domain the node trusts.

Who can reach it

No authentication to the node is needed: an attacker only needs a record published under a search domain present in the host's resolv.conf, plus knowledge or influence over a container name. Any tenant who can choose the container/pod name can help the collision along.

What to do

Update netavark to 1.15.1 or later, or apply the Red Hat errata for RHEL 8/9/10 and OpenShift Container Platform 4. Existing containers keep the network configuration they were created with, so recreate running containers after the package update; no node reboot is required.

References