⚠️ Warning — This finding was routed to an issue rather than a PR because there is no simple, self-contained fix that is clearly safe. A correct fix requires a design decision (new bounds/config, protocol semantics, or an upstream-dependency change) and risks unintended consequences (e.g. breaking local networks, over-banning peers, blackholing valid data, or changing protocol behavior). Per the 'be very careful of unintended consequences' directive it is filed for design discussion rather than patched blindly.
Severity: medium
Component: massa-module-cache/src/controller.rs (save_module)
Summary
save_module checks hd_cache before lru_cache, even when the same module may already be
present in both. This causes unnecessary RocksDB reads and RuntimeModule::deserialize work,
followed by redundant reinsertion into lru_cache, instead of reusing the existing in-memory
entry — a resource-amplification problem.
The specific low-cost exploit narrative and the "deserialization = proven full recompilation"
characterization from the original report are overstated.
Why borderline (review before fix)
Reordering the cache-check logic is small, but save_module is on a hot path shared by
execution and module loading; changing lookup/insertion order must preserve correctness of the
LRU/HD cache coherence and eviction. Needs review to ensure no cache-consistency regression.
Suggested direction
Check the in-memory lru_cache first and short-circuit if the module is already present,
before touching hd_cache/RocksDB; add a test asserting no redundant HD read/deserialize when
the module is already in the LRU cache.
Tracking: finding F93.
Severity: medium
Component:
massa-module-cache/src/controller.rs(save_module)Summary
save_modulecheckshd_cachebeforelru_cache, even when the same module may already bepresent in both. This causes unnecessary RocksDB reads and
RuntimeModule::deserializework,followed by redundant reinsertion into
lru_cache, instead of reusing the existing in-memoryentry — a resource-amplification problem.
The specific low-cost exploit narrative and the "deserialization = proven full recompilation"
characterization from the original report are overstated.
Why borderline (review before fix)
Reordering the cache-check logic is small, but
save_moduleis on a hot path shared byexecution and module loading; changing lookup/insertion order must preserve correctness of the
LRU/HD cache coherence and eviction. Needs review to ensure no cache-consistency regression.
Suggested direction
Check the in-memory
lru_cachefirst and short-circuit if the module is already present,before touching
hd_cache/RocksDB; add a test asserting no redundant HD read/deserialize whenthe module is already in the LRU cache.
Tracking: finding F93.