[Kartikey1306]

Update: #144 has merged, so this now applies directly to master — there is no longer a parent to merge first. The stacking note below predates that.

Closes #170

Stacked on #144; review 9569226..e72cf77 for this change alone — one commit, three files (+186/−6). #144 repairs master, which does not compile today, so this sits on it rather than on master. It is independent of the rest of the eos stack and can land in any order among them; merge order is #144, then this.

The defect

core/src/scheduler.c:38-56 used snprintf()'s return value as the next write offset. That return is the length it would have written, and the loop guard is checked only before an iteration, so one truncating append leaves len past the end of input[2048]. The hash append then evaluates input + len — a pointer past the end — and sizeof(input) - len, which underflows size_t.

Uniform options never expose it: they either all fit, or the guard stops the loop while room remains. It takes appends that walk len up near the 1920 guard and then one option too large for what is left:

9 options of ":key=value" = 200 bytes -> len = 21 + 1800 = 1821  (< 1920, loop continues)
1 maximal option          = 640 bytes -> 227 bytes left, truncates, but len += 640

len = 2461 into a 2048-byte buffer -> writes 413 bytes past the end,
                                      size argument 2048-2461 = 1.8e19

Those widths are what the config parser already accepts (config.c:329-330: 127-char keys, 511-char values, up to EOS_MAX_OPTIONS = 32), and this runs on every eos build (scheduler.c:105, :185).

The change

core/src/scheduler.c, +40/−6. Appends go through append_clamped(), which clamps to what is actually in the buffer and can never return an offset past the end.

Room for the content hash is reserved up front. The old len < sizeof(input) - 128 guard was reaching for exactly this and did not hold. It matters beyond tidiness: when options crowd the hash out, two packages built from different sources produce the same cache key, and the build reuses the wrong artifact. Reserving makes the hash always present.

Tests

tests/test_scheduler_cache_key.c (new, +146) includes core/src/scheduler.c to reach the static — the same technique test_ed25519_canonical_s.c uses on ed25519_verify.c, and the CMake comment says so. Four cases: the overflowing shape, the reserve boundary, every option count 0..31, and the no-hash path.

The tests assert on the deterministic consequence, not on the sanitizer — a cache-key collision — so they discriminate on an ordinary build:

against the ORIGINAL scheduler.c, plain Debug:
  test_hash_still_separates_packages_when_options_overflow  [FAIL]
      scheduler.c:105: strcmp(key_a, key_b) != 0        <- keys collided
  exit=1

against the ORIGINAL scheduler.c, -fsanitize=address:
  ==39439==ERROR: AddressSanitizer: SEGV on unknown address 0x313131314129
      #1 compute_cache_key scheduler.c:56
  SUMMARY: AddressSanitizer: SEGV scheduler.c:56 in compute_cache_key

against this branch:
  4/4 tests passed; ASan exit 0, 0 findings

My first version of this test used uniform 640-byte options and passed against the unfixed code — it never made an append truncate. It is rewritten to the shape above; the arithmetic is in the file's header comment so the next reader does not have to rediscover which shape reaches the bug.

Verified at e72cf77, gcc/Ninja/Debug, -DEOS_BUILD_TESTS=ON -DEOS_PRODUCT=vbox_test: ctest --no-tests=error --timeout 120 44/44 passed (43 before, plus this one).

Not run here: the Windows/MSVC leg and the ARM cross build — macOS/arm64 only, and CI covers both. Nothing in this change is platform-specific; append_clamped() uses only snprintf and size_t arithmetic.

[srpatcha]

Reviewed. Approve: the hash space is reserved exactly, and the test fails on master (keys collide) and passes here. Nit: options beyond the 2048-byte buffer are still dropped from the key, so two packages that differ only past that point share a cache key. Hashing incrementally would remove that.