CVE-2025-1272
Linux Kernel Lockdown Bypass in Fedora Allows Privilege Escalation
Publication date: 2026-02-18
Last updated on: 2026-02-26
Assigner: Fedora Project
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| fedora | linux | From 6.12 (inc) |
| red_hat | enterprise_linux | From 6.12 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-306 | The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-1272 is a security vulnerability in the Linux kernel versions 6.12 and above on Fedora Linux. The issue occurs because Secure Boot does not automatically enable the kernel lockdown mode, leaving it disabled without any warning.
Kernel lockdown mode is intended to restrict access to sensitive kernel features and memory, thereby enhancing system security when Secure Boot is enabled.
Due to this vulnerability, attackers may gain unauthorized access to sensitive information such as kernel memory mappings, I/O ports, Berkeley Packet Filter (BPF), and kprobes.
Additionally, the disabled lockdown mode allows loading of unsigned kernel modules, which can lead to execution of untrusted code and bypass Secure Boot protections.
This vulnerability specifically affects Fedora Linux and has been addressed in Red Hat Enterprise Linux 9 by ensuring Secure Boot properly enables kernel lockdown mode.
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': 'This vulnerability can have serious security impacts by allowing attackers to gain unauthorized access to sensitive kernel information such as memory mappings, I/O ports, BPF, and kprobes.'}, {'type': 'paragraph', 'content': 'It also permits the loading of unsigned kernel modules, which can lead to execution of untrusted and potentially malicious code.'}, {'type': 'paragraph', 'content': "By bypassing Secure Boot protections, the integrity and trustworthiness of the system's security guarantees are compromised."}, {'type': 'paragraph', 'content': 'Overall, this can lead to a complete compromise of system security, including confidentiality, integrity, and availability of the affected Fedora Linux system.'}] [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the Linux kernel lockdown mode being disabled without warning on Fedora Linux versions 6.12 and above. Detection involves verifying whether the kernel lockdown mode is enabled on your system.
You can check the current kernel lockdown status by examining the contents of the lockdown file in the kernel security directory.
- Run the command: cat /sys/kernel/security/lockdown to see the current lockdown mode status.
- Alternatively, check the kernel command line for lockdown parameters using: cat /proc/cmdline
- Verify if Secure Boot is enabled on your system, as the vulnerability affects Secure Boot enforcement.
If lockdown mode is disabled or not enforced despite Secure Boot being active, your system is vulnerable.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should apply the security updates that ensure kernel lockdown mode is properly enabled when Secure Boot is active.
Specifically, update your Fedora Linux system to a kernel version that includes the fix for CVE-2025-1272, which enforces lockdown mode automatically under Secure Boot.
If an update is not immediately available, consider manually enabling lockdown mode by adding the kernel parameter lockdown=integrity or lockdown=confidentiality at boot time.
Additionally, verify that Secure Boot is enabled and functioning correctly in your system firmware settings.
Avoid loading unsigned kernel modules until the vulnerability is patched, as this can lead to execution of untrusted code.