Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
#7,917 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
game-dev

Direzione di ricerca

Leggi sexp_abort_rearm in sexp.cpp e confronta la ricerca della nave di supporto con l’helper ai_abort_rearm_request esistente in aicode.cpp. L’issue descrive tre possibili soluzioni; controlla il comportamento dell’helper e i test di riarmo pertinenti prima di scegliere un approccio. Il lavoro è concluso quando abort-rearm non fa nulla in sicurezza se nessuna nave di supporto sta assistendo la nave indicata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
C++
Stelle
488
Fork
184
Merge medio
2g 9h
PR unite (30g)
40

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di scp-fs2open/fs2open.github.com

Tutte le issue di scp-fs2open/fs2open.github.com

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.