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:41 +0000 (17:12 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 24 Jan 2007 17:12:41 +0000 (17:12 +0000)
commit4461eb17c61e82ddeb56741cd82c6a369f6cd96f
tree688ed657748209ba91fef6bd378fb27b537436d2
parent234db5bae10185417fc4a569ef563da34a48b92f
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