Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Subject: Change in behaviour in gss_release_buffer() by mechtypes
    introduces memory leak
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1217

While running the dejagnu test suite gssftp w/ valgrind - when using the
aes keytypes - a memory leak is introduced by the gss_unseal() - in
particular k5sealv3.c line 399...

Internally - memory is allocated for the output message - and the length
filled in later.  If message_buffer->length results in 0 (about line
425) - things get interesting...

The caller uses gss_release_buffer to free memory returned.
Before the mechglue layer - generic/rel_buffer.c would test only if 
buffer->value was set - and if so - free the memory and set the length to 0.

In mechglue/g_rel_buffer.c both the buffer->length and value are tested.

The problem: Memory may be allocated in k5sealv3 which will not be freed.

The fundamental question is - if the length field is == 0 - could memory
have been allocated? If so - it should be freed by gss_release_buffer. 
If not - then k5sealv3.c should be changed accordingly.

My reading of RFC2744 does not make it clear  - but from the RFC 3.2:
 "[the buffer] ...which consists of a length field that contains the
total number of bytes in the datum,..."

Which seems to imply that the length contains the bytes in the datum -
but does not indicate if 0 means no allocation...

Ezra