mirror of
https://git.openafs.org/openafs.git
synced 2025-01-18 23:10:58 +00:00
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>
This commit is contained in:
parent
ce20f1f151
commit
816b0c7673
@ -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;
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user