[20572] in Kerberos_V5_Development
Bug in mechglue's copy_mech_cred function?
daemon@ATHENA.MIT.EDU (Sands, Daniel N. via krbdev)
Thu May 21 02:24:36 2026
To: "krbdev@mit.edu" <krbdev@mit.edu>
Date: Wed, 20 May 2026 23:43:46 +0000
Message-ID: <SA9PR09MB530904347D8440230E18CDDEDB012@SA9PR09MB5309.namprd09.prod.outlook.com>
Content-Language: en-US
MIME-Version: 1.0
From: "Sands, Daniel N. via krbdev" <krbdev@mit.edu>
Reply-To: "Sands, Daniel N." <dnsands@sandia.gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I'm looking at code in the 1.18 distribution as well as 1.21. I have what I'm pretty sure is a bug that will cause memory corruption and/or segfaults for 3rd party gssapi mechs, at the least. It's in the case where gss_export_cred and gss_import cred are NOT implemented, but gss_inquire_cred and gss_acquire_cred are. What I see is:
status = mech->gss_inquire_cred(minor_status, cred_in, &name, &life,
&usage, NULL);
This calls the mechanism-specific function to inquire the name of a credential. That means that the 'name' will only be usable by this mechanism. Next:
status = mech->gss_acquire_cred(minor_status, name, life, &oidset,
usage, cred_out, NULL, NULL);
Again, the mechanism-specific version of gss_acquire_cred is used. This uses the mechanism-specific name, which is correct. Finally:
gss_release_name(&tmpmin, &name);
This calls the mechglue version of gss_release_name, on the mechanism-specific 'name'. The 'name' will not be in a format that makes sense to mechglue. Shouldn't it call mech->gss_release_name instead?
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
