Security content was scattered across four unrelated sidebar locations
with no entry point: hardening and signing under Development/MAVLink,
secure boot under Hardware Setup, log encryption under logging. A reader
had to already know all four pages existed to find any of them.
Add a top-level Security section with a hub page that collects them and
links out to the threat model and the reporting process. Those two live
in the repository rather than here so there is one authoritative copy
that does not fork per release or per translation. The existing pages
keep their current URLs and sidebar positions.
Cross-link the hub from the pages where the trust boundary actually
matters: companion computer and uXRCE-DDS, which sit inside the boundary
and are not covered by message signing, ROS 2 offboard control, telemetry
and data links, and the safety pages, which are the conceptual twin.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
PX4 has no written statement of what it defends against, so incoming
security reports re-litigate the same boundary from scratch and the same
class of finding has been decided both ways. MAVLink FTP path traversal
was closed once as out of scope and later published as CVE-2026-32709.
State the boundary the docs have implied for years. MAVLink is an open
protocol, so reaching a link is the integrator's boundary to defend and
message signing is the mechanism PX4 ships for closing it. What PX4 owns
on any link is that its parsers do not corrupt memory, that it grants no
capability beyond the published set, and that reaching one bus does not
hand over another.
Guarantees are stated per configuration tier rather than as a flat list,
because the guarantee set is a function of whether signing is provisioned
and whether the offboard transport is reachable. A flat list would claim
protections that do not hold on the shipped default.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Adopt a policy for AI-assisted contributions modeled on the Linux
kernel's coding-assistants document: the human submitter is the author
and accountable for every line, an AI tool never appears in authorship
or Signed-off-by tags, licensing follows the LF Generative AI Policy,
and disclosure via an Assisted-by trailer is required.
Summarize the policy in CONTRIBUTING.md and add it to the docs sidebar.
The commit and pr skills keep their disclosure and sign-off rules but do
not link the policy: files loaded into every agent session are standing
context, not rules applied on demand, so pointing at the policy from
there invites agents to pull it in and biases unrelated work.
Assisted-by: Claude:claude-opus-4-8[1m]
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Align with the Linux kernel security process: bugs found with AI
assistance systematically surface across multiple researchers at the
same time, so treat them as public and fix them in the open instead of
through a private advisory. Reproducers stay private and are shared
with maintainers on request.
Reference: https://docs.kernel.org/process/security-bugs.html
Assisted-by: Claude:claude-fable-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Instead of climbing/descending with max speed first and then fly straight, fly diagonally to new waypoint.
This aligns the behavior between Mission and Hold modes.
* boards: enable CONFIG_FS_LARGEFILE for NuttX boards with MMC/SD
Without large file support, fsblkcnt_t/off_t are 32-bit and statfs
consumers (procfs /fs/usage, df) compute the volume size as
f_bsize * f_blocks in 32 bits, which wraps at 4GB. Boards with an
SD card or eMMC larger than 4GB report the wrong capacity, e.g. a
32GB SD card on FMU-V6X:
nsh> ls -l /dev/mmcsd0
brw-rw-rw-1850212352 /dev/mmcsd0 (= 31914983424 mod 2^32)
nsh> df -h
vfat 1749M 240K 1749M /fs/microsd
With CONFIG_FS_LARGEFILE=y the same card reports the full 29G.
This enables the option on the 77 boards that build the MMC/SD block
driver (CONFIG_MMCSD=y, SDIO or SPI). Boards without removable storage
and constrained-flash targets (CONFIG_BOARD_CONSTRAINED_FLASH=y) are
left unchanged.
Note: on the px4_firmware_nuttx-10.3.0+ branch the 64-bit file types
are additionally gated on CONFIG_HAVE_LONG_LONG, which is only defined
via nuttx/compiler.h include order, making the option unreliable. That
gating is fixed by the companion NuttX backport PR
(PX4/NuttX, branch backport-fs-largefile, upstream commit 92b2f1bd3d3).
Tested on a custom STM32H743 board with 8GB eMMC and on FMU-V6X with a
32GB SD card.
* fix(boards): enable CONFIG_FS_LARGEFILE for MMC/SD variant configs
The test/console/stackcheck/socketcan/sysview/cyphal/debug/cryptotest
variant configs of boards covered by the previous commit were missed,
leaving them with 32-bit off_t. fmu-v5 protected is intentionally
excluded: protected-mode syscall proxies keep 32-bit widths.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* chore(nuttx): bump submodule for FS_LARGEFILE backport
Picks up the backport of upstream NuttX 92b2f1bd3d3, which gates the
64-bit file types on CONFIG_FS_LARGEFILE alone instead of the
include-order-dependent CONFIG_HAVE_LONG_LONG.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Follow-up to #28042: the ECM wind entity read ran every step and would
overwrite wind published on the wind_info topic. Only default to the
wind entity until the first wind_info message is received, from then on
the topic value is used exclusively.
Signed-off-by: mahima-yoga <mahima@auterion.com>
* feat(simulation): load gz WindEffects system globally
Nothing published the world wind (wind_info topic / wind entity
velocity) so far, leaving the airspeed sensor and drag systems without
wind data in worlds that define one.
No effect in worlds without a wind definition.
Signed-off-by: mahima-yoga <mahima@auterion.com>
* fix(simulation): read wind from the ECM in the gz airspeed plugin
The wind_info topic is only published when the wind changes, so a model
that spawns after the world has loaded misses it and simulates a
wind-blind pitot: so the EKF never estimates the wind. Read the wind entity
velocity from the EntityComponentManager each step instead.
Signed-off-by: mahima-yoga <mahima@auterion.com>
---------
Signed-off-by: mahima-yoga <mahima@auterion.com>
* feat(camera_feedback): gate CAMERA_IMAGE_CAPTURED by param
Some cameras implementing the MAVLink Camera Protocol (e.g. reached via
TRIG_INTERFACE=MAVLink) report CAMERA_IMAGE_CAPTURED themselves. The
autopilot's camera_feedback also emitted this message, so the ground
station saw duplicate capture messages for every shot.
Add a bool 'report' field to the camera_capture message, set from the new
CAM_CAP_REPORT parameter, and gate the CAMERA_IMAGE_CAPTURED stream on it.
When reporting is disabled the capture is still published and logged for
geotagging; only the MAVLink message to the ground station is suppressed.
CAM_CAP_REPORT applies live (no reboot); it only gates a MAVLink message,
unlike CAM_CAP_FBACK which reconfigures the capture pin.
* fix(camera_feedback): update docs
Gazebo gimbal joints consume vehicle-relative angles, but the gz_bridge
passed Earth-frame ROI attitude setpoints straight through, applying the
vehicle heading twice. Respect the yaw-frame flags and rotate Earth-frame
setpoints into the vehicle frame with the inverse vehicle attitude before
commanding the joints.
The MAVLink v2 gimbal output also only recomputed the geographic ROI
bearing when a new ROI command arrived, so the setpoint froze while the
vehicle translated. Refresh position-based setpoints every update cycle,
matching the v1 output.
Signed-off-by: jbotwina <jimbotwina16@gmail.com>
wait_until_altitude() returns on the first touch of the target band while
the vehicle is still climbing, so start_checking_altitude() latched the hold
reference mid-climb. The normal takeoff overshoot (~0.24 m) and slow VTOL
settle then exceeded the 0.15 m tolerance and the standard_vtol job failed
intermittently.
Wait for the overshoot to damp before capturing the reference, and restore
the 0.2 m tolerance established in #26106 (a later SIH rewrite had tightened
it back to 0.15 m). Steady-state hover holds to ~0.05 m, so the check stays
sensitive to real altitude-hold failures.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Since #27918 a blind descend reports the distinct Descend flight mode
instead of masquerading as Land. MAVSDK v3.17.1 has no Descend mode, so
wait_for_flight_mode(Land) timed out and SITL failed on main.
Losing GPS in SIH removes all horizontal position aiding, so the vehicle
always blind-descends after the mission GPS loss; a controlled Land is
never entered. The test already waits for the automatic disarm after
landing, which is the meaningful check.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Give NAVIGATION_STATE_DESCEND its own MAVLink custom_mode and advertise it so ground stations stop displaying it as Land.
---------
Signed-off-by: Elisa Ferrara <elisa.ferrara@auterion.com>
Shifting the remaining bytes with memmove and zeroing the tail is
functionally equivalent to the copy-out/zero/copy-back sequence and
removes the dynamic allocation entirely, along with the unchecked
malloc return.
Suggested-by: Beat Küng <beat@auterion.com>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The swap buffer in VnSearcher_discardData was malloc'd but never freed,
leaking on every call. Reported by Martin Strunz.
No VnSearcher_* symbol is referenced by the driver today, so the linker
drops searcher.c entirely and no shipped firmware is affected. Fixed
anyway so the leak cannot go live if the port autodetect API is ever
used. Upstream vnproglib is frozen with no public repository, so the
fix is carried in the vendored copy.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Since b11e615810 src/modules/zenoh/Kconfig sources the generated topic
catalog through ZENOH_KCONFIG_TOPICS, which only cmake exports, so every
standalone Kconfig parse crashed and build_all_targets produced an empty
build matrix on every run while the scan job still reported success.
Add Tools/kconfig/loadconfig.py as the single entry point for parsing
the Kconfig tree outside cmake: it generates the topic catalog exactly
like cmake/kconfig.cmake and provides shared board/target enumeration
and config loading. Port generate_board_targets_json.py (CI matrix) and
updateconfig.py (make updateconfig) to it; both were independently
broken and each reimplemented board scanning on its own.
Harden the workflow so the next failure of this class is loud: run the
generator as a standalone assignment, so bash -e fails the step (the
previous echo "matrix=$(...)" form masked the exit code), and write
the JSON outputs through the heredoc GITHUB_OUTPUT form.
Matrix output verified byte-identical to the pre-b11e6158101 baseline
in all three modes; updateconfig output verified identical against the
same baseline.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
sensor_gps uORB instance numbering is boot-order dependent for CAN
receivers, so GPS_RAW_INT/GPS2_RAW showed a random receiver in dual-GPS
setups (e.g. moving base + rover RTK). Resolve the primary from
SENS_GPS_PRIME instead, matching the vehicle_gps_position selection
including DroneCAN node IDs (2-127). The node ID matching lives in
lib/gnss/SensorGpsSelector.hpp and is shared with vehicle_gps_position.
Each stream only reports its selected receiver and falls back to NO_GPS
keepalives if it has no data.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(crsf): correct GPS telemetry ground speed, course, and altitude offset
Ground speed was sent from the NED down-velocity component with the km/h conversion inverted, course over ground wraps negative values through the uint16 field, and the rc_input frame applied a +1 m offset where the protocol expects +1000 m.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(crsf): send local altitude and vertical speed telemetry
Add the CRSF barometric altitude frame (0x09), fed from vehicle_local_position, to both the crsf_rc driver and the legacy rc_input telemetry. Shows up as Alt and VSpd sensors on EdgeTX/OpenTX radios, complementing the MSL altitude already sent in the GPS frame.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* docs(crsf): clarify local-altitude telemetry semantics and units
Note that the Alt/VSpd sensors reuse the CRSF baro-altitude frame to carry PX4's fused local altitude (above the estimator origin), not a raw barometer reading, and document the EdgeTX version requirements. Add terse unit comments on the GPS-frame fields.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The rangefinder bridge published TOO_CLOSE, TOO_FAR and UNDEFINED
readings with signal_quality -1 (unknown) and the raw wire range, so
consumers treated them as usable measurements. DroneCAN rangefinder
nodes commonly report an out-of-range sentinel value in the range field
for these reading types (e.g. max_distance + 1 for TOO_FAR); flight
logs show the EKF fusing a node's 101 m TOO_FAR sentinel as terrain
distance at 45-113 m AGL.
Per the distance_sensor uORB convention (0 = invalid signal), mark all
non-VALID_RANGE readings as quality 0 so downstream consumers reject
them.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(ekf2): correct Minimum spelling in range validity param short
User-facing EKF2 range finder parameter description for QGC metadata.
* ci: retrigger SITL after flaky standard_vtol failure
---------
Co-authored-by: Daniel Pike <daniel@team-of-light.com>
