From 113ede2a6b43551efe9df19774202e91730dfe11 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) Reviewed-on: http://gerrit.openafs.org/9298 Reviewed-by: Derrick Brashear Tested-by: BuildBot Reviewed-by: Jeffrey Altman (cherry picked from commit 816b0c76738b7e404c9384a745b58b4d90bfc30d) Change-Id: I7976f00431e4dc96642b45fc7563485a5087c938 Reviewed-on: http://gerrit.openafs.org/11025 Reviewed-by: Nathaniel Filardo Reviewed-by: Chas Williams - CONTRACTOR Tested-by: BuildBot Reviewed-by: Andrew Deason Reviewed-by: Stephan Wiesand --- 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 3e4259a5f..1a7296442 100644 --- a/src/afs/afs_cell.c +++ b/src/afs/afs_cell.c @@ -1016,11 +1016,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; } -- 2.39.5