PX4 Study

This is a brief summary of my study regarding PX4. I’ve provided a general summary below, please credit properly if you plan to use any of this information.

Deliverable 1 — Vulnerability Survey

Introduction

PX4 is an open-source autopilot for commercial and research Unmanned Aerial vehicles (UAVs). However, because many vehicles using PX4 perform in GPS-denied environments where real-time operations are critical, the system prioritizes performance. This creates a tradeoff between performance and security, where protections such as authentication and encryption are not implemented and deemed inefficient. Because of the architecture of PX4, gaps remain exploitable within the software.

PX4 Overview

Flight Stack

A flight stack is a system controlling flight and estimation operations. It consists of control algorithms that provide navigation. Autonomous drones use the flight stack to estimate physical states (e.g. attitude, position) and to control flight.

The PX4 flight stack includes several components: a position controller, which “takes a setpoint and a measurement or estimated state… as input… [it adjusts] the value of the… [input] so that it matches the setpoint”; an estimator which calculates vehicle states from sensor data; and a mixer which “takes force commands (such as “turn right”) and translates them into individual motor commands”. These components work together to control the flight of an autonomous vehicle.

Ground Control Stations

A Ground Control Station (GCS) is used to ensure navigation of a UAV remotely. It also presents data to the operator such as flight telemetry data, status concerning flight mode and battery, and mission plan data. A mission plan is a set of instructions to instruct the UAV what path to follow during flight. This plan includes information such as speed settings, fail-safe behaviours, and waypoints. A waypoint is a set of GPS coordinates that a vehicle should fly to. Vehicle communication and telemetry is facilitated using protocols such as MAVLink and product-specific Software Development Kits (SDKs).

MAVLink

Micro Air Vehicle Link (MAVLink) uses the User Datagram Protocol (UDP) as its transport protocol, allowing up to 16 simultaneous external connections. Messages transmitted over this protocol are called MAVLink frames. Each frame is split into sections describing the payload length, sequence number and other identifications, and the payload (data) itself.

MAVLink itself is an auxiliary module included in PX4’s Autopilot source code. Some notable implementation components include:

• mavlink receiver and mavlink command sender, both used for entry points in the network
• mavlink log handler, used to print out useful logs for operators
• mavlink stream, used to update subscriptions and send messages through the protocol

NuttX

Apache NuttX is a real-time operating system (RTOS) that acts as a foundation for PX4 software to run on, following POSIX and ANSI standards. It provides interface support for multi-threaded environments.

This system handles scheduling, drivers, and even provides its own shell for running commands on a flight controller. While this software uses almost all of the sub modules of NuttX, the following modules are critical to address.

Each module within PX4 serves as its own task, and each task houses multiple threads in its environment.

Each environment has its own work queue. Work queues are queues handling network events. A high priority work queue services important tasks such as backend interrupts, whilst low priority queues handle less important tasks. In the NuttX RTOS environment, each task functions as an independent thread (process).

Attack Vectors

This section analyzes factors that directly affect PX4’s attack surface. While NuttX is an appropriate operating system for PX4, their interactions reveal security gaps when balancing the requirements of performance and system protection mechanisms.

Both drivers and modules are susceptible to memory corruption issues. Common issues include buffer overflows, no format specifiers, and use-after-free vulnerabilities.

Each vulnerability discussed within this deliverable is evaluated using the Common Vulnerability Scoring System (CVSS v3.1). This framework assigns a score to a vulnerability, from 1.0 (Low) to 10.0 (Critical). Higher scores indicate a more severe or impactful vulnerability. A Base Score represents the qualities of a vulnerability, while the Estimated Severity is the severity tied to that score.

Novel Vulnerability

Race Condition in MavlinkULog::stop() Function

Base Score: 7.5 (HIGH)

ULog is the logging format that records flight controller data. UAVs can stream live data over a MAVLink connection to a host machine. Through rapidly toggling the logger on and off using start (MAV CMD LOGGING START) and stop (MAV CMD LOGGING STOP) commands, the system alternates between creating and destroying the MavlinkULog object.

An attacker that is network-adjacent, that is, on the same UDP network as the victim, can execute this exploit.

The global static pointer instance manages the logger subsystem. When MavLinkULog is destroyed, other threads like the receiver and work queue may access it. There is a race condition between two threads:

• The thread deleting the MavLinkULog object using MavlinkUlog::stop()
• A thread handling a polled update using the handle ack function

