Bug 13439 - iconv_open incorrectly shares internal conversion state
Summary: iconv_open incorrectly shares internal conversion state
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.14
: P2 critical
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2011-11-25 17:09 UTC by Weng Xuetian
Modified: 2014-06-13 14:37 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Weng Xuetian 2011-11-25 17:09:45 UTC
Here is a piece of code: http://pastebin.com/GpwkwWm2
On Archlinux with glibc 2.14.1

The final output will be ㄀㄀㄀㄀㄀㄀.

Seems it works with glibc 2.13.
Comment 1 Andreas Jaeger 2011-11-25 19:14:27 UTC
Please provide a self-contained testcase without any other libraries like Qt involved.
Comment 2 Weng Xuetian 2011-11-25 21:31:06 UTC

Ok, to make the problem clear.
iconv_open("UTF-8", "UTF-16") in glibc 2.13 will not remember the endianness , while glib 2.14 will remember it, no matter another iconv_open is called.

glibc 2.13 output

glibc 2.14 output

Comment 3 Andreas Jaeger 2011-11-28 08:58:33 UTC
Information provided.
Comment 4 Ulrich Drepper 2011-12-18 02:11:26 UTC
That's the correct behavior.  If you want to convert a new string you have to use iconv_close.  It would be absolutely wrong to reset the setting after every iconv() call since this would make it impossible to convert a file/buffer in pieces.
Comment 5 Weng Xuetian 2011-12-18 06:59:50 UTC
Is it supposed to like this? The code use iconv_open TWICE.

I support each of iconv_t have it's own state, but not affect each other, this is not true any more? As you can see, it's true in 2.13.

If it's not true, it will break many library. Like I just use iconv_open("UTF-16", "UTF-8") here, and another library use iconv_open("UTF-16", "UTF-8") in another place, but I didn't aware, then it will break.
Comment 6 Ulrich Drepper 2011-12-21 23:48:13 UTC
I checked in a patch.
Comment 7 Jackie Rosen 2014-02-16 18:23:55 UTC Comment hidden (spam)
Comment 8 Florian Weimer 2014-06-13 14:24:39 UTC
This can result in data corruption in multi-threaded programs.  It does not result in information leaks because only the endianness flag and no other data is shared incorrectly.

Commit ee190f67cc00b958a667af75dc68f3fc21611c9f is the fix (but the commit message is somewhat misleading).