PaperlayerView exact revision on arXiv

Source-linked AI summary

Mission (Im)Possible: Towards Autonomous Discovery of Autopilot Logic Flaws in Open-Source Drone Frameworks

Ziyi Liang, Zichuan Li, Bin Yuan, Deqing Zou, Luyi Xing

arXiv:2610.19566v1cs.CRcs.SE

TL;DR

Logic flaws in autopilot software are difficult to discover because they involve cross-module semantics and often lack crashes or unified bug oracles. IMF combines command-level static slices, LLM-generated simulator tests, and log analysis; evaluation on PX4 and Ardupilot confirmed 105 previously unknown flaws.

  • Problem

    Autopilot logic flaws can span modules and runtime semantics, while LLM discovery is challenged by context limits, hallucinations, and the lack of unified bug oracles.

    Source: §1 · pp. 1–2

  • Method

    IMF uses command-level forward slices to guide an auditor agent, simulator tests to exercise hypotheses, and an LLM log analyzer to validate candidate-specific runtime violations.

    Source: §4.1 · pp. 6–7, §10 · p. 18

  • Results

    105 previously unknown logic flaws were confirmed after manual verification on PX4 and Ardupilot.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The discovered flaws include behaviors that do not directly cause crashes detectable by traditional sanitizers.

    Source: §6.2 · p. 11

    IMF cannot find logic bugs that depend on specific hardware backends such as cameras, actuators, or gimbals.

    Source: §8 · p. 16

Abstract

from arXiv · show

Autonomous drones are increasingly deployed in safety-critical tasks, yet their autopilot software can still contain subtle logic flaws that lead to unsafe behaviors. These flaws are difficult to discover with existing techniques because they often depend on semantic relationships across modules, commands, and runtime state, and rarely manifest as crashes or detectable failures. With recent advances in LLMs, we observe that, when equipped with essential domain knowledge and carefully crafted context, LLMs demonstrate strong capabilities in understanding the high-level semantics of autopilot systems, making them suitable for logic flaw discovery. However, LLMs are limited by their context and can be biased to the vulnerabilities frequently occurs in training dataset, while logic flaws often require higher-level semantic bug oracles to identify their existence. To bridge the gap, we present Impossible Mission Finder (IMF), a multi-agent system combining static analysis, dynamic execution and log analysis, that supports fully automated identify, test, and validate logic flaws in autonomous vehicles. IMF primarily contains three LLM agents, it first uses the auditor agent to propose logic flaw hypothesis based on carefully-crafted program slicing, then it launches tester agents to write and execute test cases for each candidate, and finally it spawns the log analyzer agent to validate the execution log against the flaw hypothesis. This enables IMF dynamically validate bug oracles in a case-by-case manner, making it suitable for discovering logic flaws that do not have a unified pattern. We evaluated IMF on two widely used open-source autopilot systems, PX4 and Ardupilot, leading to 105 previously unknown logic flaws, that can cause unsafe behaviors including mission interruption failures, invalid actions, entering into restricted fly zones etc.

1 Introduction

Logic flaws in drone autopilots can have safety-critical consequences but are difficult to detect because they span modules and runtime state and may not cause crashes. IMF combines static analysis, LLM agents, simulator tests, and log analysis; its evaluation confirmed 105 previously unknown flaws.

1 Introduction

  • Logic flaws are overlooked despite potential real-world impacts, and can arise from cross-module state propagation, implicit assumptions, and runtime semantics.A PX4 synchronization issue can cause the drone to mishandle a PAUSE command.Source: §1 · p. 1
  • LLMs need carefully constructed context for autopilot codebases exceeding 6M lines, while hallucinations and the lack of generic bug oracles complicate discovery.Unlike memory-corruption or taint-style flaws, logic flaws often lack unified patterns and observable crashes.Source: §1 · p. 2
  • IMF uses program slices to guide LLM hypotheses, then automatically generates and runs tests and analyzes execution logs to validate candidate flaws.The authors describe the system as a fully automated multi-agent approach.Source: §1 · p. 2
  • 105 previously unknown logic flaws were confirmed after manual verification on PX4 and Ardupilot.The flaws can cause operational failures and safety-critical issues, including navigation errors or collisions.Source: §1 · pp. 1–2

