From Newsgroup: comp.protocols.kerberos

On 9/27/25 06:17, Osipov, Michael (IN IT IN) via Kerberos wrote:

(gdb) where
#0-a 0x60000000c8a788d0:0 in get_tag () at asn1_encode.c:370
#1-a 0x60000000c8a79f70:0 in split_der () at asn1_encode.c:605

[...]

777-a-a-a-a-a-a-a-a encode_run(req, "pa_pk_as_req", "",
acc.encode_krb5_pa_pk_as_req);

I'd be interested in the stack trace going back to near this call site--specifically, which encode_krb5_*() function is called.

The reason I ask is that encode_krb5_pa_pk_as_req() should not reach split_der(). So I wonder if a different function is being executed
somehow, like encode_krb5_auth_pack().

If I'm right, then we'll have the mystery of why
acc_encode_krb5_pa_pk_as_req contains the wrong function pointer. The structure is populated by krb5int_accessor().

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 9/28/25 07:36, Osipov, Michael (IN IT IN) wrote:

Here is the full stacktrace:

[...]

#28 0x60000000c8a87c20:0 in encode_krb5_auth_pack () at
asn1_k_encode.c:1513
#29 0x4011340:0 in main () at krb5_encode_test.c:798

Okay, it's nothing so exotic as a misplaced function pointer; we're just
at a different point in main() from what we originally thought (line
798, not lines 775-778).

Walking carefully through the stack trace, I can deduce that the failure happens when trying to encode the algorithm identifier within the
paChecksum2 field of the PKAuthenticator.
ktest_make_sample_pk_authenticator() doesn't intentionally include a paChecksum2 field, but it doesn't null it either. So this is a straightforward use of uninitialized memory, obscured on other platforms because the pointer value happens to be 0 there. (And asan/valgrind
don't catch it, presumably because the memory was written to earlier
within structures of different types.)

I will open a PR.

--- Synchronet 3.21a-Linux NewsLink 1.2