[fd-mux] Handling of cross-tile shared memory may lead to OOB read

[0x0ece]

In fd_mux_tile (src/disco/mux/fd_mux.c), it appears a compromised tile could cause an out-of-bounds read in another tile (e.g. if you achieved remote code execution the quic tile, you may be able to make the verify tile read out-of-bounds memory):

ulong depth    = fd_mcache_depth( this_in->mcache ); min_in_depth = fd_ulong_min( min_in_depth, depth );  
if( FD_UNLIKELY( depth > UINT_MAX ) ) { FD_LOG_WARNING(( "in_mcache[%lu] too deep", in_idx )); return 1; }  
this_in->depth = (uint)depth;  
this_in->idx   = (uint)in_idx;  
this_in->seq   = fd_mcache_seq_query( this_in_sync ); /* FIXME: ALLOW OPTION FOR MANUAL SPECIFICATION? */  
this_in->mline = this_in->mcache + fd_mcache_line_idx( this_in->seq, this_in->depth );  

The depth variable is set from the underlying shared memory for the input workspace. Note there's a bounds check to ensure that the depth is less than UINT_MAX (4GB). The fd_mcache_line_idx function can return a value between [0,depth). Since the workspace shared memory mapping is 1GB (e.g. for fd1_quic_verify.wksp), this looks like it could result in an mline value that points out of bounds.

In certain scenarios, OOB read issues like this may lead to cross-tile information leak or other undefined behavior.