At Tue, 15 Feb 2022 09:17:34 -0300, Ranier Vilela <ranier.vf@gmail.com> wrote in
> Per Coverity.
Thanks for the source:)
> Like the function pg_encoding_max_length_sql
> (src/backend/utils/mb/mbutils.c)
> Only assertion is insufficient to avoid accessing array out-of-bounds.
>
> This bug is live according Coverity at function: pg_verify_mbstr_len
> (src/backend/utils/mb/mbutils.c)
> CID 1469870 (#1 of 1): Out-of-bounds access (OVERRUN)7. overrun-call:
> Overrunning
> callee's array of size 42 by passing argument src_encoding (which evaluates
> to 63) in call to pg_verify_mbstr_len. [show details
>
<https://scan6.scan.coverity.com/eventId=32693869-7&modelId=32693869-0&fileInstanceId=131415642&filePath=%2Fdll%2Fpostgres%2Fpostgres%2Fsrc%2Fbackend%2Futils%2Fmb%2Fmbutils.c&fileStart=1546&fileEnd=1605>
It returns 400..
> ]
> 633 retval = pg_verify_mbstr_len(src_encoding, src_str, len, false);
> 634
>
> Trivial patch attached.
Mmm? If the assert doesn't work, there should be inconcsistency
between pg_enc and pg_wchar_table. But AFAICS they are consistent.
The patch:
pg_encoding_max_length(int encoding)
{
- Assert(PG_VALID_ENCODING(encoding));
-
- return pg_wchar_table[encoding].maxmblen;
+ if (PG_VALID_ENCODING(encoding))
+ return pg_wchar_table[encoding].maxmblen;
+ else
+ return -1;
Returning -1 for invalid encoding is, I think, flat wrong.
> 633 retval = pg_verify_mbstr_len(src_encoding, src_str, len, false);
The src_encoding comes from pg_char_to_encoding. It returns
pg_encname_tbl[n]->encoding, which seems to reutrn a value of
pg_enc. the max value of which is 42. So I don't come up with a
hypothesis that makes it possible for now..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
