the daqd producer and some of the transmit code needs to do better parameter/input handling

corrupted data blocks could allow buffer overflows if things like the model/dcu count was bad or lengths were bad.

changed title from the daqd producer needs to do better parameter/input handling when it injests data from the shared memory buffer to the daqd producer and some of the transmit code needs to do better parameter/input handling

changed the description

mentioned in merge request !163 (merged)

In shmem_receiver.hh it looks like header.curCycle is used without being checked on line 68.

and header.cycleDataSize is used without being checked on line 89.

Starting at producer_shmem.cc:351, a number of shared memory values are used for control without being checked.

Consider a sanity check function to be applied to the block header before using each block, and another function to be applied to each dcu header individually.

I have updated the shmem receiver code to have more sanity checks, checking for a max cycle count, ensuring the cur cycle is in bounds, and checking for data overflow.

sub_recv_buffered.cc:305

cycle used to calculate destination pointer but may not be checked. Perhaps checked prior to call?

Edit: some checks are made in ingest()@recv_buffer.hh:259 but it doesn't look like header.dcuheader[0].cycle is checked.

That bit of code deals with a 'concentrated' bit of data, so it is the combined data at this point, not direct user input. The place to look at the cycle for validity is in recv_buffer.hh in the ingest method.

I've updated that method to through out out of bounds cycles and messages with invalid dcu counts.

mentioned in commit b7c857cc

mentioned in commit 434fd1fd

mentioned in commit fb8a6465

mentioned in commit 538afcb7