AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 42 Bitcoin

common: handle taken() extra_tlvs in new_existing_htlc properly.

Public commit record

What the developer wrote

Authored by Rusty Russell

65/100 · Adequate
common: handle taken() extra_tlvs in new_existing_htlc properly.

Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
The short version

What changed, and why it matters

This patch fixes a memory-management bug when handling extra TLV (type-length-value) data attached to Lightning Network HTLCs (payment hops). The bug involved the 'taken()' memory ownership marker: when the caller had marked the extra_tlvs array to be 'taken' (transferred), the old code would still make a full copy and deep-copy of every value buffer, which is unnecessary and could lead to use-after-free or double-free problems because the original array's value buffers were not re-parented correctly. The patch introduces a helper that checks whether the array is already 'taken' and, if so, avoids the redundant deep copy, ensuring the value buffers are attached to the correct parent object.

Recommended action

Treat as a low-to-moderate reliability/security fix. Apply the patch and run the project's memory-sanitizer/valgrind tests, especially any exercising HTLC creation with extra_tlvs. No immediate emergency response is indicated, but node operators should upgrade in due course to avoid potential memory corruption during payment forwarding.

Security signals we found

01

Memory ownership/lifetime bug in TLV array duplication

02

Incorrect handling of TAKES/taken() semantics for extra_tlvs

03

Potential use-after-free or double-free in HTLC metadata handling

04

Fix reported by project contributor Christian Decker

05

Patch is defensive/refactoring with explicit memory-ownership semantics

Risk score

Why this scored 42/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 7/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.