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()
|
Список | 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 по дате отправления: