It should work if you start it with "tmux new" not "tmux".


On Tue, Sep 16, 2014 at 03:37:59PM +0200, Thomas St??fe wrote:
>    Yes you did. Sorry, just looked at the 1.9a sources, not your development
>    sources.**
>    Might probably make sense to roll this fix out, because right now tmux
>    1.9a is unusable (it crashes on three of my linux machines).
>    Kind Regards, Thomas St**fe
>    On Tue, Sep 16, 2014 at 2:56 PM, Nicholas Marriott
>    <[1]nicholas.marri...@gmail.com> wrote:
> 
>      Hi. Pretty sure I already fixed this.
> 
>      -------- Original message --------
>      From: Thomas St**fe <[2]thomas.stu...@gmail.com>
>      Date: 16/09/2014 13:22 (GMT+00:00)
>      To: [3]tmux-users@lists.sourceforge.net
>      Subject: Fix for buffer overwriter in cmd.c (cmd_pack_argv)
> 
>      Hi all,
>      I did run into a buffer overwriter which caused a crash when starting
>      tmux on linux.
>      I downloaded tmux 1.9a and installed it from the sources.
>      tmux crashes (aborts) on my linux machine right after start in the libc
>      with the following callstack:
>      Program terminated with signal 6, Aborted.
>      #0 **0x00007f51f5d09b55 in raise () from /lib64/libc.so.6
>      (gdb) where
>      #0 **0x00007f51f5d09b55 in raise () from /lib64/libc.so.6
>      #1 **0x00007f51f5d0b131 in abort () from /lib64/libc.so.6
>      #2 **0x00007f51f5d4d640 in malloc_printerr () from /lib64/libc.so.6
>      #3 **0x00000000004066b3 in client_main ()
>      #4 **0x0000000000434342 in main ()
>      The crash is in a call to free(2).**
>      The crash is caused by a buffer overwriter in cmd_pack_argv() in cmd.c.
>      The error is that**
>      the function unconditionally writes '\0' to the first byte of the output
>      buffer without checking
>      output buffer size or argc.**
>      If argc is 0, output buffer size is 0, and we overwrite one byte beyond
>      the range allocated at
>      client_main() (client.c line 291).
>      This does not always lead to an error; depends on whether there are any
>      important data
>      beyond the allocated 4 bytes.
>      I believe the small patch below fixes the bug; at least it makes the bug
>      disappear on my**
>      machine:
>      --- cmd.c_  2014-09-16 14:07:01.000000000 +0200
>      +++ cmd.c  2014-09-16 14:07:49.000000000 +0200
>      @@ -138,6 +138,10 @@
>      **  size_t  arglen;
>      **  int  i;
>      **
>      + **if (argc == 0) {
>      + ** **return (0);
>      + **}
>      +
>      **  *buf = '\0';
>      **  for (i = 0; i < argc; i++) {
>      **  if (strlcpy(buf, argv[i], len) >= len)
>      Kind Regards, Thomas St**fe
> 
> References
> 
>    Visible links
>    1. mailto:nicholas.marri...@gmail.com
>    2. mailto:thomas.stu...@gmail.com
>    3. mailto:tmux-users@lists.sourceforge.net

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Reply via email to