From: Simon Wilkinson <sxw@your-file-system.com>
Date: Wed, 27 Feb 2013 10:28:05 +0000 (+0000)
Subject: Unix CM: Don't free cell, then release lock on it
X-Git-Tag: upstream/1.8.0_pre1^2~1393
X-Git-Url: https://git.michaelhowe.org/gitweb/?a=commitdiff_plain;h=816b0c76738b7e404c9384a745b58b4d90bfc30d;p=packages%2Fo%2Fopenafs.git

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 <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
---

diff --git a/src/afs/afs_cell.c b/src/afs/afs_cell.c
index 7cf1fb45d..10c04f6af 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;
 }