A couple of callers in rxgk_token.c call xdr_destroy(&xdrs) in a
cleanup code path; at present the code is fine because we are careful to
only jump to the cleanup path from a state where the xdrs are initialized,
but this is needlessly fragile (and is an undocumented requirement of the
code). Since xdr_destroy() unconditionally looks at xdrs.x_ops->x_destroy,
this could cause a NULL dereference if an error is encountered in a future
version where the 'xdrs' may be zeroed when the cleanup path runs.
Change-Id: I23c1bd09c88238bc602cc92572df4cd2278c69c9
Reviewed-on: https://gerrit.openafs.org/13521
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
ret = 0;
done:
- xdr_destroy(&xdrs);
+ if (xdrs.x_ops) {
+ xdr_destroy(&xdrs);
+ }
return ret;
}
ret = 0;
done:
- xdr_destroy(&xdrs);
+ if (xdrs.x_ops) {
+ xdr_destroy(&xdrs);
+ }
return ret;
}