common: don't trigger siphash_seed() init from span hashing either.
What the developer wrote
Authored by ShahanaFarooqui
common: don't trigger siphash_seed() init from span hashing either.
Previous commit stopped trace ids consuming the deterministic
randbytes stream, but tracing still touched it once: span_key_hash()
calls siphash_seed(), whose lazy init draws 16 bytes from the stream.
Since randbytes call sites are assigned their offset blocks in
first-use order, that single draw shifts every later draw in the
process by 1000 when tracing is active (HAVE_USDT builds, as in CI):
keysend preimages and invoicerequest payer keys then differ from a
build with tracing disabled, showing up as an 11-file doc-examples
diff.
Use a cheap multiplicative hash for span keys when the deterministic
override is active, so tracing touches the RNG stream zero times.
What changed, and why it matters
This is a small bug-fix commit in Core Lightning's tracing code. It fixes a situation where enabling tracing accidentally changed the sequence of random numbers used elsewhere in the program, causing test outputs to differ between builds with and without tracing. The change makes tracing use a simple math hash instead of a randomness-seeded hash when deterministic mode is active. There is no direct security vulnerability here; it is a determinism/reproducibility fix.
No urgent security action required. Treat as a normal correctness/reproducibility fix. Reviewers may want to verify that the multiplicative hash provides adequate distribution for the span hash table in deterministic test scenarios, and that no other tracing code paths still consume randbytes in deterministic mode.
Security signals we found
No direct memory safety issue
No input validation bypass
No authentication or authorization change
Fixes deterministic/reproducibility behavior under tracing
Avoids unintended RNG stream consumption by tracing instrumentation
Evidence from the diff
The commit modifies span_key_hash() in common/trace.c. Previously, this function called siphash24() with siphash_seed(), whose lazy initialization drew 16 bytes from the randbytes stream. In deterministic override mode, that draw shifted the offset of all subsequent randbytes consumers by 1000, causing observable differences in keysend preimages and invoicerequest payer keys between HAVE_USDT (tracing-enabled) and non-tracing builds. The patch checks randbytes_overridden() and, when active, returns a cheap multiplicative hash (key * 0x9E3779B97F4A7C15ULL) instead, ensuring tracing touches the RNG stream zero times.
Changed components
common/trace.cspan_key_hash()USDT tracing subsystemInspect captured patch +6 / −0
diff --git a/common/trace.c b/common/trace.c
index fdd6205..a3e3430 100644
--- a/common/trace.c
+++ b/common/trace.c
@@ -91,6 +91,12 @@ static size_t span_keyof(const struct span *span) { return span->key; }
static size_t span_key_hash(size_t key)
{
+ /* Tracing must never touch the RNG: siphash_seed() draws its
+ * seed from the randbytes stream on first use, and with the
+ * deterministic override active that would shift every later
+ * draw in the process (see trace_rand_u64 below). */
+ if (randbytes_overridden())
+ return key * 0x9E3779B97F4A7C15ULL;
return siphash24(siphash_seed(), &key, sizeof(key));
}
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.