Fault in vformat.c due to insufficient buffer size

[ashikase]

Problem

There appears to be a bug in vformat.c:_read_attribute_value_add.

The buffer for the ouput string, outbuf, is set to twice the length of the input string:

Line 252: p = outbuf = malloc(str->len*2);

The final character of the output string is set to 0 (null):

Line 267: *p = 0;

The problem arrises when the size of the output string is equal to the size of the output buffer; no room is left for the null terminator. Thus, a memory address outside of the range of the output buffer is modified. When the function attempts to free the allocated memory:

Line 310: free(outbuf);

... a fault occurs:

*** glibc detected *** ./vconvert: free(): invalid pointer: 0x0804fc60 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7e4fd65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7e53800]
/lib/tls/i686/cmov/libc.so.6[0xb7e05ad4]
/lib/tls/i686/cmov/libc.so.6[0xb7dfdd6d]
/lib/tls/i686/cmov/libc.so.6[0xb7dfdb42]
/lib/tls/i686/cmov/libc.so.6(iconv_close+0x1c)[0xb7dfd13c]
/usr/local/lib/libvformat.so.0.0.0[0xb7b16c8c]
/usr/local/lib/libvformat.so.0.0.0[0xb7b18644]
/usr/local/lib/libvformat.so.0.0.0(vformat_construct+0x176)[0xb7b19366]
/usr/local/lib/libvformat.so.0.0.0(vformat_new_from_string+0x3b)[0xb7b1967b]
/usr/local/lib/opensync/formats/libxmlformat-vcard.so[0xb7b343e0]
/usr/local/lib/libopensync.so.1.0.0(osync_converter_invoke+0x17d)[0xb7f500b5]
/usr/local/lib/libopensync.so.1.0.0(osync_format_env_convert+0x26d)[0xb7f52d33]
./vconvert[0x804966e]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7dfc050]
./vconvert[0x8048c71]

Solution

Increasing the allocation size of the output buffer by 1, thus making room for the null terminator, appears to fix the problem:

Line 252: p = outbuf = malloc(str->len*2);

Reproduction

This may be a rarely encountered bug. In my case, it occurred while trying to convert an incorrectly formatted vcard. One of the fields of the vcard claimed that its data was Shift-JIS encoded, though it was actually UTF-8.

Below is a sample vcard containing such data (due to a problem with Trac, I am unable to attach the vcard as a file; I apologize if any of the characters in the vcard appear as garbage):

BEGIN:VCARD
VERSION:3.0
FN;CHARSET="Shift_JIS":会社
END:VCARD

Notes

The suggested patch will prevent the plugin from crashing, but it will fix the conversion error. Due to the incorrect CHARSET attribute, iconv will still treat the UTF-8 data as Shift-JIS, thus producing incorrect output.

[cstender]

Fixed in svn. Thanks a lot for the report.

[sim]

 decoration Changed 1 year ago by admin

 bathtub Changed 1 year ago by admin

 solar system Changed 1 year ago by admin

 stair parts Changed 1 year ago by admin

 solar supply Changed 1 year ago by admin