]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
lockdown: also lock down previous kgdb use
authorDaniel Thompson <daniel.thompson@linaro.org>
Mon, 23 May 2022 18:11:02 +0000 (19:11 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 30 May 2022 07:24:03 +0000 (09:24 +0200)
commiteca56bf0066ef2f1e7be0e3fa7564b85a309872c
tree502dc98bcde19abd74a050223cf75f6af92b277d
parent4b0986a3613c92f4ec1bdc7f60ec66fea135991f
lockdown: also lock down previous kgdb use

commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
include/linux/security.h
kernel/debug/debug_core.c
kernel/debug/kdb/kdb_main.c
security/security.c