You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fast64 handles texture scrolling in SM64 by checking against the address of segments loaded in sSegmentROMTable and making sure they match the address of a particular segment it wants to scroll. However, at no point are the segments stored in here ever reset back to NULL. Once segments become unloaded, they will then be pointing to invalid memory, despite still returning truthfully when checking for texture scrolling.
In other words, loading an actor group for a particular segment and then unloading it (without loading another actor group in its place) will cause the game to attempt to scroll textures at arbitrary memory addresses, leading to both severe and difficult to diagnose cases of undefined behavior. This is so bad that it could very easily and feasibly lead to the complete death of unsuspecting hacks that are affected by this.
A proposed solution to this would be to make sSegmentROMTable a struct, storing both the address and the left/right side of the pool. Whenever a main pool memory allocation is freed, the game should check whether each stored address is greater than or equal to the new allocated end address on the left side, or less than the start address on the right side. If it is, update it to be NULL. (This may not work for segments of size 0, but those cases are already sketchy to begin with. This will also need to check multiple functions such as main_pool_pop_state and main_pool_free, potentially others that I'm not aware of yet.)
The text was updated successfully, but these errors were encountered:
gheskett
changed the title
fast64 Texture Scrolling Not Memory Safe
[SM64] fast64 Texture Scrolling Not Memory Safe
Jul 2, 2024
fast64 handles texture scrolling in SM64 by checking against the address of segments loaded in
sSegmentROMTable
and making sure they match the address of a particular segment it wants to scroll. However, at no point are the segments stored in here ever reset back to NULL. Once segments become unloaded, they will then be pointing to invalid memory, despite still returning truthfully when checking for texture scrolling.In other words, loading an actor group for a particular segment and then unloading it (without loading another actor group in its place) will cause the game to attempt to scroll textures at arbitrary memory addresses, leading to both severe and difficult to diagnose cases of undefined behavior. This is so bad that it could very easily and feasibly lead to the complete death of unsuspecting hacks that are affected by this.
A proposed solution to this would be to make
sSegmentROMTable
a struct, storing both the address and the left/right side of the pool. Whenever a main pool memory allocation is freed, the game should check whether each stored address is greater than or equal to the new allocated end address on the left side, or less than the start address on the right side. If it is, update it to be NULL. (This may not work for segments of size 0, but those cases are already sketchy to begin with. This will also need to check multiple functions such asmain_pool_pop_state
andmain_pool_free
, potentially others that I'm not aware of yet.)The text was updated successfully, but these errors were encountered: