Ticket History #5841: GSSAPI Error Display Bug

# Tue Nov 13 17:02:17 2007 David Bartley <dtbartle@csclub.uwaterloo.ca> - Ticket created

Date:	Tue, 13 Nov 2007 03:15:59 -0500 (EST)
From:	David Bartley <dtbartle@csclub.uwaterloo.ca>
To:	krb5-bugs@mit.edu
Subject:	GSSAPI Error Display Bug

Download (untitled) / with headers
text/plain 695B

There's a bug in the GSSAPI g_display_com_err_status function. Kerberos
error codes are represented as an int32 are are negative. However, in
g_display_com_err the status_value (i.e. the krb5 error) is passed in as a
uint32. This function then passes status_value to error_message, which
expects a signed long, which is an int64 on 64-bit systems. Casting a uint32
to an int64 will not sign-extend the value, so an incorrect error code ends
up being passed to error_message.

This bug can be seen when using SASL/GSSAPI (e.g. ldapsearch). On 32-bit
systems the full error text is displayed, whereas on 64-bit systems only
the error number is displayed. I've attached a patch which fixes the bug.

Download krb5-gssapi-bug.patch
text/x-diff 647B

Message body is not shown because sender requested not to inline it.

# Tue Mar 17 17:34:33 2009 tlyu (Taylor Yu) - Taken

# Fri Apr 11 13:57:22 2025 ghudson@mit.edu (Greg Hudson) - Comments added

Download (untitled) / with headers
text/html 1.2KiB

This bug was never fixed in g_display_com_err_status(). However, I believe all visible manifestations of it were fixed in 1.7. Details follow:

Commit fcdd2de143971b0f020531479ad18f57874aef30 changed krb5_gss_display_status() to support extended error messages; in the process, it stopped using g_display_com_err_status(). Commit abcfdaff756631d73f49103f679cafa7bc45f14e added the necessary cast to the error_message() call in the replacement code.

g_display_com_err_status() is still used by the mechglue's g_display_com_err_status() when the minor code mapping does not contain a mech OID--meaning the code was generated by the mechglue, not by a mech. So, for this bug to remain visible, the mechglue would have to generate a com_err code within the negative range. System errors like ENOMEM are positive, so wouldn't manifest the bug.

Since the mechglue sometimes delegates to functions in lib/gssapi/generic, codes in gssapi_err_generic.et are a concern, as that table is within the negative range. Currently, it looks like none of those codes are currently generated outside of a mech.

I will add the cast as suggested, with a commit message note that it doesn't change anything in practice.

# Fri Apr 11 16:50:32 2025 ghudson@mit.edu (Greg Hudson) - Comments added

Download (untitled) / with headers
text/html 874B

I check the com_err implementations of error_message(), and the in-tree com_err has masked the incoming error code since 1997 (commit 1eda083efe0b1c9f8db5c559651dbab9ae09faa2), allowing positive values between 2^31 and 2^32-1 to be decoded as if the corresponding negative value had been passed. The e2fsprogs com_err started masking incoming error codes in 2007 (commit 6b6c27fb8a45f264194d8dd637643d8b4898271a), shortly after this bug report.

So, it shouldn't be necessary to add a cast to the g_display_com_err_status() call to error_message(), as that is now handled internally. I will close this ticket with no changes.

As aside note, SPNEGO also calls error_message() with an uncasted OM_uint32 value, so if we do ever decide to add a cast to g_display_com_err_status(), we should add one there as well.

# Fri Apr 11 16:50:32 2025 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'resolved'

# Fri Apr 11 16:51:03 2025 ghudson@mit.edu (Greg Hudson) - Tags nochange added