Fix stack buffer overflow in mavlink_log_handler logdata.txt parsing

[Copilot]

Stack buffer overflow in mavlink_log_handler.cpp when parsing logdata.txt: LogEntry.filepath (60 bytes) written with unbounded sscanf("%s", ...). Remotely exploitable via FTP - attacker creates log file with long filename, triggers crash via LOG_REQUEST_DATA.

Changes

Buffer size increase

• LogEntry.filepath: 60 → 256 bytes (LOG_FILEPATH_SIZE constant)

Bounded sscanf

// Before (vulnerable)
sscanf(line, "%" PRIu32 " %" PRIu32 " %s", &time_utc, &size_bytes, filepath)

// After (safe)
sscanf(line, "%" PRIu32 " %" PRIu32 " %" LOG_FILEPATH_SCANF_WIDTH "s", &time_utc, &size_bytes, filepath)
// where LOG_FILEPATH_SCANF_WIDTH = "255"

Compile-time safety

• static_assert(PX4_MAX_FILEPATH >= LOG_FILEPATH_SIZE) - prevents NuttX configs with insufficient path size
• static_assert(LOG_FILEPATH_SIZE == 256) - enforces synchronization with width specifier

Files Modified

• mavlink_log_handler.h: Define LOG_FILEPATH_SIZE constant, update struct
• mavlink_log_handler.cpp: Add width specifiers to both sscanf calls (lines 189, 524), add assertions

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug] Stack buffer overflow in mavlink_log_handler when parsing logdata.txt due to unbounded sscanf("%s") into LogEntry.filepath</issue_title>
<issue_description>### Describe the bug

A stack-buffer-overflow vulnerability exists in PX4’s mavlink_log_handler.cpp/.h when handling logs: LogEntry.filepath is a fixed-size buffer (~60 bytes), but logdata.txt parsing uses sscanf(..., "%s", entry->filepath) without a width limit, so an overly long filename/path token can overflow the stack and crash. In practice this is remotely triggerable via the FTP microservice: an attacker creates a log file in the log directory with an excessively long filename, then sends LOG_REQUEST_LIST (receiving LOG_ENTRY) followed by LOG_REQUEST_DATA; when the handler processes the long filename during log access/parsing, the unbounded %s write overflows LogEntry.filepath, leading to a remote denial-of-service and potentially more severe memory-corruption impact.

To Reproduce

1.armed and takeoff
3.send an FTP message to create an attack file
4.send an LOG_REQUEST_FILE and recvive LOG_ENTRY
5.send an LOG_REQUEST_DATA (poc)
6.crashed

Expected behavior

PX4-Autopilot should respond to LOG_REQUEST_LIST / LOG_REQUEST_DATA normally, and a log entry with an overly long filename should be rejected (or sanitized) instead of causing a crash.

Screenshot / Media

Flight Log

No response

Software Version

main branch

Flight controller

px4 sitl

Vehicle type

None

How are the different components wired up (including port information)

No response

Additional context

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

@farhangnaderi @MaEtUgR might know what is going on here?

• Fixes [Bug] Stack buffer overflow in mavlink_log_handler when parsing logdata.txt due to unbounded sscanf("%s") into LogEntry.filepath #26118

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.