Unix CM: Don't free cell, then release lock on it
authorSimon Wilkinson <sxw@your-file-system.com>
Wed, 27 Feb 2013 10:28:05 +0000 (10:28 +0000)
committerJeffrey Altman <jaltman@your-file-system.com>
Wed, 27 Feb 2013 20:44:34 +0000 (12:44 -0800)
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>

src/afs/afs_cell.c

index 7cf1fb4..10c04f6 100644 (file)
@@ -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;
 }