linux-kernel - Re: [PATCH v2 7/7] kdb: Simplify management of tmpbuffer in kdb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 22 Apr 2024 16:52:52 -0700
From: Doug Anderson <dianders@...omium.org>
To: Daniel Thompson <daniel.thompson@...aro.org>
Cc: Jason Wessel <jason.wessel@...driver.com>, kgdb-bugreport@...ts.sourceforge.net, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 7/7] kdb: Simplify management of tmpbuffer in kdb_read()

Hi,

On Mon, Apr 22, 2024 at 9:38 AM Daniel Thompson
<daniel.thompson@...aro.org> wrote:
>
> The current approach to filling tmpbuffer with completion candidates is
> confusing, with the buffer management being especially hard to reason
> about. That's because it doesn't copy the completion canidate into
> tmpbuffer, instead of copies a whole bunch of other nonsense and then
> runs the completion stearch from the middle of tmpbuffer!
>
> Change this to copy nothing but the completion candidate into tmpbuffer.
>
> Pretty much everything else in this patch is renaming to reflect the
> above change:
>
>     s/p_tmp/tmpbuffer/
>     s/buf_size/sizeof(tmpbuffer)/
>
> Signed-off-by: Daniel Thompson <daniel.thompson@...aro.org>
> ---
>  kernel/debug/kdb/kdb_io.c | 40 +++++++++++++++++-----------------------
>  1 file changed, 17 insertions(+), 23 deletions(-)

Definitely an improvement.

Reviewed-by: Douglas Anderson <dianders@...omium.org>


> diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
> index 94a638a9d52fa..640208675c9a8 100644
> --- a/kernel/debug/kdb/kdb_io.c
> +++ b/kernel/debug/kdb/kdb_io.c
> @@ -227,8 +227,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
>         int count;
>         int i;
>         int diag, dtab_count;
> -       int key, buf_size, ret;
> -
> +       int key, ret;
>
>         diag = kdbgetintenv("DTABCOUNT", &dtab_count);
>         if (diag)
> @@ -310,21 +309,16 @@ static char *kdb_read(char *buffer, size_t bufsize)
>         case 9: /* Tab */
>                 if (tab < 2)
>                         ++tab;
> -               p_tmp = buffer;
> -               while (*p_tmp == ' ')
> -                       p_tmp++;
> -               if (p_tmp > cp)
> -                       break;
> -               memcpy(tmpbuffer, p_tmp, cp-p_tmp);
> -               *(tmpbuffer + (cp-p_tmp)) = '\0';
> -               p_tmp = strrchr(tmpbuffer, ' ');
> -               if (p_tmp)
> -                       ++p_tmp;
> -               else
> -                       p_tmp = tmpbuffer;
> -               len = strlen(p_tmp);
> -               buf_size = sizeof(tmpbuffer) - (p_tmp - tmpbuffer);
> -               count = kallsyms_symbol_complete(p_tmp, buf_size);
> +
> +               tmp = *cp;
> +               *cp = '\0';
> +               p_tmp = strrchr(buffer, ' ');
> +               p_tmp = (p_tmp ? p_tmp + 1 : buffer);
> +               strscpy(tmpbuffer, p_tmp, sizeof(tmpbuffer));

You're now using strscpy() here. Is that actually important, or are
you just following good practices and being extra paranoid? If it's
actually important, this probably also needs to be CCed to stable,
right? The old code just assumed that it  could copy the whole buffer
into tmpbuffer. I assume that was OK, but it wasn't documented in the
function comments that there was a maximum size that buffer could
be...


-Doug