Non-exit relay on Tor 0.4.9.11 pegs CPU to 100–365%+ and RAM climbs continuously within seconds of every startup, due to a tight loop on “Service descriptor has an invalid signature length” parse errors.
**Environment:** - Tor version: 0.4.9.11 - Role: non-exit relay (ORPort 0.0.0.0:9001, ExitRelay 0, not a bridge) - OS: Debian (Raspberry Pi 4) - Service managed via systemd (tor@default.service, multi-instance)
**Steps to reproduce:** 1. Start tor@default via systemd (`systemctl start tor@default`) 2. Within seconds, CPU usage climbs rapidly — observed 99.7% almost immediately, reaching 365% within ~25 seconds, with RAM climbing from ~640MB to ~1GB+ and rising 3. `journalctl -u tor@default` shows the line `Service descriptor has an invalid signature length.Expected 86 but got 88` repeating continuously (~16 times/second, ~21,920 occurrences in one hour) 4. `systemctl stop tor@default` hangs and does not respond to SIGTERM cleanly; had to send SIGKILL manually 5. To rule out a corrupted local cache: stopped the service, moved aside cached-descriptors, cached-descriptors.new, cached-microdescs, and cached-microdescs.new (forcing a fresh fetch from the network), then restarted 6. Bug recurred identically within seconds of the fresh restart — same error, same CPU/RAM runaway — ruling out stale local data as the cause
**Impact:** This relay has been running Tor stably for a long time prior to this incident. The CPU runaway caused the host (a Raspberry Pi 4) to overheat, which also took down an unrelated service (Lyrion Music Server) sharing the same hardware. Had to power-cycle, reboot, and eventually kill -9 the tor process, since a clean systemd stop would not complete in reasonable time.
**Notes:** Since the bug reproduces identically even after a full local cache wipe and fresh network fetch, this looks like it’s triggered by a malformed/malicious descriptor currently circulating on the network that this relay’s fetch happens to reach quickly on every bootstrap — combined with what looks like a bug in Tor’s descriptor-parsing/retry logic that fails to cleanly discard the bad descriptor once and instead loops on it. Happy to provide further logs or test a patch if useful.
Thanks for the detailed report! This definitely looks like a descriptor parsing loop bug triggered by malformed network consensus/descriptor data.
Have you checked if upgrading to the latest Tor version fixes this, or is this specific to 0.4.9.11? If it persists, opening an issue on the official Tor GitLab with your trace logs would be the best next step for the dev team.