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>
Give PRs generated via the skill a fixed, skimmable structure instead of an ad-hoc leading paragraph. Keeps the existing no-attribution, no-test-plan, and terse rules.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
wait_until_ready() polls MAVSDK's is_armable, but a known hysteresis gap
(and estimator heading-reference flicker at startup) means the flag can
read armable while PX4 then denies the arm command with 'no heading
reference'. This made arm() fail intermittently. Retry the arm command
until the autopilot accepts it, so the transient is absorbed while real
failures still time out.
Signed-off-by: Julian Oes <julian@oes.ch>
The four older VTOL RTL tests waited only 120s for disarm while running
the same climb-to-550m-and-land missions as the other RTL tests, which
already use 150s. 'RTL direct Mission Land' occasionally tipped just
over 120s of sim time (observed 123.76s), failing wait_until_disarmed.
Align all of them to 150s for margin.
Signed-off-by: Julian Oes <julian@oes.ch>
Switching the SITL tests to the SIH simulator exercises sih.cpp, whose
gcov data contains a spurious negative counter (line 510) that newer
lcov treats as a fatal error, failing the coverage step. Pass
--ignore-errors negative so lcov zeroes the bad count and continues, as
the tool itself suggests.
Signed-off-by: Julian Oes <julian@oes.ch>
The 0.01m (1cm) tolerance was not reachable within the 15s sim-time
window for the standard_vtol, causing the takeoff-and-hold test to time
out. Use 0.1m, which still verifies altitude hold but is physically
achievable, and stays below the 0.15m hold-monitoring tolerance.
Signed-off-by: Julian Oes <julian@oes.ch>
