This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #14134] Fix iconv segfault while converting fromIBM-930
- From: Petr Baudis <pasky at ucw dot cz>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 4 Jun 2012 19:21:17 +0200
- Subject: Re: [PATCH][BZ #14134] Fix iconv segfault while converting fromIBM-930
- References: <20120523072951.05c5a66f@spoyarek>
Hi!
On Wed, May 23, 2012 at 07:29:51AM +0530, Siddhesh Poyarekar wrote:
> When converting IBM930 code with iconv(), if IBM930 code which includes
> invalid multibyte character "0xffff" is specified, then iconv()
> segfaults. This is easy to see using the following command:
>
> echo '0x0e 0x43 0x8c 0xff 0xff 0x43 0xbd 0x43 0xbd' | xxd -r |
> iconv -f IBM930 -t UTF-8
>
> The crash seems to happen when looking up the offset for the
> character into the conversion table, since the conversion tables are
> delimited by {0xffff, 0xffff, 0} at the end. I've added an additional
> check for invalid character in this patch, which is to check if the
> matched entry is the one above. I have made an analogous change to the
> conversion-to-ibm930 section of the code since it makes sense logically,
> even though I don't have a reproducer to induce a crash the other way
> around.
Shouldn't this be a problem for rp1 (single-byte) table as well?
Also, this just doesn't make sense to me. The termination entry is
there precisely to break searching the array in the first place, and it
should work due to the initial test
if (__builtin_expect (ch >= 0xffff, 0)) \
{ \
UNICODE_TAG_HANDLER (ch, 4); \
STANDARD_TO_LOOP_ERR_HANDLER (4); \
}
How can control pass this test if ch == 0xffff?
--
Petr "Pasky" Baudis
Smart data structures and dumb code works a lot better
than the other way around. -- Eric S. Raymond