2 Background

The background describes MAVLink commands and telemetry, mission execution and flight modes, and indirect data flows that connect command handlers to vehicle outputs.

2.1 MAVLink Protocol and MAV_CMD

  • MAVLink connects drones to external systems and carries commands and telemetry, including commands that configure missions and flight parameters.It also enables setting home positions, GeoFence boundaries, and mission configurations.Source: §2.1 · pp. 2–3

2.2 Flying Modes and Missions

  • Missions execute ordered waypoint and action sequences in mission mode, while operator commands or safety conditions can trigger flight-mode transitions.Examples of modes include takeoff, hold or loiter, mission or auto, and return-to-launch.Source: §2.2 · p. 3

2.3 Indirect Data Flow in Autopilot Frameworks

  • Autopilot data flows often cross modules indirectly: PX4 uses named uORB topics, while Ardupilot uses mechanisms such as parameter stores and handler tables.A reposition command can flow through a handler, navigator, setpoint topic, and position-control modules toward actuator outputs.Source: §2.3 · p. 3

3 Motivating Example

A PX4 home-position update can leave an active waypoint's setpoint stale while its reachability check uses the updated altitude. That inconsistency can prevent waypoint completion and cause indefinite loitering.

3 Motivating Example

  • A home-position altitude update can leave an active waypoint's target unrecalculated while the reachability check uses the new altitude.The inconsistent state can prevent the system from recognizing that the waypoint has been reached.Source: §3 · p. 3
  • The setpoint publication runs only after a mission update or waypoint completion, but the distance check runs on each Navigator::on_active call.Thus the check can use the updated home position while low-level motor modules retain previously published coordinates.Source: §3 · pp. 4–5
  • The mismatch can make the drone keep correcting its heading toward an already-passed waypoint and loiter indefinitely around invalid target coordinates.The distance fails the acceptance condition, so the waypoint is not marked reached.Source: §3 · p. 5
  • In preliminary trials, GPT-5.4 found the issue in all three runs with a prepared slice, while none of four tested models found it using full files.With full files, models instead reported simpler non-semantic issues.Source: §3 · p. 5

4 Impossible Mission Finder (IMF)

IMF combines offline command-level static analysis with online LLM agents that propose hypotheses, test them in simulators, and validate execution logs. Its design targets context quality, hallucinations, and the absence of unified logic-flaw oracles.

4 Impossible Mission Finder (IMF)

  • IMF has an offline phase that builds command forward slices and an online auditor, tester, and log analyzer that propose, execute, and validate flaw hypotheses.The pipeline combines static analysis and LLMs to automate logic-flaw discovery.Source: §4 · p. 5, Figure 2 · p. 6

4.1 Preparing Analysis Context For LLMs

  • Forward slices give the auditor focused cross-function and cross-module context, tracing a MAVLink command from dispatch through downstream consumers.The slices include relevant functions, control- and data-flow fragments, and the call chain.Source: §4.1 · p. 6
  • IMF accounts for indirect flows by joining publisher and subscriber slices through topic names and merging command aliases through curated mappings.It also enumerates multiple dispatch points and merges their slices for a command.Source: §4.1 · pp. 6–7
  • SliceDB tools query individual command slices or shared sinks across two commands, while repository and sub-agent tools let the auditor explore and delegate tasks.The offline database stores forward slices for runtime interaction by the auditor.Source: §4.1 · pp. 7–8

4.2 Verifying with Runtime Execution

  • The tester uses a unified Python interface for both autopilots and checks whether each test reflects the hypothesis and can distinguish the suspected bug from normal behavior.The harness hides framework-specific API details, and failed semantic checks return a rationale for revision.Source: §4.2 · pp. 8–9

4.3 Validating Existence of Logic Flaws

  • The log analyzer uses a candidate-specific ego state to interpret execution entries and determine whether observed behavior matches the hypothesis.IMF selects needed state fields dynamically rather than relying only on a fixed ego-state schema.Source: §4.3 · pp. 9–10
  • 97% fewer LLM calls result from triggering analysis only after the sliding window accumulates at least 10 meaningful ego-state changes.The window collapses repeated silent log entries and focuses analysis on higher-level semantics.Source: §4.3 · p. 10

5 Implementation

IMF combines separately packaged agent software and a testing harness, with CodeQL-generated slices and MAVLink interfaces supporting code exploration and testing.

Agent implementation

  • The agent package uses a ReAct auditor, while the tester and log analyzer follow fixed workflows for direct invocation by the auditor.The multi-agent package is built on LangGraph and uses code exploration tools from Atlantis.Source: §5 · p. 10

Static analysis

  • CodeQL queries build SliceDB by collecting forward slices for MAVLink commands, messages, and uORB topics and mapping messages to commands.The seven query files comprise three for Ardupilot and four for PX4, totaling 1,846 lines of query code.Source: §5 · p. 10

Testing harness

  • The testing harness implements interfaces for 42 MAV_CMDs and supports arbitrary MAVLink packets through send_param, send_command, and send_command_int.Direct packet IDs and parameters let agents test edge cases beyond the unified interfaces.Source: §5 · p. 10

Release

  • The implementation and findings were released anonymously on GitHub.The passage points to a Data Availability section for details.Source: §5 · p. 10

6 Evaluation

Across PX4 and Ardupilot, IMF identified 105 unique logic flaws after manual verification. The evaluation also examines auditor candidate generation, tester test-case generation, log analysis, and comparisons with existing frameworks.

6.1 Overview

  • The overview identifies GPT-5.4 for the auditor and tester and GPT-OSS-120B for the log analyzer, then previews component evaluations.The evaluation proceeds from end-to-end effectiveness to the auditor, tester, and log analyzer.Source: §6.1 · p. 11

6.2 Framework Effectiveness on Real-world Systems

  • 105 unique real logic flaws remained after manual verification and merging two duplicate pairs.The findings include command input-handling defects, protocol incompliance, runtime state inconsistencies, and safeguard enforcement failures.Source: §6.2 · p. 11
  • The four confirmed flaw categories include 57 command input-handling defects, 11 protocol-incompliance cases, 29 runtime-state inconsistencies, and 8 safeguard-enforcement failures.Examples include invalid geofence parameters, protocol-field misinterpretation, pause/reposition races, and commands that fail to validate geofences.Source: §6.2 · pp. 11–12, Table 1 · p. 12

6.3 Effectiveness of the Auditor

  • With SliceDB enabled, the auditor produced 28 candidates on PX4 versus 17 without it, and 23 on Ardupilot versus 22 without it.The authors attribute the larger PX4 difference to slicing that connects indirect uORB dataflows; Ardupilot’s direct function calls are often traceable through file-level reads.Source: §6.3 · pp. 12–13, Table 2 · p. 13

6.4 Effectiveness of the Tester

  • The tester generated valid tests for 36/50 sampled hypotheses on its first attempt and 46/50 by its third attempt.Three remaining failures were rejected by semantic checks; another test passed semantic checking but timed out before producing a parseable log.Source: §6.4 · p. 13, Table 3 · p. 13

6.5 Effectiveness of the Log Analyzer

  • On the 50-log dataset, the full log analyzer achieved the highest F1 (0.81) by checking runtime logs against auditor hypotheses.Without the hypothesis it made more false positives; Dronlomaly’s low-level motion features were not aligned with most of the logic bugs.Source: §6.5 · pp. 13–14, Table 4 · p. 14

6.6 Comparison with Existing Frameworks

  • PGFuzz requires expert-written temporal-logic policies, while ADGFuzz targets assignment-dependency bugs and misses many flaw types IMF identified.IMF instead combines LLM-generated hypotheses, dynamic testing, and log-based validation to address diverse semantic bugs without a manually written oracle for one bug class.Source: §6.6 · p. 14

7 Case Study

Five case studies illustrate how autopilot logic flaws can produce unsafe mission behavior through stale validation, state inconsistency, and flawed recovery. Additional examples cover protocol interpretation, authority checks, and command-parameter propagation.

