From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sudheer H R <sudheer.hr@tekenlight.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Found a buffer-overflow defect in asynchronous database
 connection API PQconnectPoll
In-reply-to: <5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com>
References: <5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com>
Comments: In-reply-to Sudheer H R <sudheer.hr@tekenlight.com>
	message dated "Wed, 23 Jun 2021 17:43:32 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2080222.1624454678.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Jun 2021 09:24:38 -0400
Message-ID: <2080223.1624454678@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2080223.1624454678%40sss.pgh.pa.us>
Precedence: bulk

Sudheer H R <sudheer.hr@tekenlight.com> writes:
> While trying to sanitise the code for heap buffer overflows I compiled a=
nd linked the executable with clang -fsanitize=3D=E2=80=9Caddress=E2=80=9D=
 option. The connection library indicates a buffer over flow in an interna=
l source code of the module.

Hm, interesting.  Our code is expecting that gss_display_status() returns
a null-terminated string, but this trace suggests that the string is
not necessarily null-terminated.  The documentation I found on the net
is unclear on the point, and the code I could find is split as to how
the string is treated.  If it's not supposed to be null-terminated,
we're hardly the only ones making that mistake.

In any case, you wouldn't get here unless we'd run into some kind of
problem trying to make a GSS connection.  Could you maybe explain the
conditions you're running this under, and/or print out the failure message
it constructs?

			regards, tom lane