BuildKit: build requesting a CDI device panics a daemon started with --cdi-disabled

Impact

A buildkitd started with --cdi-disabled panics when a build tries to use a CDI device. CDI is the mechanism GPUs are handed to containers, so on a GPU build host this is reachable by anything that asks for a GPU in a build - deliberately or by a stale Dockerfile. An authenticated user who can submit builds can take down the shared daemon and every concurrent build on it; the daemon has to be restarted. Impact is availability only, with no disclosure or tampering per the vendor's scoring.

Who can reach it

Any authenticated user who can submit a build to a buildkitd instance running with --cdi-disabled, requesting a CDI device.

What to do

Upgrade BuildKit to v0.33.1 and restart buildkitd. As a mitigation, stop running with --cdi-disabled (leave CDI enabled) or block CDI device requests at the build-submission layer.

References

Related entries

• runc: Volume-mount race gives incorrect access control and privilege escalation to hostCVE-2019-19921 · runcHigh
• Podman: File permissions not checked for non-root users in a privileged containerCVE-2021-20188 · PodmanHigh
• runc: Regression of CVE-2019-19921: incorrect access control leading to privilege escalation via volume mountsCVE-2023-27561 · runcHigh
• Slurm: Filesystem race conditions allow gaining ownership of, overwriting, or deleting filesCVE-2023-41914 · SlurmHigh
• Traefik: Service middleware annotation escapes crossProviderNamespaces restrictionsCVE-2026-85594 · Traefik Kubernetes Ingress provider (traefik.ingress.kubernetes.io/service.middlewares annotation)High
• Cilium: A user who can create CiliumNetworkPolicy in one namespace affects traffic cluster-wideCVE-2023-41333 · CiliumMedium