fix(Core/OutdoorPvP): Fix use-after-free in DelCapturePoint#25229
fix(Core/OutdoorPvP): Fix use-after-free in DelCapturePoint#25229blinkysc wants to merge 1 commit intoazerothcore:masterfrom
Conversation
…urePoint DeleteGOData was called before _capturePoint->Delete(), freeing the GameObjectData while Delete() still accesses it via GetScriptId(). Reorder to match DelObject() which correctly deletes the GO first.
There was a problem hiding this comment.
Pull request overview
Fixes a shutdown-time use-after-free in OPvPCapturePoint::DelCapturePoint() by reordering deletion of GameObjectData to occur after the capture point GameObject is deleted, matching the (already-correct) ordering used in DelObject().
Changes:
- Reordered
DeleteGOData()to run after_capturePoint->Delete() - Keeps spawn id reset (
m_capturePointSpawnId = 0) aligned with the data deletion
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (_capturePoint) | ||
| { | ||
| _capturePoint->SetRespawnTime(0); // not save respawn time | ||
| _capturePoint->Delete(); |
There was a problem hiding this comment.
_capturePoint remains non-null after calling _capturePoint->Delete(). If Delete() frees the object (or makes the pointer invalid), leaving the member pointer set can enable later use-after-free via any subsequent _capturePoint checks. Consider clearing the member immediately after deletion (e.g., set _capturePoint = nullptr; after Delete()) to make the object lifecycle explicit and prevent accidental reuse.
| _capturePoint->Delete(); | |
| _capturePoint->Delete(); | |
| _capturePoint = nullptr; |
| sObjectMgr->DeleteGOData(m_capturePointSpawnId); | ||
| m_capturePointSpawnId = 0; |
There was a problem hiding this comment.
DeleteGOData(m_capturePointSpawnId) is called unconditionally. If m_capturePointSpawnId can legitimately be 0 (it’s set to 0 here and likely used as a sentinel), consider guarding the delete with if (m_capturePointSpawnId) to avoid relying on implicit behavior of DeleteGOData(0) and to make intent clearer.
| sObjectMgr->DeleteGOData(m_capturePointSpawnId); | |
| m_capturePointSpawnId = 0; | |
| if (m_capturePointSpawnId) | |
| { | |
| sObjectMgr->DeleteGOData(m_capturePointSpawnId); | |
| m_capturePointSpawnId = 0; | |
| } |
Changes Proposed:
Minor shutdown-only use-after-free:
OPvPCapturePoint::DelCapturePoint()calledDeleteGOData()before_capturePoint->Delete(), freeing theGameObjectDatawhileDelete()→SetLootState()→GetScriptId()still accesses it.Reorders to match
DelObject()directly above, which already has the correct order (delete GO first, then erase data).Only triggers during server shutdown via
OutdoorPvPMgr::Die()— no gameplay impact.This PR proposes changes to:
AI-assisted Pull Requests
Important
While the use of AI tools when preparing pull requests is not prohibited, contributors must clearly disclose when such tools have been used and specify the model involved.
Contributors are also expected to fully understand the changes they are submitting and must be able to explain and justify those changes when requested by maintainers.
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
-DCMAKE_CXX_FLAGS="-fsanitize=address")GameObject::GetScriptIdduringOutdoorPvPMgr::Die()Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.