]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Don't assume GSSAPI result strings are null-terminated.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 23 Jun 2021 18:01:32 +0000 (14:01 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 23 Jun 2021 18:01:32 +0000 (14:01 -0400)
commitd3a845d1fd0fca8255f15aea508a6f86e2f5a852
tree8fc2d331e1bda5ee2415ffe3e39500083195ab6b
parent0a8929ca0b9e26c6cc60b54fd7a7030fc577d5ce
Don't assume GSSAPI result strings are null-terminated.

Our uses of gss_display_status() and gss_display_name() assumed
that the gss_buffer_desc strings returned by those functions are
null-terminated.  It appears that they generally are, given the
lack of field complaints up to now.  However, the available
documentation does not promise this, and some man pages
for gss_display_status() show examples that rely on the
gss_buffer_desc.length field instead of expecting null
termination.  Also, we now have a report that on some
implementations, clang's address sanitizer is of the opinion
that the byte after the specified length is undefined.

Hence, change the code to rely on the length field instead.

This might well be cosmetic rather than fixing any real bug, but
it's hard to be sure, so back-patch to all supported branches.
While here, also back-patch the v12 changes that made pg_GSS_error
deal honestly with multiple messages available from
gss_display_status.

Per report from Sudheer H R.

Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com
src/backend/libpq/auth.c
src/interfaces/libpq/fe-auth.c