On Tue, 16 Feb 2021, Damien Miller wrote: > On Mon, 15 Feb 2021, Ed Maste wrote: > > > From the login_getcapstr man page, > > > Note that with all functions in this group, you should not call free(3) > > > on any pointers returned. Memory allocated during retrieval or > > > processing of capability tags is automatically reused by subsequent calls > > > to functions in this group, or deallocated on calling login_close(). > > This seems to be a divergence between FreeBSD and OpenBSD. OpenBSD has > > > CAVEATS > > The string returned by login_getcapstr() is allocated via > > malloc(3) when the specified capability is present and thus > > it is the responsibility of the caller to free() this space. > > However, if the capability was not found or an error > > occurred and def or err (whichever is relevant) are non-NULL > > the returned value is simply what was passed in to > > login_getcapstr(). Therefore it is not possible to blindly > > free() the return value without first checking it against > > def and err. > > NetBSD is idential to OpenBSD. I guess we'll need to special-case FreeBSD > and anything else that derives from that codebase. Does anyone know what > else does it the FreeBSD way? (I'm guessing Dragonfly...) actually, this is in the child process so the leak doesn't matter here. I think this fix is fine. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev