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

Truncate logged peer message strings

Public commit record

What the developer wrote

Authored by Elias Rohrer

68/100 · Adequate
Truncate logged peer message strings

Counterparty-provided strings in network messages (Error, Warning,
TxAbort) were logged without length limits, allowing a malicious peer
to bloat log files. Some logging sites also lacked the same
sanitization used for other untrusted strings.

Add a `DebugMsg` struct and `log_msg!` macro that consistently
truncate messages to 512 characters while preserving `PrintableString`
sanitization. Replace all bare `msg.data` and ad hoc
`PrintableString(&msg.data)` usages at the 7 relevant logging sites
in `peer_handler.rs` and `channel.rs`.

Co-Authored-By: HAL 9000
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a minor denial-of-service issue where a malicious peer could send very long text strings inside Lightning network messages (errors, warnings, transaction aborts). Those strings were written to log files without any length limit or consistent cleanup, so an attacker could fill up disk space or make logs hard to read. The patch caps logged peer message strings at 512 characters and applies the project's usual untrusted-string sanitization everywhere these messages are logged.

Recommended action

Treat as a low-severity hardening fix. Users running nodes that log peer messages should update to avoid unbounded log growth from malicious peers. No immediate emergency response is warranted because the issue is limited to log bloat and does not compromise funds, keys, or consensus safety.

Security signals we found

01

Counterparty-controlled strings logged without length limits

02

Inconsistent sanitization across logging sites for untrusted peer data

03

Potential log-file bloat / disk-filling from malicious peer messages

04

New centralized helper (`DebugMsg`/`log_msg!`) enforces 512-character cap and `PrintableString` cleanup

05

No memory-safety or cryptographic bug; this is a logging hardening fix

Risk score

Why this scored 52/100

Our methodology →
Potential impact 8/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.