27 lines
1.7 KiB
Markdown
27 lines
1.7 KiB
Markdown
|
# 0035. Cap the length of a server line
|
||
|
|
|
||
|
|
- **Status:** Accepted
|
||
|
|
- **Area:** Network
|
||
|
|
- **Recorded:** 2026-11-03
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
`ElectrumClient.ReadLoopAsync` accumulated bytes until it found a newline, with no maximum. A malicious, misconfigured or compromised server could send an endless line and drive memory use up until the process died, which is cheap to do and fatal on Android. `SECURITY.md` treats denial of service against the indexing server as out of scope, but here it is the client that dies, and the fix is small.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
- A single JSON-RPC line is capped at `ElectrumClient.DefaultMaxLineBytes` (16 MiB), a parameter of `ConnectAsync` (`maxLineBytes`). The default is well above the largest legitimate replies: header batches (a few hundred KB), a large transaction (up to about 2 MB of hex) and the history of a very active address (a few MB).
|
||
|
|
- The check runs as the buffer grows, **before** a newline arrives, and also on complete lines, so neither an unterminated stream nor one huge terminated line is buffered past the cap (apart from what a single read delivers).
|
||
|
|
- On excess the read loop fails with `InvalidDataException`. This reuses the protocol-error path: pending requests fail with that exception, the connection is marked dead, `Disconnected(ex)` is raised and later requests fail fast.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
- One hostile server can no longer exhaust the memory of the client with an unbounded line.
|
||
|
|
- A legitimate reply larger than 16 MiB would be refused; none is expected on this chain, and the cap is a parameter.
|
||
|
|
- No new parser is introduced, so no new fuzz target.
|
||
|
|
|
||
|
|
## References
|
||
|
|
|
||
|
|
- `src/Core/Net/ElectrumClient.cs`
|
||
|
|
- `tests/PalladiumWallet.Tests/Net/ElectrumClientTests.cs`
|
||
|
|
- Related: 0009, 0034
|