Re: 4.10rc1 ipc locking bug.
From: Mike Galbraith
Date: Thu Dec 29 2016 - 22:53:38 EST
On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -------------------------------------
> trinity-c47/31138 is trying to release lock (
> [CONT START] &(&new->lock)->rlock
> [CONT START] ) at:
> [<ffffffff8136627f>] SYSC_semtimedop+0x97f/0x11d0
> but there are no more locks to release!
This?
From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Subject: [PATCH] ipc/sem.c: fix semop()/semop() locking failure
Date: Sun, 18 Dec 2016 19:38:45 +0100
Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt
The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.
This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout
With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, the call at the syscall return locks
the global spinlock.
The fix is trivial: Use the return value from sem_lock.
Reported-by: dvyukov@xxxxxxxxxx
Signed-off-by: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: dave@xxxxxxxxxxxx
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid,
}
rcu_read_lock();
- sem_lock(sma, sops, nsops);
+ locknum = sem_lock(sma, sops, nsops);
if (!ipc_valid_object(&sma->sem_perm))
goto out_unlock_free;