xsi_semget: fix possible way to crash the kernel

I don't know if the behavior makes sense, but anything is better than a
kernel crash. The ticket is an example calling the syscall directly,
so there is no user-oriented guarantee on how we behave here.

Fixes #16741.

Change-Id: I803596004d005c8c0e058c5422c4b0f7c78cfad8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3623
Reviewed-by: Rene Gollent <rene@gollent.com>
This commit is contained in:
Adrien Destugues 2021-01-10 20:30:58 +01:00 committed by waddlesplash
parent 7f9c675629
commit b181ea960c

View File

@ -771,7 +771,12 @@ _user_xsi_semget(key_t key, int numberOfSemaphores, int flags)
MutexLocker _(sXsiSemaphoreSetLock);
semaphoreSet = sSemaphoreHashTable.Lookup(semaphoreSetID);
if (semaphoreSet == NULL || !semaphoreSet->HasPermission()) {
if (semaphoreSet == NULL) {
TRACE_ERROR(("xsi_semget: calling process has no semaphore, "
"key %d\n", (int)key));
return EINVAL;
}
if (!semaphoreSet->HasPermission()) {
TRACE_ERROR(("xsi_semget: calling process has no permission "
"on semaphore %d, key %d\n", semaphoreSet->ID(),
(int)key));