device: receive: drain decryption queue before exiting RoutineDecryption

It's possible for RoutineSequentialReceiver to try to lock an elem after RoutineDecryption has exited. Before this meant we didn't then unlock the elem, so the whole program deadlocked. As well, it looks like the flush code (which is now potentially unnecessary?) wasn't properly dropping the buffers for the not-already-dropped case. Signed-off-by: Jason A. Donenfeld <[email protected]>
WireGuard · Jan 7, 2021 · 29b0477 · 29b0477
1 parent 85b4950
commit 29b0477
Show file tree

Hide file tree

Showing 2 changed files with 18 additions and 2 deletions.
diff --git a/device/device.go b/device/device.go
@@ -371,7 +371,10 @@ func (device *Device) FlushPacketQueues() {
 		select {
 		case elem, ok := <-device.queue.decryption:
 			if ok {
-				elem.Drop()
+				if !elem.IsDropped() {
+					elem.Drop()
+					device.PutMessageBuffer(elem.buffer)
+				}
 			}
 		case <-device.queue.handshake:
 		default:

diff --git a/device/receive.go b/device/receive.go
@@ -251,7 +251,20 @@ func (device *Device) RoutineDecryption() {
 	for {
 		select {
 		case <-device.signals.stop:
-			return
+			for {
+				select {
+				case elem, ok := <-device.queue.decryption:
+					if ok {
+						if !elem.IsDropped() {
+							elem.Drop()
+							device.PutMessageBuffer(elem.buffer)
+						}
+						elem.Unlock()
+					}
+				default:
+					return
+				}
+			}
 
 		case elem, ok := <-device.queue.decryption: