]> granicus.if.org Git - postgresql/commit
Get pg_utf_mblen(), pg_utf2wchar_with_len(), and utf2ucs() all on the same
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 24 Jan 2007 17:12:17 +0000 (17:12 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 24 Jan 2007 17:12:17 +0000 (17:12 +0000)
commit0887fa111724ba3b0732a4303fda5031e4d695f9
tree87ea415d3e9dd956db970153cbf428e034435e05
parent07cf99ac6fc6d0265efae5cb88c345d7dbcd57fd
Get pg_utf_mblen(), pg_utf2wchar_with_len(), and utf2ucs() all on the same
page about the maximum UTF8 sequence length we support (4 bytes since 8.1,
3 before that).  pg_utf2wchar_with_len never got updated to support 4-byte
characters at all, and in any case had a buffer-overrun risk in that it
could produce multiple pg_wchars from what mblen claims to be just one UTF8
character.  The only reason we don't have a major security hole is that most
callers allocate worst-case output buffers; the sole exception in released
versions appears to be pre-8.2 iwchareq() (ie, ILIKE), which can be crashed
due to zeroing out its return address --- but AFAICS that can't be exploited
for anything more than a crash, due to inability to control what gets written
there.  Per report from James Russell and Michael Fuhr.

Pre-8.1 the risk is much less, but I still think pg_utf2wchar_with_len's
behavior given an incomplete final character risks buffer overrun, so
back-patch that logic change anyway.

This patch also makes sure that UTF8 sequences exceeding the supported
length (whichever it is) are consistently treated as error cases, rather
than being treated like a valid shorter sequence in some places.
src/backend/utils/mb/wchar.c