# Deadlock (CWE-833) The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock. - Prevalence: Medium 1 language covered - Impact: High 1 high-severity rules - Prevention: Documented 1 fix examples **OWASP:** Insecure Design (A04:2021-Insecure Design) - #4 ## Description Deadlocks occur when two or more threads are each waiting for the other to release a resource. This results in all affected threads being blocked indefinitely, causing a denial of service. ## Prevention ### Key Practices - Use deadlocks, goroutine leaks, or panics ### Go Use buffered channels or separate goroutines; always close channels when done ## Warning Signs - [HIGH] Channel misuse can cause: - Deadlocks (blocking operations without receiver/sender) - Goroutine leaks (receivers waiting ## Consequences - DoS ## Mitigations - Acquire locks in a consistent order across all threads - Use timeout-based lock acquisition - Use higher-level concurrency constructs that prevent deadlocks ## Detection - Total rules: 1 - Languages: go ## Rules by Language ### Go (1 rules) - **Channel Misuse** [HIGH]: Improper channel usage can cause deadlocks, goroutine leaks, or panics. Common issues include send/receive on unbuffered channel in same goroutine, not closing channels, and sending on closed channels. - Remediation: 1. Use buffered channels when sender/receiver in same goroutine: ```go ch := make(chan int, 1) // Buffered ch <- 42 val := <-ch ``` 2. Always close channels when done sending: ```go go func() { defer close(ch) // Prevents goroutine leaks for _, item := range items { ch <- item } }() ``` 3. Use select with timeout/context for network operations: ```go select { case result := <-resultCh: handle(result) case <-ctx.Done(): return ctx.Err() case <-time.After(5 * time.Second): return errors.New("timeout") } ``` 4. Never send on closed channel: ```go // Use sync primitives to coordinate close var once sync.Once closeCh := func() { once.Do(func() { close(ch) }) } ```