tools: ctl: bound csv data write against abi header size

[jmestwa-coder]

ascii csv input in read_setup() overflows the tlv buffer with -r:

• with -r (no_abi) the data write index starts past the 32-byte sof_abi_hdr
• the per-value guard still checks n < n_max, where n_max is the unpadded ctrl_size
• the binary branch reads only n_max - abi_size, the csv branch does not match it
• a csv file with ctrl_size/4 values writes sizeof(struct sof_abi_hdr) bytes past the heap buffer

Bounded the csv write with n < n_max - abi_size like the binary branch.

[sofci]

Can one of the admins verify this patch?

reply test this please to run this test once

[lyakh]

that loop could benefit from some clarity improvements - mixing size in bytes and index into a 32-bit array makes it a bit hard to follow

[lyakh]

is alignment guaranteed? E.g. if the buffer size is initialised from the file size in like

sof/tools/ctl/ctl.c

Line 368 in a36b4c7

ctrl_size = get_file_size(ctl_data->in_fd);

it isn't guaranteed to be a multiple of 4? We're about to write 4 bytes to the buffer. Maybe either align it up to 4 bytes when allocating or change the check here to n <= n_max - abi_size - sizeof(uint32_t)?

[jmestwa-coder]

good catch, alignment isn't guaranteed and that's an overflow on its own. with ctrl_size = 257 the old bound let the last store write 3 bytes past the 265-byte buffer.

• went with counting values rather than n <= n_max - abi_size - sizeof(uint32_t), because sizeof makes the rhs size_t, so a bytes control with count < 36 wraps it to a huge unsigned and the guard always passes
• the loop now walks a uint32_t index bounded by val_max = (n_max - abi_size) / sizeof(uint32_t), which floors off the unaligned tail
• n is computed once after the loop instead of being carried alongside the index

that also drops the bytes vs u32 index mixing you pointed at. the binary branch already lands exactly on the buffer end, so it's unchanged. pushed.