CVE-2026-56968

An attacker-controlled NTLM server sends a Type-2 (challenge) message shorter than the expected 1076-byte `tSmbNtlmAuthChallenge` struct. The client's `_gsasl_ntlm_client_step()` function [ref_id=1] accepts any input length up to the struct size, then copies only the received bytes via `memcpy`, leaving the remainder of the heap-allocated buffer uninitialized. The struct is passed to libntlm's `buildSmbNtlmAuthResponse()`, which reads target-name and target-info fields from the uninitialized tail. Those stale heap bytes are echoed back to the attacker inside the NTLM response, achieving a remote heap memory disclosure [CWE-908].

The advisory recommends replacing `malloc()` with `calloc()` to zero-initialize the entire struct, so that a short challenge cannot expose stale heap contents [ref_id=1]. It further suggests validating that the wire-declared target-name and target-info lengths and offsets stay within `input_len` before libntlm consumes them, preventing a malicious server from pointing those fields into the zeroed (or still-stale) tail. The patch does not show the exact diff, but the fix is described as a two-part change: zero the struct and add bounds checks.