Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

P2: abort-rearm on a ship that is not being rearmed reads past the object array

Open Beginner friendly
  • Is something wrong?
#7,917 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
game-dev

Research direction

Read sexp_abort_rearm in sexp.cpp and compare its support ship lookup with the existing ai_abort_rearm_request helper in aicode.cpp. The issue describes three possible fixes; check the helper’s behavior and relevant rearm tests before choosing an approach. Done means abort-rearm safely does nothing when no support ship is servicing the named ship.

Written by the indexing model from the issue text.

Description

Problem

The abort-rearm sexp crashes or corrupts memory when the ship it names is not currently being rearmed. Mission designers may reasonably use it to cancel a rearm "just in case", but if no support ship is servicing that ship, the sexp hands the repair code an object at index -1 and the repair code reads through it.

In sexp_abort_rearm (sexp.cpp), the support ship is looked up from the ship's AI info without checking that one is set, so &Objects[-1] is passed to ai_do_objects_repairing_stuff, which then walks that object's docking list.

Steps to reproduce

  1. FSO master (tested on 12a36dc1a with an ASan debug build; sexp.cpp, aicode.cpp and objectdock.cpp are unchanged on current master 76219fd1e), Linux, MediaVPs 5.0.2.
  2. Any mission with a ship that is not being rearmed (I used a GTF Myrmidon given a play-dead order).
  3. Run ( abort-rearm "<that ship>" ) from an event.

Expected vs. actual behavior

Expected: nothing happens, since there is no rearm to abort.

Actual: AddressSanitizer reports a global-buffer-overflow read in dock_find_instance (objectdock.cpp:1047), called from ai_do_objects_repairing_stuff (aicode.cpp:11378) and sexp_abort_rearm (sexp.cpp:15342). The address read is the slot just before the global object array. Without the sanitizer the result depends on whatever memory sits there.

Proposed fixes

  1. Skip ships with no support ship. In sexp_abort_rearm, continue to the next ship when support_ship_objnum is negative. One line, matches what the sexp promises.
  2. Guard inside the repair function. Have ai_do_objects_repairing_stuff ignore an abort when the repair object is invalid, which also protects any other caller.
  3. Route through the existing abort helper. Call ai_abort_rearm_request, which already handles the "nobody is servicing me" case, instead of calling the repair code directly.
Dominant language
C++
Stars
488
Forks
184
Avg merge
2d 9h
Merged PRs (30d)
40

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scp-fs2open/fs2open.github.com

All issues in scp-fs2open/fs2open.github.com

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.