7 Case Study

  • The five cases span geofence enforcement, pause handling, RTL recovery, narrow-zone recovery, and waypoint reachability after a home-altitude update.The cases involve stale validation, race conditions, inconsistent state updates, flawed recovery logic, and command-semantics errors.Source: §7 · p. 14, Figure 3 · p. 15
  • A mission accepted under an old geofence can continue into a newly restricted region after the fence changes.PX4 accepts the new fence but does not reliably recheck the already loaded mission against it.Source: §7 · p. 14
  • A pause race can leave the navigator following the previous waypoint even after the system records the pause state.The vehicle can continue toward the next waypoint instead of stopping.Source: §7 · p. 15
  • If the home position is updated inside a no-fly zone, RTL can later use that location as its recovery destination.PX4 does not consistently validate the updated home position against active no-fly zones before RTL uses it.Source: §7 · p. 15
  • Between two narrow no-fly zones, opposing recovery actions can keep the drone moving between restricted regions instead of resuming its mission.An operator may need to take over to move it out of the repeated recovery maneuvers.Source: §7 · p. 15
  • Changing home altitude during a mission can leave waypoint state based on the old altitude while reachability checks use the new one.The current waypoint may remain incomplete, blocking later mission items.Source: §7 · p. 16
  • Other cases include accepting (0, 0) as a payload location, ignoring a debug command’s target component, and dropping a force flag during disarm-command propagation.These cover protocol interpretation, authority checks, and command-parameter propagation.Source: §7 · p. 16

8 Discussion

IMF focuses on logic flaws in shared autopilot modules that can be tested in simulation, while hardware-backend bugs and several other areas remain outside its current scope. Its effectiveness may also vary with the LLMs used.

8 Discussion

  • IMF cannot find logic bugs that depend on hardware backends such as cameras, actuators, or gimbals.Its testing package executes tests in simulators and targets general modules such as mission control and command handling.Source: §8 · p. 16
  • IMF targets MAVLink command handling and mission-related logic; lower-level controllers, sensor drivers, GPS spoofing, and other physical-layer attacks are out of scope.The authors leave automatic identification of logic bugs in those modules to future work.Source: §8 · p. 16
  • IMF’s effectiveness may vary across LLMs and reasoning efforts, although simulator execution, log validation, and expert review are used to check reported flaws.All three modules rely on LLM performance.Source: §8 · p. 16

9 Related works

Related work addresses localized violations, predefined testing oracles, log anomalies, and LLM-based code analysis. IMF distinguishes itself by synthesizing candidate-specific behavioral divergences from autopilot code slices and validating them through simulation and logs.

9 Related works

  • Classical analysis methods are effective for localized memory-safety, protocol, or invariant violations, while IMF targets mission-logic flaws with runtime-resolved cross-module evidence and semantic divergence.Autopilot testing systems commonly rely on predefined policies, differential checks, dependencies, or environmental mutations rather than candidate-specific divergence hypotheses.Source: §9 · p. 17
  • IMF’s log analyzer checks whether the candidate’s predicted divergence appears in a run, rather than detecting generic anomalies in flight logs.The paper says this reduces false positives from benign trajectory variation.Source: §9 · p. 17
  • IMF adds slice context that crosses autopilot indirection and dynamic confirmation to LLM-based code analysis and bug-finding approaches.The cited work notes that LLM systems can struggle with noisy whole-file context and unverified findings.Source: §9 · p. 17
  • Representative findings include a debug command that can trap the autopilot, negative delay values that pass through immediately, and negative servo repeat counts that can cause effectively unbounded oscillation.The table identifies findings by ID, platform, related MAVLink command, and description.Source: §9 · p. 18

10 Conclusion

IMF combines targeted code context, simulator testing, and log-based semantic validation to automatically identify, test, and validate autopilot logic flaws. Evaluation on PX4 and Ardupilot uncovered 105 previously unknown flaws after deduplication.

10 Conclusion

  • IMF constructs command-level code slices as LLM context, converts generated hypotheses into simulator tests, and validates candidate-specific runtime violations in execution logs.The log analyzer checks whether the candidate-specific violation appears in the logs.Source: §10 · p. 18
  • The system addresses the need for high-quality LLM context, runtime verification infrastructure, and semantic bug oracles for varied logic violations.Source: §10 · p. 18
  • 105 previously unknown logic flaws were uncovered on PX4 and Ardupilot after deduplication.Source: §10 · p. 18

Related papers

Loading 2610.19566v1…