[ciqlts8_6] lockdown: also lock down previous kgdb use by ciq-kernel-automation[bot] · Pull Request #895 · ctrliq/kernel-src-tree

ciq-kernel-automation · 2026-02-18T19:17:18Z

Summary

This PR has been automatically created after successful completion of all CI stages.

Rocky8_10 reference

It was attempted to be back ported in this commit sha on rocky8 rebuilds however it did not cleanly apply 61b2455
The SPLAT commit that it was associated to is this one:
8fe840b

Red Hat did not backport the full LSM 5.4 patches but instead adapted their previous method (before the LSM unification) to kernel_is_locked_down(). A note, redhat did not, like the source commit drop the read access during the KDB console connect. They did prevent the write so they're maintaining the integrity of the kernel where as since we're dropping the read and write we're also making it a confidentiality mode". Other wise we chose to use their "Panic Messaging" as well.

Commit Message(s)

lockdown: also lock down previous kgdb use

jira VULN-3157
cve CVE-2022-21499
commit-author Daniel Thompson <daniel.thompson@linaro.org>
commit eadb2f47a3ced5c64b23b90fd2a3463f63726066
upstream-diff: Adapted to use older kernel_is_locked_down() APIs as the
	Lockdown LSM changes introduced in 5.4 where not backported to
	this kernel.

Test Results

✅ Build Stage

Architecture	Build Time	Total Time
x86_64	23m 20s	25m 27s
aarch64	12m 49s	14m 7s

View build logs

✅ Boot Verification

Status: Passed (all architectures)
View boot logs

✅ Kernel Selftests

Architecture	Passed	Failed
x86_64	111	29
aarch64	40	13

View kselftest logs

Test Comparison

x86_64:

✅ Status: Passed - Within acceptable threshold (±3 tests)
Compared against: ciqlts8_6

aarch64:

✅ Status: Passed - Within acceptable threshold (±3 tests)
Compared against: ciqlts8_6

🤖 This PR was automatically generated by GitHub Actions
Run ID: 22232723880

github-actions · 2026-02-18T19:26:58Z

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/22154387405

github-actions · 2026-02-18T19:26:59Z

🔍 Upstream Linux Kernel Commit Check

❌ PR commit f06708d8617b (lockdown: also lock down previous kgdb use) references CVE-2022-21499 but
upstream commit eadb2f47a3ce has no CVE assigned

This is an automated message from the kernel commit checker workflow.

github-actions · 2026-02-18T19:27:00Z

🔍 Interdiff Analysis

⚠️ PR commit f06708d8617b (lockdown: also lock down previous kgdb use) → upstream eadb2f47a3ce
Differences found:

================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -641,7 +641,7 @@
 			 * themselves, especially with help from the lockdown
 			 * message printed on the console!
 			 */
-			if (kernel_is_locked_down("Use of kgdb/kdb to write kernel RAM")) {
+			if (security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL)) {
 				if (IS_ENABLED(CONFIG_KGDB_KDB)) {
 					/* Switch back to kdb if possible... */
 					dbg_kdb_mode = 1;
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -171,19 +171,22 @@
  * Update the permissions flags (kdb_cmd_enabled) to match the
  * current lockdown state.
  *
- * When the kernel is locked down, strip all memory/register read and
- * write permissions as well as flow control from kdb_cmd_enabled.
+ * Within this function the calls to security_locked_down() are "lazy". We
+ * avoid calling them if the current value of kdb_cmd_enabled already excludes
+ * flags that might be subject to lockdown. Additionally we deliberately check
+ * the lockdown flags independently (even though read lockdown implies write
+ * lockdown) since that results in both simpler code and clearer messages to
+ * the user on first-time debugger entry.
  *
- * The remaining permitted flags are: INSPECT, SIGNAL, REBOOT
- * (and ALWAYS_SAFE).
+ * The permission masks during a read+write lockdown permits the following
+ * flags: INSPECT, SIGNAL, REBOOT (and ALWAYS_SAFE).
  *
- * INSPECT commands are not blocked during lockdown because they are
- * not arbitrary memory reads. INSPECT covers the backtrace family
- * (sometimes forcing them to have no arguments) and lsmod. These
- * commands do expose some kernel state but do not allow the developer
- * seated at the console to choose what state is reported. SIGNAL and
- * REBOOT should not be controversial, given these are allowed for
- * root during lockdown already.
+ * The INSPECT commands are not blocked during lockdown because they are
+ * not arbitrary memory reads. INSPECT covers the backtrace family (sometimes
+ * forcing them to have no arguments) and lsmod. These commands do expose
+ * some kernel state but do not allow the developer seated at the console to
+ * choose what state is reported. SIGNAL and REBOOT should not be controversial,
+ * given these are allowed for root during lockdown already.
  */
 static void kdb_check_for_lockdown(void)
 {
@@ -193,14 +196,27 @@
 	const int read_flags = KDB_ENABLE_MEM_READ |
 			       KDB_ENABLE_REG_READ;
 
-	if (!kernel_is_locked_down("kdb"))
-		return;
+	bool need_to_lockdown_write = false;
+	bool need_to_lockdown_read = false;
+
+	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | write_flags))
+		need_to_lockdown_write =
+			security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL);
+
+	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | read_flags))
+		need_to_lockdown_read =
+			security_locked_down(LOCKDOWN_DBG_READ_KERNEL);
 
 	/* De-compose KDB_ENABLE_ALL if required */
