masaori335 commented on code in PR #13328: URL: https://github.com/apache/trafficserver/pull/13328#discussion_r3687436487
########## src/iocore/cache/Stripe.cc: ########## @@ -170,6 +178,52 @@ Stripe::_init_directory(std::size_t directory_size, int header_size, int footer_ this->directory.footer = reinterpret_cast<StripeHeaderFooter *>(this->directory.raw_dir + footer_offset); } +// Bounds-check the trusted header/freelist fields of an in-shm directory before +// the fast-restart attach (magic/version are already checked by the caller). A +// stale-but-magic-valid segment could present out-of-range offsets that become OOB +// disk I/O. On failure the caller falls through to the disk read + recover_data(). +// +// Trust model: the shm segment is trusted to the same degree as the on-disk +// directory (same-uid, mode 0600). Stripe geometry (segments/buckets) is recomputed +// locally each run and raw_dir_size is exact-matched before attach, so this only +// validates the header cursor fields and per-segment freelist heads; it does not +// re-validate individual Dir entries -- the read path already checks Doc magic + key +// before serving, so a stale entry resolves to a miss, never served corruption. +bool +Stripe::_shm_directory_is_valid() const Review Comment: Added cache_shm_dir_invalid. ts1 fills the cache and clean-shuts-down, then shm_poke.py tampers with the stripe segment between runs: ts2 sees write_pos pushed past the end of the stripe, ts3 sees freelist[0] pushed past the segment's entry count. Each instance must attach the shm segments (the control segment is untouched, so this is specifically the per-stripe gate), log shm directory invalid for '<stripe>'; falling back to disk read not log the fast-attach line, and still serve the object out of cache (X-Cache: hit-fresh) after the disk read + recover_data(). The replay's origin response for those transactions is a 502 sentinel, so a wrongly forwarded request fails the run. Linux-only, like the other poke tests. Addressed by 80cff77c80. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