As the instance pointer is not nullified before memory deallocation occurs, a context switch can occur immediately after the handle ack thread passes the if ( instance) check but before completing subsequent function calls. If the thread executing stop() is scheduled during this micro-window, it executes delete instance, leaving the first thread with a dangling pointer (a Use-After-Free) or a null-pointer dereference when execution is resumed.

With this dangling pointer problem, the thread which will queue the acknowledgment will receive stale data or a conflicting value.

Static Analysis

Classification

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (’Race Condition’), CWE-667: Improper Locking

• Affected Versions: 1.17.0-rc2 and older
• Tested Version: v1.17.0-alpha1-695
• Patched Version: Currently in Triage

Summary

A race condition in Mavlink’s ULogger module resulting in an unauthorized DoS when exploited.

Static Analysis

Cppcheck suggests a potential Use-After-Free (UAF):

A thread that is processing an acknowledgment can get a reference to instance right before the lock. If stop() is executed the instance object is destroyed. When the thread unpauses it executes handle ack() on the de-allocated instance (the stale acknowledgment).

bool MavlinkULog::_init = false;
MavlinkULog *MavlinkULog::_instance = nullptr;
px4_sem_t MavlinkULog::_lock;

void MavlinkULog::stop()
{
    lock();
    if (_instance) {
        delete _instance;
        _instance = nullptr;
    }
    unlock();
}

void MavlinkULog::handle_ack(mavlink_logging_ack_t ack)
{
    lock();
    if (_instance) {
        if (_wait_for_ack_sequence == ack.sequence) {
            _ack_received = true;
            publish_ack(ack.sequence);
        }
    }
    unlock();
}

The ULog streaming starts based on external commands allowing an opening for availability compromise.

Metrics

The impact of the PoC will be measured based on ASan Errors, usability of the PX4 console for an operator, and telemetry reliability. Its impact will also be measured by any indicators of memory corruption:

Dynamic Memory Analysis

• ASan errors, specifically the use-after-free message
• Dynamic analysis with GDB

Telemetry and Instability

• Operator usability of the PX4 console (responsiveness, latency)
• Publication rate increase (msgs/s)
• Time to execute command sent once work queue is flooded
• RX Loss fluctuation

Setup & Results

An unauthorized state desynchronization in Mavlink’s ULogger module resulting in a DoS when exploited (degraded command processing, resource starvation).

Environment

Requisites

• A tool like pymavlink or a socket to send the commands:
  • MAV CMD LOGGING START (ID 2510)
  • MAV CMD LOGGING STOP (ID 2511)
• A MAVLink communication channel to a PX4 flight controller (UDP Port 18570)

Steps

• Launch PX4 SITL (Reproducible on both jmavsim and Gazebo)
  • make px4 sitl jmavsim
  • make px4 sitl gz x500
• Execute the minimal PoC script in a new window

PoC

The Python script accomplishes two things:

• Opens a remote connection on UDP port 18570
• Floods the logger with STOP/START commands to trigger the race condition during the periodic acknowledgment

Remediation

Create unique sessions for each initialization of the logger, so that stale acknowledgments aren’t used in future sessions. Implement rate-limiting for logger toggling commands. Add a check within handle ack() to ensure that an active session exists before the periodic poll.

Impact

Flooding with LOGGING START and LOGGING STOP commands causes a 254.0% RX Loss value, a jump from 8.8K to ˜14.8K publication messages per second, and desynchronization within the MAVLink sequence tracking ability. The loss of communication between the drone and a transmitter causes severe issues such as modules (commander, navigator, and mavlink) skipping or losing important packets.

Metric	Baseline	Attacked
RX Loss	0.0%	254.0%
Publication Rate (msgs/s)	∼8.8K	∼14.8K

Additional commands sent from the operator are entered into the uORB work queue, which do not get executed until about a minute after the attacker has stopped the script. Stale acknowledgments additionally confuse an operator of the logger and connection status.

Throughout various runs, the RX loss fluctuated between 254.0% and undefined values such as NaN%.

Past CVEs Analyzed

Vulnerability 1: Global Buffer Overflow Leading to DoS (CVE-2023-47625)

Base Score: 7.1 (HIGH)

The Radio Control (RC) is a driver in the rc input PX4 module. Within this module, the radio controller data is sent to sensors to guide vehicle navigation. This driver uses the TBS Crossfire protocol (CRSF). CVE-2023-47625 leverages this protocol to change flight modes, causing unexpected vehicle behaviour.

