Describe the bug
Summary
The mission feasibility checker does not appear to validate MAV_CMD_DO_SET_HOME against active geofence constraints. A mission or command sequence that changes the vehicle's Home reference point may move Home outside the configured geofence boundary, which can affect distance-based or height-based geofence checks.
I initially reported this through the project's Security Policy contact and also contacted the corresponding release managers, but I have not received a response so far. I am opening this issue to ask whether this behavior is expected and to request guidance on the appropriate fix path.
Affected Component
- Component: Navigator / Mission Feasibility Checker
- File:
src/modules/navigator/MissionFeasibility/FeasibilityChecker.cpp
- Relevant function:
FeasibilityChecker::checkMissionAgainstGeofence()
- Relevant MAVLink command:
MAV_CMD_DO_SET_HOME
Details
The current geofence feasibility logic appears to focus on mission items that explicitly contain position data, such as waypoint-like mission items. However, commands that modify navigation state and can affect geofence interpretation, such as MAV_CMD_DO_SET_HOME, do not appear to be validated against the active geofence.
As a result, a mission item or command that changes Home may be accepted even when the new Home position is outside the configured geofence boundary. This can shift the reference point used by distance-based or height-based geofence logic and may undermine the intended safety restrictions.
Security Impact
If confirmed, this may allow a user with permission to upload mission items or send accepted MAVLink commands to bypass intended geofence constraints by moving the Home reference point outside the allowed boundary.
Potential impact:
- Geofence policy bypass
- Safety restriction bypass
- Incorrect interpretation of distance-based or height-based geofence constraints
- Unexpected mission feasibility approval
Reproduction
I have reproduced the behavior in SITL with an active geofence configuration and a command sequence involving MAV_CMD_DO_SET_HOME.
I am intentionally not posting the full PoC code publicly here. I can provide the complete SITL reproduction script, logs, and video evidence privately to maintainers if needed.
Expected Behavior
MAV_CMD_DO_SET_HOME should be validated against the active geofence policy before being accepted or before mission feasibility is approved.
If the new Home position is outside the allowed geofence boundary, the command or mission should be rejected.
Suggested Fix
Update the mission feasibility and/or command validation path so that MAV_CMD_DO_SET_HOME is included in geofence validation.
At minimum, the new Home coordinates should be checked against the active geofence constraints before the command is accepted or before a mission containing this command is considered feasible.
Disclosure Timeline
- I reported this issue through the project's Security Policy contact.
- I also contacted the corresponding release managers.
- I have not received a response so far.
- I am opening this public issue to request maintainer feedback and guidance.
Additional Notes
Please let me know if you prefer that I provide the full PoC, SITL logs, and video through a private channel.
Flight Log / Additional Information
No response
Describe the bug
Summary
The mission feasibility checker does not appear to validate
MAV_CMD_DO_SET_HOMEagainst active geofence constraints. A mission or command sequence that changes the vehicle's Home reference point may move Home outside the configured geofence boundary, which can affect distance-based or height-based geofence checks.I initially reported this through the project's Security Policy contact and also contacted the corresponding release managers, but I have not received a response so far. I am opening this issue to ask whether this behavior is expected and to request guidance on the appropriate fix path.
Affected Component
src/modules/navigator/MissionFeasibility/FeasibilityChecker.cppFeasibilityChecker::checkMissionAgainstGeofence()MAV_CMD_DO_SET_HOMEDetails
The current geofence feasibility logic appears to focus on mission items that explicitly contain position data, such as waypoint-like mission items. However, commands that modify navigation state and can affect geofence interpretation, such as
MAV_CMD_DO_SET_HOME, do not appear to be validated against the active geofence.As a result, a mission item or command that changes Home may be accepted even when the new Home position is outside the configured geofence boundary. This can shift the reference point used by distance-based or height-based geofence logic and may undermine the intended safety restrictions.
Security Impact
If confirmed, this may allow a user with permission to upload mission items or send accepted MAVLink commands to bypass intended geofence constraints by moving the Home reference point outside the allowed boundary.
Potential impact:
Reproduction
I have reproduced the behavior in SITL with an active geofence configuration and a command sequence involving
MAV_CMD_DO_SET_HOME.I am intentionally not posting the full PoC code publicly here. I can provide the complete SITL reproduction script, logs, and video evidence privately to maintainers if needed.
Expected Behavior
MAV_CMD_DO_SET_HOMEshould be validated against the active geofence policy before being accepted or before mission feasibility is approved.If the new Home position is outside the allowed geofence boundary, the command or mission should be rejected.
Suggested Fix
Update the mission feasibility and/or command validation path so that
MAV_CMD_DO_SET_HOMEis included in geofence validation.At minimum, the new Home coordinates should be checked against the active geofence constraints before the command is accepted or before a mission containing this command is considered feasible.
Disclosure Timeline
Additional Notes
Please let me know if you prefer that I provide the full PoC, SITL logs, and video through a private channel.
Flight Log / Additional Information
No response