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: Tue, 23 Apr 2024 12:02:12 +0100
From: Daniel Thompson <daniel.thompson@...aro.org>
To: Doug Anderson <dianders@...omium.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()

On Mon, Apr 22, 2024 at 04:52:52PM -0700, Doug Anderson wrote:
> On Mon, Apr 22, 2024 at 9:38 AM Daniel Thompson
> <daniel.thompson@...aro.org> wrote:
> > 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
> > @@ -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...

This is pretty much it.

I used strscpy() because the function does not document any upper limit
on the length of the supplied buffer. Thus using strscpy() means we are
resilient in the face of future refactoring.

I chose not to Cc: stable@... since it's only a theoretic overflow.
With the code as it currently is kdb_read() should never be passed a
buffer long enough to cause problems.


Daniel.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