Ah, yes, but all software is 10 years old and full of exploitable security holes and weak algorithms if you're constrained to FIPS, so the kernel isn't a special case :)
Only if your organization submits to the stupidity of the FIPS 140-2 consultant scam. Google has this level of certification and they obviously aren't using vendor kernels (or vendor anything). At Google the production kernel was, in many ways, newer than the one you could download from kernel.org
you state that "Google has this level of certification" as if it is a certification which applies to organizations. It does not. Specific hardware and software cryptographic modules are given FIPS 140-2 certification. Google currently has 8 cryptographic modules which have active FIPS 140-2 certifications. 5 hardware and 3 software. The software modules are all versions of BoringSSL. Google can replace their kernel as they wish because they don't use the cryptographic api's in the kernel for anything which requires the use of a FIPS140-2 cryptographic module. Not everyone is in that position or they use a commercial Linux OS in which the non-kernel certified cryptographic module provided is available on only certain releases. If they want support for their OS they must therefore use the kernel provided with that release of the OS.
Thanks for expanding on my simplistic remark. Have you considered offering your services as a FIPS consultant? Because my ex-Google experience with this aspect of the industry is that management hires a consulting firm who come in and says things like everyone must use this RHEL kernel, this (incredibly broken) openssl and so forth. Those consultants are not offering the nuanced perspective to the management, who aren't technical enough to understand it anyway. So the word comes down from the top that we're married to kernel 4.15 until the end of days.
