Hi,

On Thu, Jun 18, 2026 at 3:04 AM David Laight
<[email protected]> wrote:
>
> > > @@ -783,8 +783,6 @@ static int kdb_exec_defcmd(int argc, const char 
> > > **argv)
> > >
> > >  /* Command history */
> > >  #define KDB_CMD_HISTORY_COUNT  32
> > > -#define CMD_BUFLEN             200     /* kdb_printf: max printline
> > > -                                        * size == 256 */
> >
> > Maybe Daniel will know more; otherwise, I need to spend more time
> > digging. ...but the comment above (that you're deleting) makes me
> > believe that 200 was purposely chosen to be a number that was under
> > 256. It sounds as if maybe they're keeping some buffers at 200 so that
> > there'e enough extra space to print the buffer plus some extra stuff?
> >
> > Maybe safer to keep the number at 200?
>
> I bet the prompt+command has to fit in 256 bytes?
> Who wants a prompt that is more than (about) 20 characters anyway?

As I said, I'm not really sure there's value in messing with the kdb
prompt to begin with, since there's no useful info you can put in it
other than the CPU. ...but whatever.


> FWIW there are a few other very strange strcpy() in kdbg that I'm pretty
> sure can actually overwrite the end of the buffer.
> (Ones that put a special marker string (IIRC "kdbg") into a buffer.)

We've had several rounds of patches improving string safety. If you
can show any missed cases, please send a patch. In this day and age,
if there are problems, it's probably a matter of time before AI sends
us patches. I presume Naveen ended up here to begin with because AI
pointed out the problems that he's fixing.

-Doug


_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Reply via email to