Re: waddnstr accesses extra byte after allocated memory

[Bill Gray]

Hi Sergey,

On 1/31/25 09:52, Sergey Poznyakoff wrote:
> (snip)
> That doesn't harm the functionality, of course, but makes
> memory checking tools unnecessarily noisy.

   Depends.  You _could_ be accessing a byte you don't own.  Some bad 
luck would be required for that,  but you could conceivably segfault 
with an out-of-bounds access.  And as you note,  Valgrind and similar 
tools will definitely be unhappy with you.

   I thought this sounded familiar,  and it turns out that the same bug 
lurked in PDCurses* for some years.  It was fixed in PDCursesMod in 2021 :

https://github.com/Bill-Gray/PDCursesMod/commit/c03e650a7020c8

   I see that it remains unpatched in PDCurses... will add a note for 
its maintainer,  who can copy/paste the fix if so inclined.

   One caveat (and a reason,  perhaps,  for ncurses commit 42259b594) 
is that in the new version,  we see the '\0' and stop before 
decrementing n.  In the prior version,  we'd decrement n before jumping 
out.  If n gets used later,  you'd be off by one.  (The -3 most common 
errors are off-by-ones and sign problems.)

-- Bill

>  For example,
> running the attached simple program under valgrind produces
> the following:
>
> ==10856== Invalid read of size 1
> ==10856==    at 0x48873E9: waddnstr (in /lib64/libncurses.so.6.3)
> ==10856==    by 0x4011B9: main (in /home/gray/tmp/a.out)
> ==10856==  Address 0x4abe041 is 0 bytes after a block of size 1 alloc'd
> ==10856==    at 0x483F7C5: malloc (vg_replace_malloc.c:381)
> ==10856==    by 0x40116E: main (in /home/gray/tmp/a.out)
>
> Reverting the condition to its state before 42259b594 fixes
> the problem.
>
> Regards,
> Sergey