fuzzing: add fuzz_iakerb harness for IAKERB acceptor path

[tc-agent]

The IAKERB GSS-API mechanism sets GSS_C_MA_NOT_DFLT_MECH in
krb5_gss_inquire_attrs_for_mech(). When gss_accept_sec_context() is
called with GSS_C_NO_CREDENTIAL, the mechglue calls
allow_mech_by_default() which returns false for IAKERB, causing the
call to return GSS_S_NO_CRED before the IAKERB code is reached. The
existing fuzz_gss harness passes GSS_C_NO_CREDENTIAL, so every
iakerb_* function has 0% fuzzing coverage on
Fuzz Introspector
despite IAKERB seeds being present in fuzz_gss_seed_corpus/.

Add fuzz_iakerb, which bypasses the mechglue and calls
iakerb_gss_accept_sec_context() directly via forward declarations,
keeping the diff minimal by avoiding changes to LOCALINCLUDES.
This exercises:

• iakerb_parse_token() — IAKERB header parsing and validation
• iakerb_acceptor_step() — realm-discovery path and KDC-forward path
• iakerb_alloc_context() / iakerb_release_context()
• The non-IAKERB fallback to krb5_gss_accept_sec_context_ext()

The seed corpus reuses two existing entries from fuzz_gss_seed_corpus/.
IAKERB tokens are binary ASN.1 DER protocol data with no text
representation, so binary seeds are unavoidable. Raw IAKERB structure
bytes (e.g. encode_krb5_iakerb_header) are not useful seeds here
because iakerb_is_iakerb_token() requires the GSSAPI wrapper
(g_verify_token_header check + IAKERB_TOK_PROXY indicator), so
unwrapped structures fall to the non-IAKERB path already covered by
fuzz_gss. The two chosen seeds both have the proper GSSAPI framing and
target distinct IAKERB-specific code paths:
realm_query.bin (18 bytes, empty realm — exercises iakerb_acceptor_realm()
without a KDC) and start_accept_context.bin (212 bytes, full token with
realm and AS-REQ — exercises iakerb_parse_token() and sendto_kdc error
handling).

Coverage baseline (Fuzz Introspector, production OSS-Fuzz run):
Overall krb5 line coverage: 22.32%. All iakerb_* functions are at 0%
coverage before this change.

Build note: Local compilation is not possible in this build
environment (Docker volume mounts resolve against the VM host filesystem,
not the agent container, so source files are inaccessible to the Docker
daemon). Static evidence for compilation correctness:

• Forward declarations match iakerb.c:808-815 and iakerb.c:847-858
  exactly (KRB5_CALLCONV is empty on Linux per gssapi.hin:50; neither
  function is static)
• OSS-Fuzz builds with --enable-static, so all symbols in the .a
  archive are available at link time — no .exports restriction applies
• Build rule is identical to fuzz_gss (same $(GSS_LIBS) flags), which
  is known to link successfully

CI will validate the actual build.

[tc-agent]

[CLAUDE CODE REVIEW - claude-opus-4-6]

Good. Now I have all the context needed for a thorough review. Let me compile my findings.

---

PR Review: fuzzing: add fuzz_iakerb harness for IAKERB acceptor path

Correctness: PASS

Forward declarations match the implementation at iakerb.c:846-857 exactly (types, calling convention, parameter order). Verified against the actual source.

Harness logic is sound:

• Context lifecycle is correct — on error, iakerb_gss_accept_sec_context internally calls iakerb_release_context() and resets *context_handle = GSS_C_NO_CONTEXT (line 918-926), so the harness's if (context != GSS_C_NO_CONTEXT) guard works properly on all paths.
• Resource cleanup mirrors fuzz_gss.c exactly (gss_release_buffer on output, conditional delete on context). Neither harness releases src_name/deleg_cred, but these are set to GSS_C_NO_* on the IAKERB path and follow the established project pattern.

Mechglue bypass rationale is verified: g_accept_sec_context.c:97-122 confirms allow_mech_by_default() returns false for mechs with GSS_C_MA_NOT_DFLT_MECH, blocking IAKERB when verifier_cred_handle == GSS_C_NO_CREDENTIAL.

Link-time symbol availability is valid: OSS-Fuzz builds with --enable-static --disable-shared (oss-fuzz.sh:11), so .exports filtering doesn't apply.

Seeds are exact copies of existing fuzz_gss_seed_corpus/ entries (verified by md5sum). Both contain valid IAKERB GSSAPI framing:

