FAILED: patch "[PATCH] lockdown: also lock down previous kgdb use" failed to apply to 5.10-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From eadb2f47a3ced5c64b23b90fd2a3463f63726066 Mon Sep 17 00:00:00 2001
From: Daniel Thompson <[email protected]>
Date: Mon, 23 May 2022 19:11:02 +0100
Subject: [PATCH] lockdown: also lock down previous kgdb use
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
include/linux/security.h +2 -0
@@ -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,
kernel/debug/debug_core.c +24 -0
@@ -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>
@@ -752,6 +753,29 @@ cpu_master_loop: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 (security_locked_down (LOCKDOWN_DBG_WRITE_KERNEL )) { +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); }
kernel/debug/kdb/kdb_main.c +59 -3
81 lines not on this page · raw message
security/security.c +2 -0
@@ -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",