This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #14134] Fix iconv segfault while converting fromIBM-930


  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]