[screen-devel] [bug #53173] Out of bounds heap memory read in MClearArea()

[Stefan Ring]

Follow-up Comment #2, bug #53173 (project screen):

It's a real shame that this patch is still lingering here. I have been plagued
by occasional screen crashes since version 4.3.1 in 2015, but I have never
been able to reproduce it. It just happened during window resizing from time
to time, usually at the most inconvenient moment. Since then, I have been very
reluctant to resize windows for fear of screen crashing again, taking all
subwindows with it. So I finally attempted to reproduce it just a few weeks
ago and gave up without anything to show for it after a few hours. But as luck
would have it, and not looking for it actively anymore, I found a relatively
reliable reproducer two days ago.

I remember always blaming
[https://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=27a8c9677a95b8de67c91f983b25691f0864c194
this fix] because it shows up in the git log just before the 4.3.1 release,
which is the one that Fedora upgraded its package to at the time, and which
introduced me to the entire issue, but now that I have a way to test for it, I
found out that it was actually caused by
[https://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=9dc8d7c2008c3c698c2e018c3ec123e6dd622f5e
this], which makes sense, because previously, the allocated memory sizes were
generously rounded up, so the occasional overflow by 1 byte would not usually
cause problems.

The crash looks like this, apparently because of heap corruption:

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140043730262912) at
./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140043730262912) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140043730262912) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140043730262912, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3  0x00007f5e78a42476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007f5e78a287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007f5e78a896f6 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f5e78bdbb8c "%s\n")
    at ../sysdeps/posix/libc_fatal.c:155
#6  0x00007f5e78aa0d7c in malloc_printerr (str=str@entry=0x7f5e78bd9711
"corrupted size vs. prev_size")
    at ./malloc/malloc.c:5664
#7  0x00007f5e78aa1862 in unlink_chunk (p=p@entry=0x55cfd4bb4610,
av=0x7f5e78c19c80 <main_arena>) at ./malloc/malloc.c:1629
#8  0x00007f5e78aa4cac in _int_realloc (av=av@entry=0x7f5e78c19c80
<main_arena>, oldp=oldp@entry=0x55cfd4bb4580,
    oldsize=oldsize@entry=144, nb=nb@entry=160) at ./malloc/malloc.c:4872
#9  0x00007f5e78aa5989 in __GI___libc_realloc
(oldmem=oldmem@entry=0x55cfd4bb4590, bytes=bytes@entry=139)
    at ./malloc/malloc.c:3485
#10 0x000055cfd3d227a5 in xrealloc (len=139, mem=0x55cfd4bb4590 ' ' <repeats
136 times>, "\221") at resize.c:624
#11 CheckMaxSize (wi=wi@entry=138) at resize.c:543
#12 0x000055cfd3d2352d in ChangeScreenSize (wi=138, he=39,
change_fore=change_fore@entry=1) at resize.c:182
#13 0x000055cfd3d2371a in CheckScreenSize (change_flag=change_flag@entry=1) at
resize.c:143
#14 0x000055cfd3d281b9 in ReceiveMsg () at socket.c:1213
#15 0x000055cfd3d5b878 in sched () at sched.c:222
#16 0x000055cfd3d10708 in main (ac=0, av=<optimized out>) at screen.c:1486

To reproduce it, I run "setarch -RL x86_64 screen" in a moderately-sized
(around 100x40) GNOME Terminal window, fetch "less ~/temp/test-resize.csv"
from the shell history (Ctrl-R plus a few letters), run it, grab the left
window handle and expand the window to around 200 columns. It does not always
crash, but it is very unlikely to not crash 5 times in a row. And if it does,
it's within the first two seconds of dragging the window around. This is on
Ubuntu 22.04 amd64. I am not using a special ~/.screenrc file for this test.
The reproducing test file is attached, and it is actually nothing special at
all. Just a few lines of numbers.

So I've happily been running a patched v4.9.0 since yesterday without issues
(there are some memmoves in the patch that were once bclears, so this needed
to be adjusted for the -v4 branch).

(file #55074)

    _______________________________________________________

Additional Item Attachment:

File name: test-resize.csv                Size:11 KB
    <https://file.savannah.gnu.org/file/test-resize.csv?file_id=55074>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?53173>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/