]> 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)
commit7eaf65451483a871056036e92e4f0fa0350b5504
tree46042951765a3096e0dbfe1a4cd4ded7fe05d22f
parentd7da3ef08989691ffe13a914a839ea9e92b59a19
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/backend/libpq/be-gssapi-common.c
src/interfaces/libpq/fe-gssapi-common.c