From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | Spyridon Dimitrios Agathos <spyridon(dot)dimitrios(dot)agathos(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bug: Reading from single byte character column type may cause out of bounds memory reads. |
Date: | 2022-07-13 15:11:34 |
Message-ID: | 2231634.1657725094@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
> something that generally prevents pg_mblen() from doing out of bound
> reading in cases similar to this one? Should we prevent such an INSERT
> from happening instead?
This is ultimately down to char_text() generating a string that's alleged
to be a valid "text" type value, but it contains illegally-encoded data.
Where we need to fix it is there: if we try to make every single
text-using function be 100% bulletproof against wrongly-encoded data,
we'll still be fixing bugs at the heat death of the universe.
I complained about this in [1], but that thread died off before reaching a
clear consensus about exactly what to do.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-07-13 15:32:12 | Re: PG15 beta1 sort performance regression due to Generation context change |
Previous Message | Andrew Dunstan | 2022-07-13 15:03:43 | Re: [PATCH] Optimize json_lex_string by batching character copying |