The buffer size is the maximum number of SBUS data bytes, referred to as SBUS BUFFER SIZE. These serial bytes are written into the buffer, but later on within the CRSF parser (CrsfParser TryParseCrsfPacket). The vulnerability arises from a lack of size validation. This global overflow can then be manipulated to cause unexpected UAV behaviours, such as flight mode changes and a failure in processing CRSF telemetry. This vulnerability was patched in PX4 v1.14.0.

Vulnerability 2: Log Handler Stack Overflow (CVE-2026-32743)

Base Score: 6.5 (MEDIUM)

In the mavlink log handler.cpp, there exists a function called handle log request data. This function switches to a request, decodes it, and sends back the log. However, the sscanf() function parses logs from a list with no bounds, meaning there is no width specifier. Architecturally, while the file path was not intended to exceed 60 bytes, it is possible to overwrite other data in memory and perform a stack-based buffer overflow.

The attacker must be on the same network as the vehicle to send the crafted MAVLink messages. By performing this overflow, an attacker may crash the system or redirect code execution.

Vulnerability 3: Heap Use-After-Free (CVE-2026-32724)

Base Score: 5.3 (MEDIUM)

A Use-After-Free vulnerability occurs when a program accesses a memory block after it has already been ‘freed’ (deallocated). This may lead to heap being overflown, where the heap holds the program’s dynamically-allocated memory.

The MAVLink implementation in PX4 contains a user-after-free vulnerability in the Mavlinkshell::available() function. This is caused by a race condition between two threads:

• The receiver thread mavlink receiver.cpp handles shell creation and destruction
• The telemetry sender thread polls the shell for output

An attacker on the same network can send SERIAL CONTROL (ID 126) messages from a ground control station or host. This may cause extensive resource exhaustion in the system, leading to a Denial of Service.

Vulnerability 4: Missing Authentication for Critical Function (CVE-2020-10282)

Base Score: 9.8 (CRITICAL)

As discussed, no message signing is present in MAVLink 1.0. For older or unpatched systems this means that a variety of attacks may be executed such as unauthorized access, identity spoofing, etc. All v1.0 implementations are affected, and newer systems remain vulnerable if package signing is disabled.

Consequences of these attacks include reconfiguration of parameters, such as their Return-to-Home waypoint. Potential resource exhaustion is possible by flooding MAVLink with malformed packets.

Vulnerability 5: Inconsistent FTP State (CVE-2026-32709)

Base Score: 6.8 (MEDIUM)

