| Subject: | gss_release_buffer() too easily deallocates memory it should not |
The GSS API provides a gss_release_buffer() function for releasing
memory associated with gss_buffer_t objects which were allocated within
the gss library. Unfortunately, half of the gss_buffer_t objects which
applications must deal with are not allocated by the gss library but
instead by the application itself. The app must read from from the
input channel and construct a gss_buffer_t object to pass into GSS
functions for processing.
The chances that an application will attempt to use gss_release_buffer()
to deallocate this memory is extremely high resulting in program crash
at best or memory corruption and unpredictable at worst.
Ken and I were discussing the situation. We believe that the problem
cannot be prevented but we can make it much more obvious to developers
that there is a problem which must be fixed.
When the gss api allocates gss_buffer_t objects it should allocate an
initial four bytes which would be set to a magic value. The pointer
returned to the application would be set to the first byte passed the
magic value. In gss_release_buffer() we would subtract four bytes from
the pointer value and verify the magic value. If the magic value does
not verify the memory was not allocated by the gss api, and therefore we
will call assert() to force the termination of the program with an error.
We should discuss if this is something we can accomplish for 1.3.2.
memory associated with gss_buffer_t objects which were allocated within
the gss library. Unfortunately, half of the gss_buffer_t objects which
applications must deal with are not allocated by the gss library but
instead by the application itself. The app must read from from the
input channel and construct a gss_buffer_t object to pass into GSS
functions for processing.
The chances that an application will attempt to use gss_release_buffer()
to deallocate this memory is extremely high resulting in program crash
at best or memory corruption and unpredictable at worst.
Ken and I were discussing the situation. We believe that the problem
cannot be prevented but we can make it much more obvious to developers
that there is a problem which must be fixed.
When the gss api allocates gss_buffer_t objects it should allocate an
initial four bytes which would be set to a magic value. The pointer
returned to the application would be set to the first byte passed the
magic value. In gss_release_buffer() we would subtract four bytes from
the pointer value and verify the magic value. If the magic value does
not verify the memory was not allocated by the gss api, and therefore we
will call assert() to force the termination of the program with an error.
We should discuss if this is something we can accomplish for 1.3.2.