Canonical has released patched FIPS packages after a customer found that Ubuntu Pro 22.04 FIPS container images could fail on the standard mainline Linux kernels used by managed Kubernetes environments, including AWS EKS and Fargate. The issue arose even when the host and container were otherwise configured for FIPS workloads.
A kernel-specific dependency
According to Canonical's account, libgcrypt20-fips depended on GRND_RESEED_ONLY, an Ubuntu-specific kernel flag used in its FIPS implementation. That flag is absent from standard mainline kernels. When the package attempted to use getrandom() with the unsupported flag, the system call returned an error and the container failed.
The failure was therefore caused by an assumption about the underlying kernel, rather than by a defective container configuration. A FIPS-compliant host and a correctly built image could still encounter the problem when deployed on a managed Kubernetes platform using a different kernel family.
The compliance constraint
Canonical said the repair needed to support standard kernels while preserving the FIPS status of the affected components. Changes to cryptographic packages can require revalidation through the National Institute of Standards and Technology's Cryptographic Module Validation Program, potentially creating a separate compliance obstacle for regulated deployments.
The resulting patch changes the behavior of libgcrypt20-fips, gnutls28 and ubuntu-fips when GRND_RESEED_ONLY is unavailable, allowing them to fall back without compromising the cryptographic guarantees described by Canonical.
Packages now available
Canonical first supplied the patched packages through a private PPA for the customer's validation. The customer tested the containers in its target environments and confirmed that the fix worked, according to the company.
Canonical then released the updates to the jammy-fips-updates and noble-fips-updates repositories. The affected deployment pattern includes Ubuntu Pro 22.04 and 24.04 FIPS container images running on standard cloud kernels. The incident shows that FIPS deployment compatibility depends on the interaction between certified packages and the host kernel, not solely on the certification of the image.
AI-generated editorial illustration; not a documentary photograph.
Source: How a missing kernel flag broke FIPS-certified containers in managed Kubernetes
SIGNAL TITANS
Leave a Reply