The fd_mux_during_frag_fn is called after the mux has received a new frag.
/* fd_mux_during_frag_fn is called after the mux has received a new frag from an in, but before the mux has checked that it was overrun. This callback is not invoked if the mux is backpressured, as it would not try and read a frag from an in in the first place (instead, leaving it on the in mcache to backpressure the upstream producer). in_idx will be the index of the in that the frag was received from. If the producer of the frags is respecting flow control, it is safe to read frag data in any of the callbacks, but it is suggested to copy or read frag data within this callback, as if the producer does not respect flow control, the frag may be torn or corrupt due to an overrun by the reader. If the frag being read from has been overwritten while this callback is running, the frag will be ignored and the mux will not call the process function. Instead it will recover from the overrun and continue with new frags. This function cannot fail. If opt_filter is set to non-zero, it means the frag should be filtered and not passed on to downstream consumers of the mux. The ctx is a user-provided context object from when the mux tile was initialized. seq, sig, chunk, and sz are the respective fields from the mcache fragment that was received. If the producer is not respecting flow control, these may be corrupt or torn and should not be trusted, except for seq which is read atomically. */typedefvoid (fd_mux_during_frag_fn)( void* ctx, ulong in_idx, ulong seq, ulong sig, ulong chunk, ulong sz,int* opt_filter );
Specifically, the parameters seq, sig, chunk, and sz originate from the received mcache fragment. Since the producer could be compromised, these fields are considered untrusted.
Vulnerability Details
In the during_frag function of fd_store, the data passed from fd_shred is directly saved into ctx->mem.
In the subsequent after_frag code, When the value of the member variable shred_cnt within the shred34 object is set to 0, all boundary checks are bypassed.
Attention must be drawn to the fact that the matter under discussion is not synonymous with the issue delineated within report 33718.
The attack surface of this vulnerability is when an attacker has arbitrary code execution rights over fd_shred, and then launches a process to process RCE attack on fd_store. Therefore, we modify the relevant code of the fd_shred process to simulate the situation where the attacker has already obtained the ability to execute code.
The project side realized that the modified content shown by the git diff needs to be synchronized to the local environment. By executing make -j fddev and sudo fddev --no-sandbox, Owing to the arrangement of the memory layout on the heap, the proof of concept (PoC) might not precipitate a system crash; however, upon debugging, it becomes evident that a distorted instance of shred34 is being erroneously conveyed to subsequent functions for further processing.
