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

net: detect half-closed sockets before connection reuse

Public commit record

What the developer wrote

Authored by Guoqiang Liu

83/100 · Strong
net: detect half-closed sockets before connection reuse

Track peer EOF and TLS closure before reusing idle connections. Make disconnect idempotent while preserving buffered data and pending operation lifetimes. Add loopback coverage for EOF, socket modes, and TLS shutdown behavior.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This patch fixes a connection-reuse bug in Monero's networking helper. Previously, the client could reuse a TCP connection that the peer had already half-closed (for example, after sending data and shutting down its send side). That could lead to sending new requests over a dead connection, reading stale or truncated data, or reusing a TLS session after the peer sent a close alert. The change makes the client check for peer EOF and TLS close-notify before declaring a connection reusable, and makes disconnect safe to call multiple times without crashing or corrupting buffered data.

Recommended action

Review and merge promptly; this is a correctness fix for connection state handling that can prevent protocol desynchronization and data corruption. Run the new unit tests (especially blocked_mode_client_ssl parameterized tests) on both TLS 1.2 and TLS 1.3 builds. Consider backporting to release branches because the bug affects any long-lived or pooled connection.

Security signals we found

01

Half-closed / EOF socket reuse

02

TLS close_notify not checked before connection reuse

03

Idempotent disconnect to avoid repeated TLS shutdown / exceptions

04

Preservation of buffered data across status probes

05

Potential request/response desynchronization or data truncation

Risk score

Why this scored 63/100

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