-	if (kdb_cmd_enabled & KDB_ENABLE_ALL)
-		kdb_cmd_enabled = KDB_ENABLE_MASK & ~KDB_ENABLE_ALL;
+	if (need_to_lockdown_write || need_to_lockdown_read)
+		if (kdb_cmd_enabled & KDB_ENABLE_ALL)
+			kdb_cmd_enabled = KDB_ENABLE_MASK & ~KDB_ENABLE_ALL;
+
+	if (need_to_lockdown_write)
+		kdb_cmd_enabled &= ~write_flags;
 
-	kdb_cmd_enabled &= ~(write_flags | read_flags);
+	if (need_to_lockdown_read)
+		kdb_cmd_enabled &= ~read_flags;
 }
 
 /*

################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -53,6 +53,7 @@
 #include <linux/vmacache.h>
 #include <linux/rcupdate.h>
 #include <linux/irq.h>
+#include <linux/security.h>
 
 #include <asm/cacheflush.h>
 #include <asm/byteorder.h>
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -45,6 +45,7 @@
 #include <linux/proc_fs.h>
 #include <linux/uaccess.h>
 #include <linux/slab.h>
+#include <linux/security.h>
 #include "kdb_private.h"
 
 #undef	MODULE_PARAM_PREFIX

================================================================================
*    ONLY IN PATCH2 - files not modified by patch1                             *
================================================================================

--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -121,10 +121,12 @@ enum lockdown_reason {
 	LOCKDOWN_DEBUGFS,
 	LOCKDOWN_XMON_WR,
 	LOCKDOWN_BPF_WRITE_USER,
+	LOCKDOWN_DBG_WRITE_KERNEL,
 	LOCKDOWN_INTEGRITY_MAX,
 	LOCKDOWN_KCORE,
 	LOCKDOWN_KPROBES,
 	LOCKDOWN_BPF_READ_KERNEL,
+	LOCKDOWN_DBG_READ_KERNEL,
 	LOCKDOWN_PERF,
 	LOCKDOWN_TRACEFS,
 	LOCKDOWN_XMON_RW,
--- a/security/security.c
+++ b/security/security.c
@@ -59,10 +59,12 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 	[LOCKDOWN_DEBUGFS] = "debugfs access",
 	[LOCKDOWN_XMON_WR] = "xmon write access",
 	[LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
+	[LOCKDOWN_DBG_WRITE_KERNEL] = "use of kgdb/kdb to write kernel RAM",
 	[LOCKDOWN_INTEGRITY_MAX] = "integrity",
 	[LOCKDOWN_KCORE] = "/proc/kcore access",
 	[LOCKDOWN_KPROBES] = "use of kprobes",
 	[LOCKDOWN_BPF_READ_KERNEL] = "use of bpf to read kernel RAM",
+	[LOCKDOWN_DBG_READ_KERNEL] = "use of kgdb/kdb to read kernel RAM",
 	[LOCKDOWN_PERF] = "unsafe use of perf",
 	[LOCKDOWN_TRACEFS] = "use of tracefs",
 	[LOCKDOWN_XMON_RW] = "xmon read and write access",

This is an automated interdiff check for backported commits.

github-actions · 2026-02-18T19:28:04Z

✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/22154387405

github-actions · 2026-02-18T20:37:53Z

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/22156694181

github-actions · 2026-02-18T20:37:54Z

🔍 Upstream Linux Kernel Commit Check

❌ PR commit fdd34a219129 (lockdown: also lock down previous kgdb use) references CVE-2022-21499 but
upstream commit eadb2f47a3ce has no CVE assigned

This is an automated message from the kernel commit checker workflow.

github-actions · 2026-02-18T20:37:55Z

🔍 Interdiff Analysis

⚠️ PR commit fdd34a219129 (lockdown: also lock down previous kgdb use) → upstream eadb2f47a3ce
Differences found:

================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -641,7 +641,7 @@
 			 * themselves, especially with help from the lockdown
 			 * message printed on the console!
 			 */