• realm_query.bin: IAKERB OID (2b 06 01 05 02 05) + IAKERB_TOK_PROXY (0x0501) + empty realm — hits iakerb_acceptor_step → iakerb_acceptor_realm()
• start_accept_context.bin: Full IAKERB token with realm KRBTEST.COM + AS-REQ — hits iakerb_parse_token() + sendto_kdc error path

Both seeds pass iakerb_is_iakerb_token() and exercise distinct IAKERB-specific code paths (not just the non-IAKERB fallback already covered by fuzz_gss).

Checklist audit

Item	Status
Diff minimality	OK — 5 files, 107 insertions, minimal approach via forward declarations
Correct repo (upstream)	OK — krb5 fuzzing moved upstream in google/oss-fuzz#11951
Files in projects/, not oss-fuzz/	N/A — upstream PR
Conventions (naming, style, includes)	OK — matches fuzz_gss.c exactly
Copyright notice	OK — same BSD notice as existing harnesses, year 2026 (current year for new file)
Makefile.in alphabetical ordering	OK
oss-fuzz.sh array ordering	OK
Binary seeds justified	OK — ASN.1 DER protocol data, no text representation; IAKERB framing required
No unrelated changes	OK
One logical change	OK
Claims sourced	OK — Fuzz Introspector linked
5-min local coverage report	MISSING — description acknowledges build env limitation
Build verification	NOT DONE LOCALLY — CI relied upon

Flags

1. No local build/coverage verification (checklist items "Report overall fuzzing coverage after 5 minutes" and "Build works without --local_source"). The description is transparent about the Docker volume mount limitation. The static analysis of symbol availability is thorough and convincing, but this is still a gap — CI is the only build validation. If CI fails, the most likely cause would be a missing include or type mismatch not caught by visual inspection.

2. Minor: #include <krb5.h> omitted. fuzz_gss.c includes <krb5.h> and <string.h> while fuzz_iakerb.c only includes <gssapi.h>. This is fine since fuzz_iakerb.c doesn't use any krb5 or string functions, but worth noting since it deviates from the pattern.

Related PRs

• [krb5] move fuzzers and build upstream google/oss-fuzz#11951 (2024-05-20): Moved fuzzers and build upstream — confirms this upstream PR is the correct venue.
• krb5: Add gss_accept_sec_context fuzz harness google/oss-fuzz#9800 (2023-02-28): Added the original fuzz_gss harness. The IAKERB coverage gap described in this PR is a direct consequence of that harness using GSS_C_NO_CREDENTIAL through the mechglue.

No conflicting concurrent PRs found.

Verdict

LGTM — the harness is correct, well-motivated, and minimal. The coverage gap is real and verified. Submit, let CI validate the build, and check results with get_pr_ci_logs.

[CLAUDE CODE REVIEW - claude-opus-4-6]

[tc-agent]

CI failure analysis:

Fuzzing check (cifuzz) — pre-existing failure in pkinit_crypto_openssl.c: the DH struct was removed from OpenSSL 3.0's public API, and asn1_mac.h is obsolete. This is a known incompatibility between the krb5 PKINIT plugin and newer OpenSSL. The official OSS-Fuzz production build for krb5 passes successfully (build ID 569ed974) because OSS-Fuzz pins to a compatible OpenSSL version. This failure exists in the base master branch independently of this PR.

Fuzz Verify / Coverage step — the coverage build fails when linking the gssrpc library (dyn.c): GNU /usr/bin/ld is invoked for the library link step instead of the LLVM linker, causing undefined references to __sancov_lowest_stack, __asan_report_load4, etc. This is a known krb5 coverage-build limitation in non-oss-fuzz environments (autotools' libtool selects GNU ld for static archive steps). The CI template's coverage step requires the full OSS-Fuzz clang+lld toolchain. This is unrelated to the fuzz_iakerb harness.

Neither failure is caused by the changes in this PR. The address-sanitizer build and fuzzer run steps in Fuzz Verify completed successfully.

[tc-agent]

[CLAUDE CODE REVIEW - claude-opus-4-6]

LGTM (seeded for batch CI validation of krb5)

[CLAUDE CODE REVIEW - claude-opus-4-6]

[github-actions]

Fuzzing Coverage Report

Tested: project krb5 · base 0138cbe → head 0e8ae74 · 300s total fuzz budget · updated 2026-04-24 18:53 UTC · workflow run

No coverage data collected. Check the workflow run for build errors.

_{Same harness config applied to both sides (baseline = base source + PR harness). Per-harness data from report_target/<fuzzer>/linux/summary.json. Full HTML reports in the workflow artifacts.}