Bump krb5 to 1.22.3 (CVE-2026-40355, CVE-2026-40356)

[twangboy]

Summary

relenv currently builds krb5 1.22.2. Two CVEs fixed upstream in krb5 1.22.3 (unreleased) affect it. Please bump krb5 once it is published.

Affected

The Salt 3008.3, 3008.4 and 3008.5 onedirs, built with relenv, all ship krb5 1.22.2. libkrb5.so.3.3 reports KRB5_BRAND: krb5-1.22.2-final 1.22.2 20260129.

The krb5 build installs these libraries into the onedir:

• libkrb5
• libgssapi_krb5
• libk5crypto
• libkrb5support
• libverto
• libkdb5
• libkadm5*
• libgssrpc
• libkrad

Downstream security scanners (Black Duck/ArmorCode) flag these libraries.

CVEs

Both are NegoEx parsing bugs in gss_accept_sec_context(). They are only reachable when a NegoEx mechanism is registered in /etc/gss/mech. Both affect krb5 < 1.22.3 and were fixed upstream in krb5 commit 2e75f0d.

• CVE-2026-40355: NULL pointer dereference, causing a process crash (DoS).
• CVE-2026-40356: integer underflow and read overrun of up to 52 bytes, possibly causing a crash (DoS).

Neither is remote code execution. Severity is reported differently by different sources: NVD gives CVE-2026-40355 a CVSS of 5.9, and some vendors give 7.5.

Request

When krb5 1.22.3 is released:

1. Update the krb5 version in relenv's dependency pins, including the checksum.
2. Cut a relenv release.

Salt will then bump its relenv pin and ship the fix in its next release.

Interim mitigation for affected systems that don't need NegoEx: don't register a NegoEx mechanism in /etc/gss/mech.

Note on libverto

libverto.so.0.0 is built from the krb5 source tree (the krb5 build passes --without-system-verto). It has no version string of its own. Scanners misidentify it as "krb5 1.18.3", which causes false positives for older krb5 CVEs that were fixed long ago. This isn't something to fix in relenv, but it explains why scanner reports carry the wrong version.

References

• Upstream fix: krb5/krb5@2e75f0d
• https://nvd.nist.gov/vuln/detail/CVE-2026-40355

[dwoz]

Released 0.23.1

[dwoz]

Accidentally converted to discussion. This issue should be closed.