fix: init log msg_buf to avoid uninit read

[MarkAtwood]

Problem

In posixLogFile_Iterate (port/posix/posix_log_file.c), msg_buf is declared uninitialized:

char msg_buf[WOLFHSM_CFG_LOG_MSG_MAX];

The parse format has 6 conversions:

sscanf(line, "%llu|%31[^|]|%255[^:]:%u|%255[^|]|%255[^\n]", ...)

A log line with an empty message (TS|LEVEL|FILE:LINE|FUNC|\n) makes the final %255[^\n] scanset match zero characters, so sscanf returns 5 and msg_buf is never written. The guard is only parsed >= 5, so entry.msg_len = strlen(msg_buf) then reads uninitialized stack memory and memcpy copies that many garbage bytes into entry.msg — undefined behavior and a stale-stack information leak to the callback.

Fix

Zero-initialize msg_buf so an unpopulated message field yields an empty string; strlen returns 0 and memcpy copies nothing.

char msg_buf[WOLFHSM_CFG_LOG_MSG_MAX] = {0};

Verification

• Compiled the translation unit with WOLFHSM_CFG_LOGGING enabled (gcc, EXIT 0, posixLogFile_Iterate symbol emitted) before and after the change.
• A standalone repro of the exact parse+strlen under valgrind memcheck: the empty-message line hit "Conditional jump or move depends on uninitialised value(s) at strlen" and returned a garbage msg_len; a control line with a real message parsed cleanly (parsed=6, no error). After zero-init, the uninitialized read is gone.

Reported by static analysis (Fenrir finding 151).

[fenrir-sweep:held]

[Copilot]

Pull request overview

This PR fixes an uninitialized stack read (and potential information leak via the iterate callback) in the POSIX file logging backend’s posixLogFile_Iterate() when parsing a log line whose message field is empty.

Changes:

• Zero-initialize msg_buf so an empty MESSAGE field results in msg_len == 0 instead of strlen() reading uninitialized memory.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.