Avoid re-locking reused UTXO futures#4673
Conversation
UtxoLookup implementations may cache and return the same async future for repeated requests for a short channel id. When a replacement channel announcement arrived for an in-flight lookup, the async path held the future state while comparing the existing pending entry, which could point to that same state. Drop the state guard before checking or replacing the pending entry so repeated lookups can update the pending announcement without re-entering the mutex. Co-Authored-By: HAL 9000 This finding was discovered by Project Loupe
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
|
No issues found. I reviewed the full diff. The deadlock fix in The fix is safe with respect to concurrency:
The added regression test is valid (both announcements share SCID 0 and the same on-chain bitcoin keys, so the replacement resolves successfully). |
UtxoLookup implementations may cache and return the same async future for repeated requests for a short channel id. When a replacement channel announcement arrived for an in-flight lookup, the async path held the future state while comparing the existing pending entry, which could point to that same state.
Drop the state guard before checking or replacing the pending entry so repeated lookups can update the pending announcement without re-entering the mutex.
Co-Authored-By: HAL 9000
This finding was discovered by Project Loupe