Fix OOB stack read in send_ipc_command due to misuse of snprintf return value

[craftsoldier]

Problem

snprintf(3) returns the number of bytes it would have written had the buffer been large enough — not the number actually written. In send_ipc_command, the return value is used directly as the send length:

char buf[256] = { 0 };
int packet_len = snprintf(buf, sizeof(buf), "%s:%s", ipc_cmd, ipc_arg);
return send_packet(data_fd, buf, (size_t)(packet_len + 1));  // bug

When the formatted command exceeds 255 bytes, buf is silently truncated but packet_len still holds the full would-be length. send_in_full then calls send(2) with a len larger than buf, causing an out-of-bounds read of the stack frame and sending garbage bytes (stack padding, saved registers, return address) to kfmon over the IPC socket.

The practical effect is a confusing silent failure: kfmon receives a garbled command and rejects it, with no useful error surfaced to the user.

Fix

Check for truncation (packet_len >= sizeof(buf)) and return KFMON_IPC_SEND_FAILURE early, turning the silent misbehaviour into a clear, returnable error.

int packet_len = ipc_arg
    ? snprintf(buf, sizeof(buf), "%s:%s", ipc_cmd, ipc_arg)
    : snprintf(buf, sizeof(buf), "%s", ipc_cmd);
if (packet_len < 0 || (size_t) packet_len >= sizeof(buf)) {
    return KFMON_IPC_SEND_FAILURE;
}

[NiLuJe]

Did a bit of archeology, best as I can think, I probably recycled that from KFMon code itself, which can afford to skip the overflow check, because it only deals with either string literals, or known fixed-length buffers that are much smaller than the chosen buffer size (which also happens to be 4K in KFMon).

TL;DR: Yeah, definitely a boo-boo ;).

[NiLuJe]

LGTM, thanks!