-			if (kernel_is_locked_down("Use of kgdb/kdb to write kernel RAM")) {
+			if (security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL)) {
 				if (IS_ENABLED(CONFIG_KGDB_KDB)) {
 					/* Switch back to kdb if possible... */
 					dbg_kdb_mode = 1;
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -171,19 +171,22 @@
  * Update the permissions flags (kdb_cmd_enabled) to match the
  * current lockdown state.
  *
- * When the kernel is locked down, strip all memory/register read and
- * write permissions as well as flow control from kdb_cmd_enabled.
+ * Within this function the calls to security_locked_down() are "lazy". We
+ * avoid calling them if the current value of kdb_cmd_enabled already excludes
+ * flags that might be subject to lockdown. Additionally we deliberately check
+ * the lockdown flags independently (even though read lockdown implies write
+ * lockdown) since that results in both simpler code and clearer messages to
+ * the user on first-time debugger entry.
  *
- * The remaining permitted flags are: INSPECT, SIGNAL, REBOOT
- * (and ALWAYS_SAFE).
+ * The permission masks during a read+write lockdown permits the following
+ * flags: INSPECT, SIGNAL, REBOOT (and ALWAYS_SAFE).
  *
- * INSPECT commands are not blocked during lockdown because they are
- * not arbitrary memory reads. INSPECT covers the backtrace family
- * (sometimes forcing them to have no arguments) and lsmod. These
- * commands do expose some kernel state but do not allow the developer
- * seated at the console to choose what state is reported. SIGNAL and
- * REBOOT should not be controversial, given these are allowed for
- * root during lockdown already.
+ * The INSPECT commands are not blocked during lockdown because they are
+ * not arbitrary memory reads. INSPECT covers the backtrace family (sometimes
+ * forcing them to have no arguments) and lsmod. These commands do expose
+ * some kernel state but do not allow the developer seated at the console to
+ * choose what state is reported. SIGNAL and REBOOT should not be controversial,
+ * given these are allowed for root during lockdown already.
  */
 static void kdb_check_for_lockdown(void)
 {
@@ -193,14 +196,27 @@
 	const int read_flags = KDB_ENABLE_MEM_READ |
 			       KDB_ENABLE_REG_READ;
 
-	if (!kernel_is_locked_down("Use of kgdb/kdb to read/write kernel RAM"))
-		return;
+	bool need_to_lockdown_write = false;
+	bool need_to_lockdown_read = false;
+
+	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | write_flags))
+		need_to_lockdown_write =
+			security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL);
+
+	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | read_flags))
+		need_to_lockdown_read =
+			security_locked_down(LOCKDOWN_DBG_READ_KERNEL);
 
 	/* De-compose KDB_ENABLE_ALL if required */
-	if (kdb_cmd_enabled & KDB_ENABLE_ALL)
-		kdb_cmd_enabled = KDB_ENABLE_MASK & ~KDB_ENABLE_ALL;
+	if (need_to_lockdown_write || need_to_lockdown_read)
+		if (kdb_cmd_enabled & KDB_ENABLE_ALL)
+			kdb_cmd_enabled = KDB_ENABLE_MASK & ~KDB_ENABLE_ALL;
+
+	if (need_to_lockdown_write)
+		kdb_cmd_enabled &= ~write_flags;
 
