Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crash in put_wc #74

Open
MarSoft opened this issue Nov 14, 2017 · 1 comment · May be fixed by #124
Open

Crash in put_wc #74

MarSoft opened this issue Nov 14, 2017 · 1 comment · May be fixed by #124

Comments

@MarSoft
Copy link
Contributor

MarSoft commented Nov 14, 2017

Another sporadic crash. Last time it happened when I ran git diff in one of the active windows, but I don't know what could cause that.

Core dump info:

           PID: 2177 (dvtm)
           UID: 1000 (mars)
           GID: 1000 (mars)
        Signal: 11 (SEGV)
     Timestamp: Tue 2017-11-14 17:24:04 MSK (6min ago)
  Command Line: dvtm -d 10 -h 5000 -c /run/user/1000/dvtm-session-cmd-2168.fifo -s /run/user/1000/dvtm-session-status-2168.fifo
    Executable: /usr/bin/dvtm
 Control Group: /user.slice/user-1000.slice/session-c2.scope
          Unit: session-c2.scope
         Slice: user-1000.slice
       Session: c2
     Owner UID: 1000 (mars)
       Boot ID: 4c2eea29941a40f7b7deba554b1a2fd3
    Machine ID: e05da9ccd03d465a8b5ecee7a9103251
      Hostname: hpook
       Storage: /var/lib/systemd/coredump/core.dvtm.1000.4c2eea29941a40f7b7deba554b1a2fd3.2177.1510669444000000.lz4
       Message: Process 2177 (dvtm) of user 1000 dumped core.
                
                Stack trace of thread 2177:
                #0  0x000056181865e7bb put_wc (dvtm)
                #1  0x0000561818658a85 main (dvtm)
                #2  0x00007ffa6163ff6a __libc_start_main (libc.so.6)
                #3  0x00005618186592fa _start (dvtm)

Tried to debug it with gdb and found that the problem happened in dvtm/vt.c line 1393, and that b->curs_row->cells was 0x2000000000 which is obviously not the correct memory address.

$ dvtm -v
dvtm-v0.15-37-gb45828d-dirty © 2007-2016 Marc André Tanner
@MarSoft MarSoft mentioned this issue Dec 4, 2017
Closed
@MarSoft MarSoft mentioned this issue Mar 8, 2018
Closed
@GReagle
Copy link

GReagle commented May 17, 2021

Core dump info:

How did you get the core dump info?

phillid added a commit to phillid/dvtm that referenced this issue Jun 19, 2021
@phillid
Ensure cursor is clamped after buffer swap
6439b1c 
vt_resize resizes both buffers of the given Vt* (involving a realloc),
but can only correctly clamp the cursor of the active buffer. This means
that when it comes time to switch to the other buffer in
interpret_csi_priv_mode, we might be switching to a buffer which has a
cursor pointing to old memory. Thus, when we switch buffers it's
necessary to ensure the cursor is clamped to avoid memory errors.

This is a bug I've observed for a few years but never often enough to
worry me. After I was able to pin it down to activities such as opening
of manpages and resizing terminals, I boiled it down to be reproducible
as:

1. Open a manpage in dvtm, buffer swap to alt
2. Close the manpage and return to the shell, buffer swaps to norm
3. Resize the pane to have fewer rows than before, alt+norm are resized
   but only norm has its cursor clamped
4. Open a manpage again, UAF causes crash since unclamped curs_row on
   alt buffer is still pointing to before-resize allocation

With some exploratory testing I have seen crashes identical and nearly
identical to the following fixed by this patch:

* martanne#73
* martanne#74
@phillid phillid linked a pull request Jun 19, 2021 that will close this issue
Open
owm111 pushed a commit to owm111/dvtm that referenced this issue May 27, 2022
@phillid
Ensure cursor is clamped after buffer swap
9a60d25 
vt_resize resizes both buffers of the given Vt* (involving a realloc),
but can only correctly clamp the cursor of the active buffer. This means
that when it comes time to switch to the other buffer in
interpret_csi_priv_mode, we might be switching to a buffer which has a
cursor pointing to old memory. Thus, when we switch buffers it's
necessary to ensure the cursor is clamped to avoid memory errors.

This is a bug I've observed for a few years but never often enough to
worry me. After I was able to pin it down to activities such as opening
of manpages and resizing terminals, I boiled it down to be reproducible
as:

1. Open a manpage in dvtm, buffer swap to alt
2. Close the manpage and return to the shell, buffer swaps to norm
3. Resize the pane to have fewer rows than before, alt+norm are resized
   but only norm has its cursor clamped
4. Open a manpage again, UAF causes crash since unclamped curs_row on
   alt buffer is still pointing to before-resize allocation

With some exploratory testing I have seen crashes identical and nearly
identical to the following fixed by this patch:

* martanne#73
* martanne#74
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Ensure cursor is clamped after buffer swap phillid/dvtm
2 participants
@MarSoft @GReagle