From 816b0c76738b7e404c9384a745b58b4d90bfc30d Mon Sep 17 00:00:00 2001 From: Simon Wilkinson Date: Wed, 27 Feb 2013 10:28:05 +0000 Subject: [PATCH] Unix CM: Don't free cell, then release lock on it If afs_NewCell fails, then we can end up releasing a lock on a section of memory that we have already freed. As this only happens if the memory we're operating on is newly allocated and not yet visible to anyone else, it is safe to release the lock before starting to tidy things up. Caught by coverity (#986054) Change-Id: Ie8651c61790d57a9fd7bbbafcaf78e37b8222bae Reviewed-on: http://gerrit.openafs.org/9298 Reviewed-by: Derrick Brashear Tested-by: BuildBot Reviewed-by: Jeffrey Altman --- src/afs/afs_cell.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/afs/afs_cell.c b/src/afs/afs_cell.c index 7cf1fb45d3..10c04f6afb 100644 --- a/src/afs/afs_cell.c +++ b/src/afs/afs_cell.c @@ -1037,11 +1037,15 @@ afs_NewCell(char *acellName, afs_int32 * acellHosts, int aflags, return 0; bad: + ReleaseWriteLock(&tc->lock); + if (newc) { + /* If we're a new cell, nobody else can see us, so doing this + * after lock release is safe */ afs_osi_FreeStr(tc->cellName); afs_osi_Free(tc, sizeof(struct cell)); } - ReleaseWriteLock(&tc->lock); + ReleaseWriteLock(&afs_xcell); return code; }