-	kdb_cmd_enabled &= ~(write_flags | read_flags);
+	if (need_to_lockdown_read)
+		kdb_cmd_enabled &= ~read_flags;
 }
 
 /*

################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -53,6 +53,7 @@
 #include <linux/vmacache.h>
 #include <linux/rcupdate.h>
 #include <linux/irq.h>
+#include <linux/security.h>
 
 #include <asm/cacheflush.h>
 #include <asm/byteorder.h>
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -45,6 +45,7 @@
 #include <linux/proc_fs.h>
 #include <linux/uaccess.h>
 #include <linux/slab.h>
+#include <linux/security.h>
 #include "kdb_private.h"
 
 #undef	MODULE_PARAM_PREFIX

================================================================================
*    ONLY IN PATCH2 - files not modified by patch1                             *
================================================================================

--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -121,10 +121,12 @@ enum lockdown_reason {
 	LOCKDOWN_DEBUGFS,
 	LOCKDOWN_XMON_WR,
 	LOCKDOWN_BPF_WRITE_USER,
+	LOCKDOWN_DBG_WRITE_KERNEL,
 	LOCKDOWN_INTEGRITY_MAX,
 	LOCKDOWN_KCORE,
 	LOCKDOWN_KPROBES,
 	LOCKDOWN_BPF_READ_KERNEL,
+	LOCKDOWN_DBG_READ_KERNEL,
 	LOCKDOWN_PERF,
 	LOCKDOWN_TRACEFS,
 	LOCKDOWN_XMON_RW,
--- a/security/security.c
+++ b/security/security.c
@@ -59,10 +59,12 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 	[LOCKDOWN_DEBUGFS] = "debugfs access",
 	[LOCKDOWN_XMON_WR] = "xmon write access",
 	[LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
+	[LOCKDOWN_DBG_WRITE_KERNEL] = "use of kgdb/kdb to write kernel RAM",
 	[LOCKDOWN_INTEGRITY_MAX] = "integrity",
 	[LOCKDOWN_KCORE] = "/proc/kcore access",
 	[LOCKDOWN_KPROBES] = "use of kprobes",
 	[LOCKDOWN_BPF_READ_KERNEL] = "use of bpf to read kernel RAM",
+	[LOCKDOWN_DBG_READ_KERNEL] = "use of kgdb/kdb to read kernel RAM",
 	[LOCKDOWN_PERF] = "unsafe use of perf",
 	[LOCKDOWN_TRACEFS] = "use of tracefs",
 	[LOCKDOWN_XMON_RW] = "xmon read and write access",

This is an automated interdiff check for backported commits.

github-actions · 2026-02-18T20:38:53Z

✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/22156694181

bmastbergen · 2026-02-18T22:04:55Z

Looks right to me. Its interesting that only the writes are taken care of in rocky8_10:

 % git show 8fe840b35a7226b11ee39118c54fbecdd8b8ab29 -- kernel/debug
commit 8fe840b35a7226b11ee39118c54fbecdd8b8ab29 (tag: centos_kernel-4.18.0-448.el8)
Author: Jonathan Maple <jmaple@ciq.com>
Date:   Wed Sep 11 20:13:07 2024 -0400

    Rebuild centos8 with kernel-4.18.0-448.el8

    Rebuild_History BUILDABLERebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
    Number of commits in upstream range v4.18~1..master: 488125
    Number of commits in rpm: 8089
    Number of commits matched with upstream: 7970 (98.53%)
    Number of commits in upstream but not in rpm: 480207
    Number of commits NOT found in upstream: 119 (1.47%)

    Rebuilding Kernel on Branch centos8_rebuild_kernel-4.18.0-448.el8 for kernel-4.18.0-448.el8
    Clean Cherry Picks: 5882 (73.80%)
    Empty Cherry Picks: 1989 (24.96%)
    _______________________________

    Full Details Located here:
    ciq/ciq_backports/kernel-4.18.0-448.el8/rebuild.details.txt

    Includes:
    * git commit header above
    * Empty Commits with upstream SHA
    * RPM ChangeLog Entries that could not be matched

    Individual Empty Commit failures contained in the same containing directory.
    The git message for empty commits will have the path for the failed commit.
    File names are the first 8 characters of the upstream SHA

diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 7064a1b55bf87..c40edc4ae49ee 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -628,6 +628,29 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct pt_regs *regs,
                                continue;
                        kgdb_connected = 0;
                } else {
+                       /*
+                        * This is a brutal way to interfere with the debugger
+                        * and prevent gdb being used to poke at kernel memory.
+                        * This could cause trouble if lockdown is applied when
+                        * there is already an active gdb session. For now the
+                        * answer is simply "don't do that". Typically lockdown
+                        * *will* be applied before the debug core gets started
+                        * so only developers using kgdb for fairly advanced
+                        * early kernel debug can be biten by this. Hopefully
+                        * they are sophisticated enough to take care of
+                        * themselves, especially with help from the lockdown
+                        * message printed on the console!
+                        */
+                       if (kernel_is_locked_down("Use of kgdb/kdb to write kernel RAM")) {
+                               if (IS_ENABLED(CONFIG_KGDB_KDB)) {
+                                       /* Switch back to kdb if possible... */
+                                       dbg_kdb_mode = 1;
+                                       continue;
+                               } else {
+                                       /* ... otherwise just bail */
+                                       break;
+                               }
+                       }
                        error = gdb_serial_stub(ks);
                }

diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index d5c7f02f6fbaa..4ce43c82d35d9 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -168,10 +168,39 @@ struct task_struct *kdb_curr_task(int cpu)
 }

 /*
- * Check whether the flags of the current command and the permissions
- * of the kdb console has allow a command to be run.
+ * Update the permissions flags (kdb_cmd_enabled) to match the
+ * current lockdown state.
+ *
+ * Within this function the call to kernel_is_locked_down() is "lazy". We
+ * avoid calling it if the current value of kdb_cmd_enabled already excludes
+ * flags that might be subject to lockdown.
+ */
+static void kdb_check_for_lockdown(void)
+{
+       const int write_flags = KDB_ENABLE_MEM_WRITE |
+                               KDB_ENABLE_REG_WRITE |
+                               KDB_ENABLE_FLOW_CTRL;
+
+       bool need_to_lockdown_write = false;
+
+       if (kdb_cmd_enabled & (KDB_ENABLE_ALL | write_flags))
+               need_to_lockdown_write =
+                       kernel_is_locked_down("Use of kgdb/kdb to write kernel RAM");
+
+       /* De-compose KDB_ENABLE_ALL if required */
+       if (need_to_lockdown_write)
+               if (kdb_cmd_enabled & KDB_ENABLE_ALL)
+                       kdb_cmd_enabled = KDB_ENABLE_MASK & ~KDB_ENABLE_ALL;
+
+       if (need_to_lockdown_write)
+               kdb_cmd_enabled &= ~write_flags;
+}
+
+/*
+ * Check whether the flags of the current command, the permissions of the kdb
+ * console and the lockdown state allow a command to be run.
  */
