The POSIX fuzzing platform hard-codes MAILBOX_HOSTBOX_SIZE to 1024
bytes, which is smaller than the IPC4 maximum message size
(SOF_IPC_MSG_MAX_SIZE = 0x1000 = 4096 bytes). This is too small to
hold the full IPC4 message envelope and blocks the harness from
populating the hostbox with realistic fuzz payload for IPC4 paths
that read from MAILBOX_HOSTBOX_BASE.

It is also a latent overflow: ipc_platform_do_cmd() in posix/ipc.c
calls memcpy(posix_hostbox, comp_data, SOF_IPC_MSG_MAX_SIZE) on the
IPC3 path. Today this is safe only because IPC3 SOF_IPC_MSG_MAX_SIZE
is 384, but any Kconfig change that grows that value would write past
the end of the 1024-byte posix_hostbox array.

Derive MAILBOX_HOSTBOX_SIZE from SOF_IPC_MSG_MAX_SIZE so the storage
always matches the maximum framed message. The posix_hostbox array
declaration in posix.c is sized via the same macro and tracks
automatically.

No behaviour change for existing IPC3 flows. Prepares the harness for
a follow-up commit that copies IPC4 fuzz payload into the hostbox so
large_config / set_dx / pipeline-state-data handlers see meaningful
input.

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

On every other SOF platform, MAILBOX_HOSTBOX_BASE, MAILBOX_DSPBOX_BASE,
MAILBOX_STREAM_BASE and MAILBOX_TRACE_BASE expand to a byte address
(an integer literal or SRAM_INBOX_BASE), so the generic mailbox API in
sof/src/include/sof/lib/mailbox.h can do plain byte arithmetic --
`MAILBOX_HOSTBOX_BASE + offset` and `memcpy(_s)(..., bytes)` -- and
land on the intended byte.

On POSIX, the bases were defined as `(&posix_hostbox[0])` etc., i.e.
plain `uint32_t *` expressions.  Pointer arithmetic on a `uint32_t *`
scales the addend by `sizeof(uint32_t) == 4`, so
`MAILBOX_HOSTBOX_BASE + offset` silently addressed byte
`offset * 4`, four times further into the buffer than the API
contract.

This was latent for years because MAILBOX_HOSTBOX_SIZE was hard-coded
to 1024 on POSIX while the largest byte offset used through
mailbox_hostbox_read() in IPC3 mailbox_validate() (offset = 8, bytes =
SOF_IPC_MSG_MAX_SIZE - 8 = 376) stays within 32 + 376 = 408 bytes,
comfortably under 1024.  After commit "fuzz: posix: size MAILBOX_HOSTBOX
from SOF_IPC_MSG_MAX_SIZE" (384 in IPC3 builds, 4096 in IPC4 builds),
the scaled IPC3 read overruns the now exactly right-sized backing buffer
by 24 bytes, which AddressSanitizer catches as a global-buffer-overflow
inside libc memcpy called from mailbox_hostbox_read() -> memcpy_s().
Reproducer (with the new 2-byte framing): two-byte fuzz input "\x80\x01"
(msgsz=384, header-only message).

Cast each base to `(uint8_t *)` so byte-offset arithmetic is honoured
and the macro semantics match every other platform.  The `uint32_t[]`
backing storage is kept for natural alignment; only how the macro
exposes that storage changes.

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

ipc4_create_pipeline_payload_decode() reads pipeline extension
objects out of the hostbox region.  The function already validates
that `size = hdr->payload_words * 4` is at least `sizeof(*hdr)`, but
the symmetric upper bound check against MAILBOX_HOSTBOX_SIZE was
emitting tr_err() and continuing.  Once the loop is entered, every
per-object bounds check at lines 290 and 299 is expressed relative to
the attacker-controlled `size`, so a payload header that claims
`payload_words` significantly larger than the mailbox lets the decoder
walk `obj` arbitrarily far past the end of MAILBOX_HOSTBOX_BASE while
dereferencing `obj->object_words` and `obj->object_id`.

This was unreachable on real hardware because the host kernel is
trusted to bound the payload, and unreachable in the SOF fuzz harness
until commit "fuzz: posix: mirror IPC4 payload into MAILBOX_HOSTBOX"
wired the fuzz-controlled bytes into the hostbox. A 60 s libFuzzer/ASan
campaign with the IPC4 dictionary then surfaced a reproducible
global-buffer-overflow at helper.c:298 (READ of size 4 at `posix_hostbox
+ 4096`).

Convert the existing warning into a hard rejection so the decoder
returns -EINVAL before entering the object-walk loop.

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

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>