saml_binding_post_parse leaks the base64-decoded response buffer on every parse

[shreemaan-abhishek]

Summary

saml_binding_post_parse leaks the base64-decoded response buffer on every parse. The buffer is decoded, handed to xmlReadMemory (which copies into the libxml2 document), and never freed on the success path.

Where

src/binding.c, saml_binding_post_parse (current main, 7d88f4e):

• saml_base64_decode (src/codecs.c:64) allocates decoded.
• xmlReadMemory((char*)decoded, decoded_len, ...) copies the bytes into the document.
• The function then returns SAML_OK (and the DTD / schema-validation early returns) without free(decoded). The only free(decoded) is on the base64-decode failure path.

Impact

One heap buffer the size of the decoded SAML response leaks per POST callback. Under AddressSanitizer/LeakSanitizer, a standalone driver calling the real parse path shows ~response-sized bytes leaked per parse (measured ~2.7 KB per ~2.7 KB response; scales linearly with the number of parses). Because the callback is reachable pre-authentication and the attacker controls the POST body size, this is a slow memory-exhaustion amplifier for a long-lived worker.

Reproducer

Build the C sources with -fsanitize=address and drive saml_binding_post_parse in a loop over a valid base64 SAMLResponse; LeakSanitizer reports the saml_base64_decode allocation as definitely lost, accumulating per iteration.

Note

Pre-existing (present in v0.2.5). No memory-safety fault otherwise: the same ASan/UBSan run over a malicious corpus was clean apart from this leak.

Suggested fix

Free decoded on every return path of saml_binding_post_parse after xmlReadMemory has copied it (a single cleanup label, or free immediately once the document is built).