From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Code quality issues in ICU patch |
Date: | 2017-06-23 18:07:42 |
Message-ID: | 20170623180742.GA31359@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 23, 2017 at 12:31:40PM -0400, Tom Lane wrote:
> icu_to_uchar() and icu_from_uchar(), and perhaps other places, are
> touchingly naive about integer overflow hazards in buffer size
> calculations. I call particular attention to this bit in
> icu_from_uchar():
>
> len_result = UCNV_GET_MAX_BYTES_FOR_STRING(len_uchar, ucnv_getMaxCharSize(icu_converter));
>
> The ICU man pages say that that macro is defined as
>
> #define UCNV_GET_MAX_BYTES_FOR_STRING(length, maxCharSize) (((int32_t)(length)+10)*(int32_t)(maxCharSize))
>
> which means that getting this to overflow (resulting in
> probably-exploitable memory overruns) would be about as hard as
> taking candy from a baby.
So it kicks off really loud and persistent alarms, and isn't as easy
as you thought, even taking this into account?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-06-23 18:21:57 | Re: Fix a typo in snapmgr.c |
Previous Message | Simon Riggs | 2017-06-23 18:07:19 | Re: Small bug in replication lag tracking |