QKeyDB durability reader can be tricked into emitting phantom entries after corruption
Replay silently produces phantom entries past a corruption point instead of halting, following a corrupted 4-byte length prefix
QKeyDB's durability log reader lacked a pre-flight sanity check comparing a decoded frame length against the remaining file size before trusting it. A single corrupted length-prefix byte could cause the reader to decode an implausible multi-gigabyte length on a much smaller file, triggering a 64 KiB resync scan that could skip past the actual corruption point and silently emit phantom (fabricated) entries into replay state instead of halting.
Root Cause
Frame length values decoded from a durability log were used directly without first validating them against basic physical bounds (decoded length must not exceed the remaining bytes in the file, and must be a sane, positive, bounded size).
Solution Steps
- Add a pre-flight bounds check on every decoded frame length: reject if position + totalEntryLength exceeds the file size, or if the length is non-positive or exceeds a sane maximum frame size, or if expected footer/CRC bytes are missing.
- On a failed bounds check, attempt a bounded 64 KiB resync scan for the next plausible frame boundary; if no valid boundary is found, truncate the corrupt tail rather than continuing to read and emit phantom entries.
- Run the tail-repair test covering exactly this corruption-then-truncate path.
Validation
[object Object]
Rollback
[object Object]
Ecosystem: qkeydb
License: CC-BY-4.0
Last updated: Jul 6, 2026