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

common: set errno=0 before calling strto{l,ul,ull}

Public commit record

What the developer wrote

Authored by Matt Whitlock

78/100 · Adequate
common: set errno=0 before calling strto{l,ul,ull}

The strto{l,ul,ull} functions do not set errno upon a successful return, so a
successful return from a maximally valued input could be misinterpreted as an
overflow error if errno happened already to be set to ERANGE before the call.
To guard against this edge case, always set errno to zero before calling these
functions if checking errno afterward.

Changelog-None
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a subtle programming bug in how Core Lightning converts text strings to numbers. Functions like strtoull only set an error flag (errno) when a value is too large, but they leave it unchanged on success. If some earlier code had already set that flag to 'overflow,' a later successful conversion of the largest possible number could be wrongly rejected as an overflow. The patch clears the error flag before each conversion so the check afterward is reliable. The practical security impact is limited because the bug only triggers when a prior operation happens to leave that specific error flag set, and the affected conversions are mostly for amounts, route hints, and JSON parsing rather than cryptographic checks.

Recommended action

Treat as a low-risk correctness fix. Review whether any other strto* call sites in the codebase check errno afterward without first clearing it, and apply the same pattern consistently. No urgent security response is indicated by the diff alone.

Security signals we found

01

Defensive fix for errno misuse around strto* conversions

02

Potential false-positive overflow rejection in BOLT11 amount parsing

03

Potential false-positive overflow rejection in JSON amount and integer parsing

04

No cryptographic, memory-safety, or authorization changes

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/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.