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

net: handle multi-part netlink responses

Public commit record

What the developer wrote

Authored by willcl-ark

80/100 · Strong
net: handle multi-part netlink responses

Handle multi-part netlink responses to prevent truncated results from
large routing tables.

Previously, we only made a single recv call, which led to incomplete
results when the kernel split the message into multiple responses (which
happens frequently with NLM_F_DUMP).

Also guard against a potential hanging issue where the code would
indefinitely wait for NLMSG_DONE for non-multi-part responses by
detecting the NLM_F_MULTI flag and only continue waiting when necessary.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes how Bitcoin Core reads network routing information from the Linux kernel. Previously, the code only made one request and could receive incomplete routing data on systems with large routing tables, or could hang waiting for a 'done' signal that never comes. The fix loops to collect all kernel response parts and only waits for the 'done' marker when the kernel says the response is multi-part. This is a reliability bug fix, not a direct money-stealing vulnerability, but incorrect routing data could affect how the node connects to peers.

Recommended action

Apply the patch. It is a low-risk correctness fix. If running a node on Linux with large routing tables, ensure the fix is included to avoid incomplete local network discovery or startup hangs.

Security signals we found

01

Incorrect routing table parsing could lead to wrong local address detection

02

Potential hang when NLMSG_DONE is not sent for non-multi-part responses

03

Fixes kernel netlink protocol handling for NLM_F_DUMP

04

No direct cryptographic, consensus, or remote-exploitable vector visible in the diff

Risk score

Why this scored 37/100

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