A missing kernel flag broke Ubuntu's FIPS containers
A deliberately added Ubuntu kernel flag was never present on the mainline kernels behind managed Kubernetes, so Canonical had to fix the cryptographic packages without invalidating their FIPS certification.
Canonical has published a post-mortem on a bug that quietly broke Ubuntu Pro FIPS containers in managed Kubernetes, and the cause is a single kernel flag that only exists on Ubuntu's own FIPS kernels. In a support case study dated 28 September, the company describes how a customer building a FedRAMP-compliant deployment found their Ubuntu Pro 22.04 FIPS container images failing on standard, mainline Linux kernels, the kind running underneath managed Kubernetes services such as Amazon EKS and Fargate.
The dependency sat in libgcrypt20-fips, which called getrandom() with GRND_RESEED_ONLY, an Ubuntu-specific flag introduced as part of Canonical's own FIPS implementation. Mainline Linux kernels do not have it. Where the syscall appeared, it returned an error and the container failed. Canonical is blunt that this was not a configuration mistake: a fully FIPS-compliant host, a correctly built container and an image identical to one that worked on a Jammy FIPS kernel would all still fail, because the package was asking for something the kernel underneath did not support.
Two constraints, one patch
The customer did most of the diagnostic work themselves, working from public bug reports and their own testing until they could hand Canonical specific package names, specific error conditions and specific references. Canonical Support then escalated the case to its FIPS team, where a support engineer called Matthew led the investigation.
Any fix had to satisfy two things at once. It had to make libgcrypt20-fips, gnutls28 and ubuntu-fips behave correctly on standard kernels without GRND_RESEED_ONLY. It also had to preserve FIPS compliance, because touching cryptographic packages can invalidate certification and drag a customer into months of revalidation through NIST's Cryptographic Module Validation Program. A patch that broke certification would simply have swapped one blocker for another for anyone with an active compliance obligation.
Matthew's patch changes how the packages behave when the flag is unavailable, letting them fall back correctly without weakening the cryptographic guarantees that FIPS rests on. Canonical handed the rebuilt packages to the customer through a private PPA so they could validate them against their own target environments, and only once that was confirmed did the packages land in the jammy-fips-updates and noble-fips-updates repositories.
What to check on your own clusters
If you run Ubuntu Pro 22.04 or 24.04 FIPS container images on standard cloud kernels, the actionable part is short: make sure those systems pull from jammy-fips-updates or noble-fips-updates. The case study is also a decent template for diagnosing compliance failures in cloud-native environments, because no single layer told the full story. The container looked right, the host was certified, and the failure lived in the seam between a package assumption and a kernel that did not share it.
That seam is worth remembering the next time a certified image behaves differently in a managed service than it does on a self-managed host. FIPS compliance is a property of the whole stack, and managed platforms swap out the bottom layer without asking anyone.
Our opinion
The interesting part of this story is the shape of the bug rather than its severity. A deliberately added kernel flag was correct on the platform Canonical controls and invisible on the platforms most customers actually run, and nothing in the container, the host or the certificate could tell you that. Compliance regimes are good at asking whether a component is certified, and much worse at asking whether the certified component and its runtime were ever properly introduced to each other.
Canonical's response is also a quietly good argument for paying for support on open source. The customer found the problem, but the fix needed the people who wrote the FIPS implementation and could change a cryptographic package without losing the certificate. That is not a bug anyone patches from the outside, and it is exactly the kind of work that does not survive a vendor relationship measured purely on licence cost.