2090Re: SEGV in msg_may_trunc()
- Dec 21, 2005Bram,
this will work, but it will still count the length of the string twice
which I tried to avoid...
Still, what about the case when the '>' is placed into one of the bytes
of a multibyte character ?
I guess it was never noticed before, as usually the bytes just before
a malloc'ed address belong to the malloc() system data, which isn't true on
BSD. And how many people use variable multibyte output locale on openBSD :)
On Wed, Dec 21, 2005 at 10:55:21PM +0100, Bram Moolenaar wrote:
>> VIM (6.3.85p0) on openBSD 3.8, built from /usr/ports.
>> in message.c there is a probable SEGV in msg_may_trunc() function.
>> If multibyte string is passed in, and the size of the string in characters
>> is less than room, but size in bytes is more than room, the (s-1) address
>> is then written to, as (n) becomes -1.
>> The attached patch should help. Should work on 6.4 as well.
>> What I still don't understand is how it is OK to replace some position
>> in asciiz string with '>'. Does anything guarantee that the position the
>> '>' is written to is not a part of a multibyte character ?
>Strange that this has gone unnoticed so long. It's probably because it
>only happens when using IObuff as the buffer, which is never freed.
>Then using one byte before the buffer writes in the length of the
>buffer, and if you don't free it that is not causing trouble. But
>of course it's bad anyway, just an explanation why we haven't seen
>crashes all around.
>A simpler solution is to check for "n" being negative and not doing
>anything then. Like this:
>RCS file: /cvsroot/vim/vim7/src/message.c,v
>retrieving revision 1.32
>diff -u -r1.32 message.c
>--- message.c 3 Oct 2005 21:50:54 -0000 1.32
>+++ message.c 21 Dec 2005 21:40:36 -0000
>@@ -727,6 +727,10 @@
> size -= (*mb_ptr2cells)(s + n);
> n += (*mb_ptr2len)(s + n);
>+ /* there may be room anyway when there are multi-byte chars */
>+ if (n == 0)
>+ return s;
[ skipped ]
- << Previous post in topic Next post in topic >>