Database/Kernel, userspace & hypervisor
RHEL on IBM Power: pre-production kernels boot under Secure Boot without lockdown patches
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
- VMware ESXi / Workstation / Fusion: Heap out-of-bounds write in the USB 2.0 EHCI controllerCVE-2022-31705 · VMware ESXi / Workstation / FusionHigh
- Linux kernel (eBPF verifier): Incorrect verifier pruning marks unsafe paths as safeCVE-2023-2163 · Linux kernel (eBPF verifier)High
- Linux kernel SMC-R (fallback path, DECLINE message leaking into the application stream): Silent data corruption, whichCVE-2023-52775 · Linux kernel SMC-R (fallback path, DECLINE message leaking into the application stream)High
- Linux kernel NFS client: O_DIRECT writes can be silently corrupted on retransmissionCVE-2023-53711 · Linux kernel NFS client (O_DIRECT subrequest rejoin before retransmission)High
- QEMU (virtio): DMA reentrancy leads to double free across virtio devices - guest-to-host code execution in QEMUCVE-2024-3446 · QEMU (virtio)High
- Linux kernel (net/tls): A non-DATA record already copied out of the pending list could be merged with a second recordCVE-2024-58239 · Linux kernel (net/tls)High
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.