A path traversal vulnerability was identified in mavlink ftp.cpp. An unauthenticated attacker may move through paths on the system as there is no canonization, and interestingly, “A (Time-of-Check to Time-of-Use (TOCTOU) race condition in the write validation on NuttX further allows bypassing the only existing guard”. This vulnerability was patched in 1.17.0-rc2.

CVE-2026-32709 may allow an attacker to read system files and inject malicious code. Mitigations include canonicalizing paths, implementing proper access control for FTP, and using atomic operations.

Vulnerability 6: Buffer Overflow in Zenoh (CVE-2026-32708)

Base Score: 8.0 (HIGH)

One of the modules in PX4 is Zenoh. Zenoh is uORB’s subscriber which allocates a stack variable-length array (VLA) for each message. With no bounds on the incoming payload length, a publisher on the same network can send a message to overflow and crash the bridge task. The bridge task directly affects the vehicle’s flight control. This brings light into the best security practice of ensuring input sizes are validating and remote attackers are disallowed from injecting payloads into middleware subscribers.

This vulnerability is patched in v1.17.0-rc2 and is mitigated with bounds checking.

---

Deliverable 2 — Exploit Plan

Introduction

This report details an exploit plan of the PX4 flight stack (v1.17.0-alpha1). It identifies five vulnerabilities, from stack-based overflows to race conditions. One of the aforementioned vulnerabilities is a novel vulnerability that demonstrates how an unauthenticated attacker may remotely compromise a vehicle. This deliverable provides the summary, static analysis, and metrics for each vulnerability being tested. Through these methods, the complexity and impact of each exploit is measured.

Overview

ID	Vulnerability	Module	Attack Vector	Impact
E1	Stack Buffer Overflow	mavlink log handler	Crafted log messages with oversized filepaths	Crashed log handler task, potential DoS
E2	Global Buffer Overflow	rc input (CRSF driver)	Crafted Radio Control packet send via Pymavlink	Flight mode alterations, potential service crash
E3	Heap Overflow (Use-After-Free)	MavlinkShell::available()	Crafted SERIAL CONTROL messages	Potential DoS, resource exhaustion
E4	Stack Buffer Overflow	uORB messaging (Zenoh)	Published messages with oversized payloads	Crashed bridge task, poor vehicle stability
E5	Cross-session state desynchronization	MavlinkULog::stop()	Rapid toggling of logger start & logger stop commands	Potential DoS, resource exhaustion

Static Analysis

MavlinkLogHandler sscanf stack buffer overflow via MAVLink log request

Classification

CWE-121: Stack-based Buffer Overflow

• Affected Versions: 1.17.0-rc1 and older
• Tested Version: v1.17.0-alpha1-695

Summary

A stack-based buffer overflow condition is when a buffer gets overflowed with information past its maximum size. This overflow causes other parts of memory to be leaked, such as the base and instruction pointers. In this particular case, a buffer is stack-based, meaning it is a local variable or function parameter.

Static Analysis

struct LogEntry {
    uint16_t id{0xffff};
    uint32_t time_utc{};
    uint32_t size_bytes{};
    FILE *fp{nullptr};
    char filepath[60];
    uint32_t offset{};
};

Since no PoC was provided within the security advisory, it was necessary to create a python exploit that sends a crafted MAVLink message to PX4 remotely. The file directory will be created using MAVLink FTP, with a file path that is larger than the 60-byte buffer.

Once the log is created on the internal file system, the log list may be requested with command LOG REQUEST LIST. This command then prompts the Log Handler to check the /log directory for the metadata of each new log entry.

Within the function that retrieves the log list of entries, the function sscanf() is used. This function may be considered unsafe as this function does not provide in-built bounds-checking.

Metrics

The impact of the PoC will be measured based on resulting drone behaviour and ASan errors:

Dynamic Memory Analysis

• ASan Errors, specifically the stack-buffer-overflow error
• GDB Analysis to determine whether the instruction pointer (rip) is overwritten with overflowed characters from the crafted file path

Undefined Drone Behaviour

• Connection loss, resulting from loss of heartbeats from the GCS
• Console crashing or unresponsive log handler task in tasklist

Global buffer overflow in crsf rc via oversized variable-length known packet

Classification

CWE-120: Buffer Copy without Checking Size of Input (’Classic Buffer Overflow’), CWE-787: Out-of-bounds Write

• Affected Versions: 1.17.0-rc2 and older
• Tested Version: v1.17.0-alpha1-695
• Patched Version: 1.17.0-rc2

Summary

A global buffer overflow occurs when an overflow does not merely stay within the stack, but bleeds out into the .data or .bss segments that store global variables.

TBS Crossfire (CRSF) is a telemetry protocol that the receiver uses to get telemetry data onto a drone transmitter. It supports two-way communication between the receiver and the transmitter. Static Analysis The CRSF parser handles packets from radio control and Crossfire. These packets, called frames, are extracted by header and payload. The payload is then copied into a static global buffer called process buffer.

static uint8_t process_buffer[CRSF_MAX_PACKET_LEN];

Max packet length of global buffer is 64 bytes

This buffer serves as a temporary storage before payloads are decoded within the CrsfParser TryParseCrsfPacket() function. The buffer will be iterated upon to parse the message, extracting the header, packet size type, payload, and cyclic redundancy check (CRC). If the packet is known, the length will be validated and working segment size is assigned the value of the packet descriptor.

If the packet is unknown, the parser will continue and de-queue the packet at once. In this else statement, there is a check (Line 299) validating the size of the segment size against the maximum packet length. This check is not present in the case where a packet type is recognized.

This lack of size check within the first case allows a malformed, known packet to be created with a size larger than the maximum 64 bytes and go uncaught by the parser. An attacker may be able to send, for example, ELRS packets and bypass this mechanism.

Additionally, there is a variable checking the status of ELRS payloads (CRSF PAYLOAD SIZE ELRS STATUS) which is assigned a value of -1. “In the parser state machine, variable-length known packets do not pass through the same maximum-length rejection used for unknown packet types.” This means that the copy (memcpy) to the buffer is unchecked, allowing an oversized packet to overflow the process buffer.

Metrics

The impact of the PoC will be measured based on resulting telemetry behaviour and ASan errors:

Dynamic Memory Analysis

• ASan Errors, specifically the static and global buffer overflow messages

Undefined Drone Behaviour

• Flooded PX4 console with messages
• Console crashing

Heap Use-After-Free in MavlinkShell::available() via SERIAL CONTROL Race Condition

Classification

CWE-416: Use-After-Free

• Affected Versions: 1.17.0-rc1 and older
• Tested Version: v1.17.0-alpha1-695
• Patched Version: 1.17.0-rc1

Summary

Automated fuzzing found a heap use-after-free vulnerability in the shell() function within the MAVLinkShell module. The receiver thread and sender have a race condition between each other. An unauthenticated attacker could spam the get and close shell to cause undefined behaviour, crashes, and memory corruption.

Static Analysis

SERIAL CONTROL is a MAVLink message with ID 126. This set of commands can be used to control a serial port. Within the mavlink shell file, there are two functions: MavlinkShell::start() and MavlinkShell::available, which start the shell and checks the amount of bytes waiting to be read from the shell.

size_t MavlinkShell::available()
{
    int ret = 0;
    if (ioctl(_from_shell_fd, FIONREAD, (unsigned long)&ret) == OK) {
        return ret;
    }
    return 0;
}

A function called Mavlink::task main() periodically checks (polls) that the shell is available to send back the output through MAVLink. MavlinkReceiver::handle message serial control() calls get shell() and close shell() commands. When one thread deletes the shell object with close shell(), the other can still hold a reference to the instance that was freed.

Under circumstances, there may be a Use-After-Free. It is also a remotely triggerable exploit.

Metrics

The impact of the PoC will be measured based on ASan errors.

Dynamic Memory Analysis

• ASan errors, specifically the heap use-after-free message

Undefined Drone Behaviour

• Broken pipes in console
• Console crashes

Zenoh uORB Subscriber Allows Arbitrary Stack Allocation

Classification

CWE-121: Stack-based Buffer Overflow

• Affected Versions: 1.17.0-rc1 and older
• Tested Version: v1.17.0-alpha1-695
• Patched Version: 1.17.0-rc2

Summary

A VLA is a variable-length array. The stack is allocated for each subscription message.

An unauthenticated attacker may send an oversized message to create an unbounded-size stack allocation. This leads to a stack-buffer overflow and a subsequent crash.

The beginning of this function validates the payload size to prevent a stack overflow. This is for the case of a contiguous payload, meaning a payload that is in one block of memory. However, this size check does not exist when the payload is non-contiguous. Later down the function, we see this snippet of code:

unsigned char reassembled_payload[len];
z_bytes_reader_t reader = z_bytes_get_reader(payload);
z_bytes_reader_read(&reader, reassembled_payload, len);
dds_istream_t is = {.m_buffer = &reassembled_payload[4], .m_size = static_cast<
    int>(len), .m_index = 0, .x_cdr_version = DDSI_RTPS_CDR_ENC_VERSION_1 };
dds_stream_read(&is, data, &dds_allocator, _cdr_ops);

Because there is no check for the size of the fragmented payload, a crafted one may exceed the maximum to hit the stack VLA. Additionally, a payload larger than the size of the stack may overflow other parts of memory, crashing the Zenoh task.

Metrics

The impact of the PoC will be measured based on ASan errors and whether the Zenoh task appears in the tasklist after script execution.

Dynamic Memory Analysis

• ASan errors, specifically the stack-buffer-overflow message

Drone Instability

• Crashed Zenoh bridge task
• Publication rate for position command (i.e. listener vehicle gps position)

---

Results

Stack Overflow (sscanf)

Environment

• Launch PX4 SITL with jmavsim and Address Sanitizer (ASan) make px4 sitl jmavsim PX4 ASAN=1
• Run the minimal PoC

PoC

As aforementioned, the script must achieve various steps:

• Establish a connection with the SITL via UDP using the pymavlink library
• Send a MAVLink CreateDirectory request with a crafted filepath of 70 bytes
• Send a MAVLink Command called LOG REQUEST LIST to parse the log list with sscanf()

Remediation

Limit string width to 59 with 1 byte for the null terminator appended. Keep the format specifier (%59s) to ensure the user input is of a string type. Avoid vulnerable functions such as gets() for reading user-inputted data. For more complex parsing of strings into tokens, use strtok(). Additionally:

• Always check the return value to ensure the expected number of bytes was read
• Avoid the %n specifier
• Ensure all variables are initialized

Employing these best practices will block buffer overflows and truly implement the filepath maximum.

Impact

When running the script while compiling PX4 with ASAN, the console crashes immediately and the instruction pointer is overwritten with overflowed characters.

In practice, this would cause the drone to lose connection with the GCS, as the console has crashed, and possibly physically crash or fail to engage its fail-safe.

Global Buffer Overflow

Environment

• Install the Docker-based reproduction environment
• Navigate to the directory and execute ./run.sh

The provided lab builds a SITL binary with ASAN, starts a PX4 daemon and crsf rc module, and injects the oversized packet.

PoC

Already provided within the Docker environment. Within the container, there is a crsf rc pty injector.py script that performs the following:

• Creates a master and slave device — PX4 listens to the slave, and the master device sends commands with the script
• Crafts a recognizable packet to bypass the check via:
  • Header (0xC8) to tell the driver to listen on the slave module
  • Payload length (64) to set the data length to exactly the buffer’s size
  • A CRC, which will cause the overflow given the lack of bounds checking
• Creates the staged CRC with crc8
• Performs packet fragmentation (splits the packet into two)

This PoC uses Baud Rate Shim to trick PX4 into believing there is a serial connection to allow the attack.

Remediation

Include bounds-checking for when a packet type is known to validate the segment size against the maximum packet length. The -1 variable-length identifier should be paired with a hard-coded constraint for the CRSF MAX PACKET LEN.

Impact

When running the PoC provided within the container, the PX4 console floods based on repeated poll timeouts from the simulator mavlink module. Compiling with ASan, the crash results in LeakSanitizer tracking the global buffer overflow.

Since the CRSF driver receives operator commands, an overflow of this driver causes a Denial-of-Service (DoS) on the commander module. As observed, the console did not flood with messages yet crashed as soon as the overflow occurred.

Observed result

The results file written to within the container shows a size 65 write into the buffer with length of 64 bytes.

Heap Use-After-Free

Environment

• Run PX4 SITL (jmavsim) with ASan enabled (make px4 sitl jmavsim PX4 ASAN=1)
• Use pymavlink to simulate heartbeats sent through MAVLink or connect to QGC

PoC

Already provided as a shared file in the advisory. This script:

• Uses send shell create to send a list of hex-encoded commands that start MavlinkShell
• Simultaneously runs send shell close with a list of hex-encoded commands to close the shell and delete the session, freeing the memory

Two threads are then created, one running the function to start the shell and the other running the function to stop and destroy the shell object.

This creates a race condition where the thread attempting to start the shell accesses the de-referenced pointer. These results are not reproducible on every trial. The race window is dependent on thread scheduler behaviour.

Remediation

To prevent race conditions, proper locking with a mutex (pthread mutex t) will ensure safe access of the shell object. Restrict IP addresses to known ones in PX4 to protect against remote attacks.

Impact

When running the PoC, results from ASan were not reproducible. The script was run repeatedly over a span of three minutes. However, the Address Sanitizer results were provided by the advisory publisher.

Zenoh Stack Allocation

Environment

• Make the Zenoh build provided
• View the reported ASan errors

PoC

The script is provided within the built environment. It accomplishes the following:

• Stubs the PX4 and Zenoh libraries
• Starts the uORB Zenoh Subscriber. This subscriber converts Zenoh packets into messages that the middleware can process.
• Creates a 16MB heap buffer filled with ’A’ (0x41) characters
• Supplies this payload to the data handler for allocation

const size_t payload_len = 16 * 1024 * 1024;
std::vector<uint8_t> payload(payload_len, 0x41);
z_loaned_sample_t sample{};
sample.payload.data = payload.data();
sample.payload.len = payload_len;
sample.payload.contiguous = false; // force non-contiguous path -> VLA
subscriber.data_handler(&sample);

Remediation

Implement the maximum length check to validate the payload against a limit. Consider using fixed-length arrays instead of VLAs if possible.

Impact

When running the PX4 console and triggering the script, the Zenoh bridge task crashed, and the console exited with the following ASan error (stack-overflow):

AddressSanitizer:DEADLYSIGNAL
=================================================================
==23755==ERROR: AddressSanitizer: stack-overflow
SUMMARY: AddressSanitizer: stack-overflow
==23755==ABORTING