Re: [PATCH v5.4] lockdown: also lock down previous kgdb use

[Greg KH <greg@kroah.com>]

On Wed, May 25, 2022 at 02:31:07PM +0100, Daniel Thompson wrote:
> 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>
> ---
> 
> Notes:
>     Original patch did not backport cleanly. This backport is fixed up,
>     compile tested (on arm64) and side-by-side compared against the
>     original.
> 

Now queued up, thanks.

greg k-h