Summary

The Zenoh uORB subscriber allocates a stack VLA directly from the incoming payload length without bounds. A remote Zenoh publisher can send an oversized fragmented message to force an unbounded stack allocation and copy, causing a stack overflow and crash of the Zenoh bridge task.

Details

In src/modules/zenoh/subscribers/uorb_subscriber.hpp (data_handler), when the payload is non-contiguous, the code does:

  size_t len = z_bytes_len(payload);
  unsigned char reassembled_payload[len];
  z_bytes_reader_read(&reader, reassembled_payload, len);
  dds_istream_t is = {.m_buffer = &reassembled_payload[4], .m_size = static_cast<int>(len), ...};
  dds_stream_read(&is, data, ...);

There is no maximum length check. With Z_FEATURE_UNSTABLE_API enabled (on by default in src/modules/zenoh/CMakeLists.txt) large Zenoh messages are fragmented (FRAG_MAX_SIZE=512), taking the non-contiguous path and hitting the VLA. Any payload larger than the thread stack will overflow and corrupt adjacent frames.

PoC

zenoh-vla-stack-overflow-poc.tar.gz

A minimal ASAN PoC is in zenoh-vla-stack-overflow-poc/:

  cmake -S zenoh-vla-stack-overflow-poc -B zenoh-vla-stack-overflow-poc/build
  cmake --build zenoh-vla-stack-overflow-poc/build
  ./zenoh-vla-stack-overflow-poc/build/zenoh_vla_stack_overflow_poc

The harness includes the real uorb_subscriber.hpp and forces the non-contiguous path with a 16 MB payload. ASAN reports stack-overflow at uorb_subscriber.hpp:97 (the VLA allocation).

Impact

Stack-based buffer overflow triggered over the Zenoh network. Any reachable Zenoh publisher (adjacent network) can crash the PX4 Zenoh bridge task; with weak stack protections this could lead to control-flow compromise (remote code execution).

Acknowledgments

• Found by SecMate (https://secmate.dev)