GPU VulnDB

Database/Kernel, userspace & hypervisor

RHEL on IBM Power: pre-production kernels boot under Secure Boot without lockdown patches

CVSS 8.2CVE-2022-1665Kernel, userspace & hypervisorcurated

Impact

A set of pre-production RHEL kernel packages for the IBM Power architecture carry signatures that grub accepts in Secure Boot mode, but they were built without the Secure Boot lockdown patches. Booting one of them yields a Secure Boot chain that reports as trusted while the kernel still permits the operations lockdown exists to block - unsigned module loading and kernel memory access - so an attacker with high privileges can load untrusted code and keep it across reboots. On a GPU node that matters because the boot-integrity attestation an operator relies on (and anything keyed to it, such as measured-boot policy or disk unlock) no longer reflects the kernel's actual state, and persistence under the hypervisor is invisible to tenant-level controls. Exposure is limited to Power hosts that have one of those pre-production builds available to grub; the record does not enumerate the affected package versions.

Who can reach it

Local, high-privilege access on an IBM Power RHEL host - enough to install a kernel package and influence the grub boot entry. No remote path, and no tenant inside a VM or container can reach it.

What to do

Make sure no pre-production kernel package is installed or reachable from a boot entry on Power hosts: remove them, install only released kernels, and update grub and the shim revocation list from Red Hat so the affected builds are no longer accepted. Taking effect requires booting the host into a known-good kernel, so each affected node has to be drained and rebooted. Red Hat's bugzilla entry is the only reference in this record and does not name fixed package versions - confirm against it before scheduling the window.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.