Re: Possible buffer overrun in src/backend/libpq/hba.c gethba_options()

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Possible buffer overrun in src/backend/libpq/hba.c gethba_options()
Дата
Msg-id CAEepm=2xjrt4P1-UYs5170B5sc5Gq7bT9gj9eB=33GLFn9Wk0Q@mail.gmail.com
обсуждение исходный текст
Ответ на Possible buffer overrun in src/backend/libpq/hba.c gethba_options()  (Julian Hsiao <jhsiao@salesforce.com>)
Ответы Re: Possible buffer overrun in src/backend/libpq/hba.c gethba_options()  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Tue, Nov 13, 2018 at 3:02 PM Julian Hsiao <jhsiao@salesforce.com> wrote:
> During a routine Coverity scan of our internal PostgreSQL fork, it
> issued a buffer overrun warning for src/backend/libpq/hba.c,
> gethba_options()[0]:
>
> MAIN_ISSUE EventDescription: Overrunning array "options" of 12 8-byte
> elements at element index 12 (byte offset 96) using index "noptions++"
> (which evaluates to 12).
> [...]
>         if (hba->ldapscope)
>             options[noptions++] =
>                 CStringGetTextDatum(psprintf("ldapscope=%d", hba->ldapscope));
> [...]
>
> This is because earlier in the function[1], if hba->usermap,
> hba->clientcert, and hba->pamservice were set then noptions would
> exceed MAX_HBA_OPTIONS. Of course, if those options are mutually
> exclusive with hba->auth_method == uaLDAP, then it's a false positive.
> Is that the case, or should MAX_HBA_OPTIONS be increased?

Right, thank you.  It seems clear that MAX_HBA_OPTIONS should be
increased and the comment near its definition is wrong.  Will fix.

-- 
Thomas Munro
http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: move PartitionBoundInfo creation code
Следующее
От: Amit Langote
Дата:
Сообщение: Re: move PartitionBoundInfo creation code