Correct HashMap preallocation amount copy/paste typo
What changed, and why it matters
This commit fixes a copy/paste typo in a deserialization routine. The code was preallocating a HashMap using the wrong length variable, which could cause either excessive memory allocation or insufficient preallocation when loading on-chain transaction data. The actual loop that reads entries still uses the correct length, so the functional behavior is mostly unchanged, but the preallocation amount could be manipulated by an attacker crafting input data.
Treat as a low-severity hardening fix. The commit should be backported to supported branches because it corrects a resource allocation decision based on untrusted input. Review nearby deserialization code for similar copy/paste typos.
Security signals we found
Deserialization of attacker-controlled length field
HashMap capacity preallocation based on deserialized length
Use of wrong variable in allocation size calculation (copy/paste typo)
Memory allocation bound by MAX_ALLOC_SIZE / 128
Evidence from the diff
In lightning/src/chain/onchaintx.rs, the deserialization code reads claimable_outpoints_len but previously preallocated claimable_outpoints using pending_claim_requests_len (a different variable likely copied from nearby code). The fix uses claimable_outpoints_len for the capacity calculation. The subsequent read loop still iterates claimable_outpoints_len times, so the number of inserted entries is correct. However, the preallocation amount is derived from a deserialized length and bounded only by MAX_ALLOC_SIZE / 128, so using the wrong length could lead to allocating up to the maximum allowed capacity even when far fewer entries are expected, or under-allocating when many entries are expected.
Changed components
lightning/src/chain/onchaintx.rsOnchainTx deserialization (ReadableArgs impl)Inspect captured patch +1 / −1
diff --git a/lightning/src/chain/onchaintx.rs b/lightning/src/chain/onchaintx.rs
index 3eb6d64..75a4e19 100644
--- a/lightning/src/chain/onchaintx.rs
+++ b/lightning/src/chain/onchaintx.rs
@@ -413,7 +413,7 @@ impl<'a, 'b, ES: EntropySource, SP: SignerProvider> ReadableArgs<(&'a ES, &'b SP
}
let claimable_outpoints_len: u64 = Readable::read(reader)?;
- let mut claimable_outpoints = hash_map_with_capacity(cmp::min(pending_claim_requests_len as usize, MAX_ALLOC_SIZE / 128));
+ let mut claimable_outpoints = hash_map_with_capacity(cmp::min(claimable_outpoints_len as usize, MAX_ALLOC_SIZE / 128));
for _ in 0..claimable_outpoints_len {
let outpoint = Readable::read(reader)?;
let ancestor_claim_txid = Readable::read(reader)?;
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.