VNX-764: Lock acquired again while it is already held

Reports a Go mutex or Java lock acquired a second time in the same or a nested block while the first acquisition is still held: Go Lock/RLock twice (deadlock), Java ReentrantLock lock() twice and read-to-write lock upgrade.

Field	Value
Rule ID	`VNX-764`
Severity	Low
SARIF level	`note`
Kind	`sast`
Languages	Java, Go
CWE	CWE-764
CAPEC	CAPEC-66
ATT&CK	T1190
CWSS vector	`CWSS:1.0/TI:L/AP:RU/AL:S/IC:N/FC:LT/RP:RU/RL:S/AV:L/AS:N/IN:A/SC:A/BI:L/DI:H/EX:L/EC:N/P:L`
Tags	`concurrency` `lock` `multiple-lock-same-resource` `cwe-764`
Source	`internal/sast/rules/vnx-764.rego`

Overview

VNX-764 maps to CWE-764: Multiple Locks of a Critical Resource. It reports a second acquisition of the same lock, in the same block or one nested inside it, with no release of that lock in between. In Go, any Lock() or RLock() after a Lock()/RLock() on the same receiver deadlocks (a deferred Unlock runs too late). In Java, lock()/lockInterruptibly() twice on a ReentrantLock leaves a hold count the single unlock() does not clear, and readLock().lock() followed by writeLock().lock() deadlocks.

It does not report acquisitions with a release in between, sibling if/else branches, acquisitions inside a goroutine, lambda or anonymous class, different locks, tryLock(), Java write-to-read downgrade, or test files. Locks reached through a helper call are not followed.

Why This Matters

A non-reentrant lock taken twice by the same goroutine never returns. A reentrant lock taken twice and released once stays held after the method returns, so every other thread blocks forever.

What Gets Flagged

s.mu.RLock()
v, ok := s.m[k]
if !ok {
    s.mu.Lock()        // flagged: RWMutex cannot be upgraded

rw.readLock().lock();
try {
    if (v == null) {
        rw.writeLock().lock();   // flagged

Remediation

Release the lock before taking it again, or restructure so the critical section takes it once.
For read-then-write, release the read lock, take the write lock and re-check the condition.

References

Suppressing this rule

Put a nosec comment on the line, or on line 1 to cover the whole file. Use the comment marker of the file’s language (#, //, -- or ;):

# nosec vnx-764
// nosec vnx-764

Or record an ignore rule: vulnetix ignore add --rule vnx-764 --reason "...". See Suppressing findings.