OK, let's give the security team some context. RFC 2744 specifies some kind of unfortunate behavior for error handling.
gss_init_sec_context and gss_accept_sec_context have an in/out context parameter (pointer to pointer). You initialize the pointed to value to null the first time through. It gets set to some allocated context handle. But you'll probably call gss_init_sec_context and gss_accept_sec_context in a loop. It gets unclear what should happen if it fails after the first time. Are you supposed to call the free function or not? The fact that I can 't remember how you figure out what you should do is an indication of how obscure it is. A lot of applications screw this up and either leak or double free sometimes. I'm a little confused why double free is a big deal, because I'd think you'd end up calling gss_delete_sec_context on NULL in that case and it could just ignore a delete of null. Anyway, the upstream change forces the code to follow a SHOULD in RFC 2744 and leave it up to the caller to free the context always. The code was correct before and after this change. However, after this change more application code is expected to be correct. Code that isn't correct is likely to just leak memory. However, this is a behavior change. It's possible that if we bring this back to stable we'll find it causes some theoretically broken application to be broken in practice as well as theory. --Sam
