[bug]: fixed-width node announcement address decoders accept short reads

[s1ns3nz0]

Environment

• LND version: upstream master at 88959aec3d7a9d11a509714d9bee97c29ee02269 (2026-09-18)
• Backend version: N/A
• OS/Distribution: N/A
• Configuration: N/A; this reproduces in lnwire unit tests

Bug Details & Steps to Reproduce

The IPv4, IPv6, and Tor v3 address TLV decoders use io.Reader.Read for fixed-width fields and do not verify that the requested number of bytes was returned.

A conforming reader may return (n < len(buf), nil). The decoder then interprets the unread zero-filled bytes as part of the address.

Minimal examples:

• IPv4: 5 bytes supplied for a 6-byte record
• IPv6: 17 bytes supplied for an 18-byte record
• Tor v3: tor.V3DecodedLen+1 bytes supplied for a tor.V3DecodedLen+2 record

The existing implementation accepts each input and returns an address.

Expected Behavior

A fixed-width address field should be read completely. Truncated input should return an error.

A reader that legitimately returns data in small fragments should still decode successfully when the complete record is available.

Proposed Fix

Replace the six fixed-width Read calls in lnwire/node_announcement_2.go with io.ReadFull.

The proposed change is limited to decoder correctness. It does not change the TLV format or reject any complete valid record.

Tests

Regression coverage includes:

• truncated IPv4, IPv6, and Tor v3 records are rejected;
• two complete addresses decode successfully;
• complete records decode through iotest.OneByteReader;
• focused fuzz targets continue to pass.

This is reported as a parser correctness issue. I have not confirmed a network-wide gossip impact or a separate live security exploit.

[bitromortac]

Thanks for reporting. Confirmed this and there's also another bug with multiple addresses, where the first IP addresses get overwritten by the last one. Will open a fix for both.

[s1ns3nz0]

Really thanks @bitromortac, but would you mind if I took this one? I've already written patches for it locally. I see it's assigned to you though, happy to stand down if it's already in progress.

[saubyk]

Thanks for the detailed report @s1ns3nz0. Please note our guidelines for new contributors: PRs from new contributors are not prioritized for review, so we'd recommend against opening one here. @bitromortac is assigned and will handle the fix.

If you'd like to build a track record with the project, issue triage and PR review are the best places to start. Reviewing the fix once it's up would be very welcome.

[s1ns3nz0]

Got it, thanks for the clarification!

[bitromortac]

@s1ns3nz0 thanks again. It was not clear to me that you planned to contribute a PR. I credited you as co-author on a commit in #11219, as well as in the release notes. Let me know if you don't want that.

[s1ns3nz0]

I thought this was a relatively small and straightforward patch, so I already had a working version when I opened the issue. That’s why I thought it would be more efficient to just open a PR with my patch rather than assigning the issue as a task.

And of course, I’d be honored to have my name mentioned in the PR. It’s absolutely no trouble at all, I really appreciate it!