-static inline bool kdb_check_flags(kdb_cmdflags_t flags, int permissions,
+static bool kdb_check_flags(kdb_cmdflags_t flags, int permissions,
                                   bool no_args)
 {
        /* permissions comes from userspace so needs massaging slightly */
@@ -1169,6 +1198,9 @@ static int kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
                kdb_curr_task(raw_smp_processor_id());

        KDB_DEBUG_STATE("kdb_local 1", reason);
+
+       kdb_check_for_lockdown();
+
        kdb_go_count = 0;
        if (reason == KDB_REASON_DEBUG) {
                /* special case below */

PlaidCat · 2026-02-18T22:27:21Z

Looks right to me. Its interesting that only the writes are taken care of in rocky8_10:

Yeah, being able to read seems like a security risk ... but I guess if you're in the kgdb you're already able to get most information :|

I"m also happy to adapt this to the RHEL logic more closely (that may very well be whats in the EUS kernel but 🤷 since we don't have visibility into it) but we're already divergent from the RESF 1:1 bug compatibility anyways.

bmastbergen

🥌

kernel/debug/kdb/kdb_main.c

kernel/debug/debug_core.c

jira VULN-3157 cve CVE-2022-21499 commit-author Daniel Thompson <daniel.thompson@linaro.org> commit eadb2f4 upstream-diff: Adapted to use older kernel_is_locked_down() APIs as the Lockdown LSM changes introduced in 5.4 where not backported to this kernel. KGDB and KDB allow read and write access to kernel memory, and thus should be restricted during lockdown. An attacker with access to a serial port (for example, via a hypervisor console, which some cloud vendors provide over the network) could trigger the debugger so it is important that the debugger respect the lockdown mode when/if it is triggered. Fix this by integrating lockdown into kdb's existing permissions mechanism. Unfortunately kgdb does not have any permissions mechanism (although it certainly could be added later) so, for now, kgdb is simply and brutally disabled by immediately exiting the gdb stub without taking any action. For lockdowns established early in the boot (e.g. the normal case) then this should be fine but on systems where kgdb has set breakpoints before the lockdown is enacted than "bad things" will happen. CVE: CVE-2022-21499 Co-developed-by: Stephen Brennan <stephen.s.brennan@oracle.com> Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit eadb2f4) Signed-off-by: Jonathan Maple <jmaple@ciq.com>

github-actions · 2026-02-20T16:54:50Z

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/22233029005

github-actions · 2026-02-20T16:54:51Z

🔍 Upstream Linux Kernel Commit Check

❌ PR commit 42ae7e56b6a8 (lockdown: also lock down previous kgdb use) references CVE-2022-21499 but
upstream commit eadb2f47a3ce has no CVE assigned

This is an automated message from the kernel commit checker workflow.

github-actions · 2026-02-20T16:54:52Z

🔍 Interdiff Analysis

⚠️ PR commit 42ae7e56b6a8 (lockdown: also lock down previous kgdb use) → upstream eadb2f47a3ce
Differences found:

================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -641,7 +641,7 @@
 			 * themselves, especially with help from the lockdown
 			 * message printed on the console!
 			 */
-			if (kernel_is_locked_down("use of kgdb/kdb to write kernel RAM")) {
+			if (security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL)) {
 				if (IS_ENABLED(CONFIG_KGDB_KDB)) {
 					/* Switch back to kdb if possible... */
 					dbg_kdb_mode = 1;
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -201,11 +201,11 @@
 
 	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | write_flags))
 		need_to_lockdown_write =
-			kernel_is_locked_down("use of kgdb/kdb to write kernel RAM");
+			security_locked_down(LOCKDOWN_DBG_WRITE_KERNEL);
 
 	if (kdb_cmd_enabled & (KDB_ENABLE_ALL | read_flags))
 		need_to_lockdown_read =
-			kernel_is_locked_down("use of kgdb/kdb to read kernel RAM");
+			security_locked_down(LOCKDOWN_DBG_READ_KERNEL);
 
 	/* De-compose KDB_ENABLE_ALL if required */
 	if (need_to_lockdown_write || need_to_lockdown_read)

################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -53,6 +53,7 @@
 #include <linux/vmacache.h>
 #include <linux/rcupdate.h>
 #include <linux/irq.h>
+#include <linux/security.h>
 
 #include <asm/cacheflush.h>
 #include <asm/byteorder.h>
--- b/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -45,6 +45,7 @@
 #include <linux/proc_fs.h>
 #include <linux/uaccess.h>
 #include <linux/slab.h>
+#include <linux/security.h>
 #include "kdb_private.h"
 
 #undef	MODULE_PARAM_PREFIX

================================================================================
*    ONLY IN PATCH2 - files not modified by patch1                             *
================================================================================

--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -121,10 +121,12 @@ enum lockdown_reason {
 	LOCKDOWN_DEBUGFS,
 	LOCKDOWN_XMON_WR,
 	LOCKDOWN_BPF_WRITE_USER,
+	LOCKDOWN_DBG_WRITE_KERNEL,
 	LOCKDOWN_INTEGRITY_MAX,
 	LOCKDOWN_KCORE,
 	LOCKDOWN_KPROBES,
 	LOCKDOWN_BPF_READ_KERNEL,
+	LOCKDOWN_DBG_READ_KERNEL,
 	LOCKDOWN_PERF,
 	LOCKDOWN_TRACEFS,
 	LOCKDOWN_XMON_RW,
--- a/security/security.c
+++ b/security/security.c
@@ -59,10 +59,12 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 	[LOCKDOWN_DEBUGFS] = "debugfs access",
 	[LOCKDOWN_XMON_WR] = "xmon write access",
 	[LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
+	[LOCKDOWN_DBG_WRITE_KERNEL] = "use of kgdb/kdb to write kernel RAM",
 	[LOCKDOWN_INTEGRITY_MAX] = "integrity",
 	[LOCKDOWN_KCORE] = "/proc/kcore access",
 	[LOCKDOWN_KPROBES] = "use of kprobes",
 	[LOCKDOWN_BPF_READ_KERNEL] = "use of bpf to read kernel RAM",
+	[LOCKDOWN_DBG_READ_KERNEL] = "use of kgdb/kdb to read kernel RAM",
 	[LOCKDOWN_PERF] = "unsafe use of perf",
 	[LOCKDOWN_TRACEFS] = "use of tracefs",
 	[LOCKDOWN_XMON_RW] = "xmon read and write access",

This is an automated interdiff check for backported commits.

github-actions · 2026-02-20T16:55:49Z

✅ Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/22233029005

kerneltoast

🚢

bmastbergen

🥌

PlaidCat self-assigned this Feb 18, 2026

PlaidCat requested review from a team and jason-rodri February 18, 2026 20:12

PlaidCat force-pushed the {jmaple}_ciqlts8_6 branch from f06708d to fdd34a2 Compare February 18, 2026 20:27

bmastbergen previously approved these changes Feb 19, 2026

View reviewed changes

PlaidCat requested a review from a team February 19, 2026 19:14

jason-rodri previously approved these changes Feb 19, 2026

View reviewed changes

kerneltoast requested changes Feb 20, 2026

View reviewed changes

kernel/debug/kdb/kdb_main.c Outdated Show resolved Hide resolved

kernel/debug/kdb/kdb_main.c Outdated Show resolved Hide resolved

kernel/debug/debug_core.c Outdated Show resolved Hide resolved

PlaidCat dismissed stale reviews from jason-rodri and bmastbergen via 42ae7e5 February 20, 2026 16:45

PlaidCat force-pushed the {jmaple}_ciqlts8_6 branch from fdd34a2 to 42ae7e5 Compare February 20, 2026 16:45

PlaidCat requested a review from kerneltoast February 20, 2026 16:46

kerneltoast approved these changes Feb 20, 2026

View reviewed changes

jason-rodri approved these changes Feb 20, 2026

View reviewed changes

bmastbergen approved these changes Feb 20, 2026

View reviewed changes

PlaidCat merged commit 8c96c51 into ciqlts8_6 Feb 20, 2026
13 checks passed

PlaidCat deleted the {jmaple}_ciqlts8_6 branch February 20, 2026 19:43

Comments

Conversation

ciq-kernel-automation bot commented Feb 18, 2026 • edited by PlaidCat Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Rocky8_10 reference

Commit Message(s)

Test Results

✅ Build Stage

✅ Boot Verification

✅ Kernel Selftests

Test Comparison

Uh oh!

github-actions bot commented Feb 18, 2026

Uh oh!

github-actions bot commented Feb 18, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions bot commented Feb 18, 2026

🔍 Interdiff Analysis

Uh oh!

github-actions bot commented Feb 18, 2026

Uh oh!

github-actions bot commented Feb 18, 2026

Uh oh!

github-actions bot commented Feb 18, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions bot commented Feb 18, 2026

🔍 Interdiff Analysis

Uh oh!

github-actions bot commented Feb 18, 2026

Uh oh!

bmastbergen commented Feb 18, 2026

Uh oh!

PlaidCat commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Feb 20, 2026

Uh oh!

github-actions bot commented Feb 20, 2026

🔍 Upstream Linux Kernel Commit Check

Uh oh!

github-actions bot commented Feb 20, 2026

🔍 Interdiff Analysis

Uh oh!

github-actions bot commented Feb 20, 2026

Uh oh!

kerneltoast left a comment

Choose a reason for hiding this comment

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

ciq-kernel-automation bot commented Feb 18, 2026 •

edited by PlaidCat

Loading

PlaidCat commented Feb 18, 2026 •

edited

Loading