bugGNU Screen - Bugs: bug #53173, Out of bounds heap memory read in...

 
 

bug #53173: Out of bounds heap memory read in MClearArea()

Submitter:  None
Submitted:  Fri 16 Feb 2018 09:58:10 PM UTC
Votes: 5
 
Category:  None Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  4.6.2
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 22 Dec 2023 04:39:23 PM UTC, comment #4: 

Renewed summary: The reported memory errors are not just a nuisance without further impact, but cause very easily reproducible crashes. I’ve been running patched versions for months now, and I do consider them a significant improvement. The only strange thing I notice is that line-breaking seems to be non-deterministic somehow. I don't think this is a consequence of this patch. Rather it only surfaces now that the crash that would have occurred without it, is gone. See <https://drive.google.com/file/d/132K0BOvsD9di8wHMMPVyY0g0W822XRsm/view?usp=drive_link>. I cannot find a good justification for some of the lines being considered actual lines, while others seem to be treated as strings of equal length to window width at the time of creation. All of the lines in this screen capture originate from this shell command used to prevent my PVR hard disk from spinning down:


while sleep 240; do date && touch xx; done


The original patch is attached to this bug report here, and the rebased versions are obtainable from the PPA/copr repos linked from my previous comment.

Stefan Ring <ringdingcoder>
Fri 06 Oct 2023 12:01:36 PM UTC, comment #3: 

As a personal stop-gap solution, I created and have been using these repositories with great success:

https://copr.fedorainfracloud.org/coprs/ringding/screen/
https://launchpad.net/~stefanrin/+archive/ubuntu/patched

Stefan Ring <ringdingcoder>
Fri 25 Aug 2023 12:30:11 PM UTC, comment #2: 

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 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 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)

Stefan Ring <ringdingcoder>
Sun 04 Mar 2018 11:16:06 AM UTC, comment #1: 

attached preliminary fix, but would like to spend some more time looking into it, particularly the macro one seems like it may cause some problems, although I didn't see any in my testing

(file #43458)

Amadeusz Sławiński <amade>
Group administrator
Fri 16 Feb 2018 09:58:10 PM UTC, original submission:  

I detected an out of bounds heap read in screen when building with address sanitizer. Happens both in 4.6.2 and current git, though the code changed a bit, so the line numbers differ. I'll attach stack traces for both.

This can be reliably reproduced for me by:
1. compile screen with -fsanitize=address in CFLAGS+LDFLAGS.
2. run screen in a terminal emulator.
3. Press ctrl-a.
4. Resize the window.

Screen will hang and the main process will have crashed with an oob read in MClearArea.

Stack trace:
==19786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000001154 at pc 0x561d8c848842 bp 0x7ffdea718400 sp 0x7ffdea7183f0
READ of size 4 at 0x615000001154 thread T0
    #0 0x561d8c848841 in MClearArea /mnt/ram/screen/src/ansi.c:2117
    #1 0x561d8c8411ab in ClearLineRegion /mnt/ram/screen/src/ansi.c:1636
    #2 0x561d8c8390a8 in DoCSI /mnt/ram/screen/src/ansi.c:887
    #3 0x561d8c834085 in WriteString /mnt/ram/screen/src/ansi.c:426
    #4 0x561d8c937335 in win_readev_fn /mnt/ram/screen/src/window.c:1443
    #5 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
    #6 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
    #7 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)
    #8 0x561d8c8204a9 in _start (/mnt/ram/screen/src/screen+0x294a9)

0x615000001154 is located 0 bytes to the right of 468-byte region [0x615000000f80,0x615000001154)
allocated by thread T0 here:
    #0 0x7f33033ff220 in realloc (/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so.4+0xe1220)
    #1 0x561d8c90640d in xrealloc /mnt/ram/screen/src/resize.c:455
    #2 0x561d8c90503f in CheckMaxSize /mnt/ram/screen/src/resize.c:394
    #3 0x561d8c901cb1 in ChangeScreenSize /mnt/ram/screen/src/resize.c:128
    #4 0x561d8c901518 in CheckScreenSize /mnt/ram/screen/src/resize.c:100
    #5 0x561d8c9150f0 in ReceiveMsg /mnt/ram/screen/src/socket.c:813
    #6 0x561d8c828ee7 in serv_read_fn /mnt/ram/screen/src/screen.c:1627
    #7 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
    #8 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
    #9 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55074:  test-resize.csv added by ringdingcoder (12KiB - text/csv)
file #43335:  screen-asan-oob-4.6.2.txt added by None (3KiB - text/plain - full asan errors)
file #43336:  screen-asan-oob-git.txt added by None (3KiB - text/plain - full asan errors)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ckujau (Voted in favor of this item)
  • -email is unavailable- added by ringdingcoder (Updated the item)
  • -email is unavailable- added by amade (Updated the item)
  •  

    There are 5 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-01-24 ckujau Carbon-Copy- Added ckujau
    2023-08-25 ringdingcoder Attached File- Added test-resize.csv, #55074
    2018-03-04 amade Attached File- Added 0001-fix-out-of-bound-accesses.patch, #43458
    2018-02-16 None Attached File- Added screen-asan-oob-4.6.2.txt, #43335
        Attached File- Added screen-asan-oob-git.txt, #43336

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code