ipc4: handler: bounds-check multi-pipeline SET_PIPELINE_STATE count

For multi_ppl=1, ipc4_set_pipeline_state() takes pipelines_count
straight from the host mailbox and uses it as the ppl_id[] loop
bound, with no validation against the mailbox size.

The IPC4 fuzzer reached this path with a 6-byte input that decodes
to type=SOF_IPC4_GLB_SET_PIPELINE_STATE, multi_ppl=1 and a count
field that easily exceeds MAILBOX_HOSTBOX. Once an earlier testcase
had created a matching pipeline, the ppl_id[i] read walked past the
end of the hostbox and AddressSanitizer reported a heap-buffer
overflow.

Cap pipelines_count at what the hostbox can actually hold and reject
oversized requests with IPC4_ERROR_INVALID_PARAM, logging the offending
count via ipc_cmd_err() for parity with the surrounding handlers.

Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>

Author: tmleman

src/ipc/ipc4/handler-user.c

@@ -441,6 +441,21 @@ static int ipc4_set_pipeline_state(struct ipc4_message_request *ipc4)
 
 	if (state.extension.r.multi_ppl) {
 		ppl_count = ppl_data->pipelines_count;
+		/*
+		 * pipelines_count is read straight from the host-provided
+		 * mailbox payload, so cap it at what the mailbox can
+		 * physically hold. Anything larger means the host promised
+		 * more ppl_id[] entries than fit in MAILBOX_HOSTBOX, and
+		 * dereferencing the flex array would read out of bounds.
+		 */
+		if (ppl_count > (MAILBOX_HOSTBOX_SIZE -
+				 sizeof(struct ipc4_pipeline_set_state_data)) /
+				sizeof(uint32_t)) {
+			ipc_cmd_err(&ipc_tr,
+				    "ipc: pipelines_count %u exceeds mailbox bound",
+				    ppl_count);
+			return IPC4_ERROR_INVALID_PARAM;
+		}
 		ppl_id = ppl_data->ppl_id;
 		dcache_invalidate_region((__sparse_force void __sparse_cache *)ppl_id,
 					 sizeof(int) * ppl_count);