-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory overflow in core option system #5924
Comments
I think it's more likely that FBA is overflowing. Did the entries contain the original text followed by garbage? |
The vector provided to RETRO_ENVIRONMENT_SET_VARIABLES is properly terminated by {NULL, NULL} . Do you mean the string which define the name/values of the core options ? Hmmm some of them are strcopy'ed at some point, but all of them are handled by snprintf before going to the vector, which i thought was supposed to do this fine ? Also, the fact is that most of the time, the string present in the dkong.hi file is related to core options, but unrelated to the current game itself (i end up seeing strings like "fba-macro-karnovr-Button_..." while karnovr is another game and i don't generate that specific string for the current game, but the string itself is present in my retroarch-core-options.cfg file, or as mentioned earlier, in one extreme case i saw the path of the file itself in dkong.hi), the only component which could be aware of those strings at that time is retroarch itself. Edit : just to make things clear, the core options in fbalpha are generated at runtime on per-game basis for dipswitches and macros. |
No I was thinking the hi-score strings whenever they are populated. |
The hiscore buffer is directly handled by vanilla code from upstream, the only thing i do is defining the "szAppHiscorePath" variable (the path to the folder where hiscore.dat is stored, and where the game.hi files are generated). This code was already checked, it was someone from upstream who told me there was garbage in the game.hi files and it was some buffer overflow somewhere in the non-upstream code. Also, i checked commits prior to the inclusion of the libretro-common file_stream overrides in fbalpha (i thought it could be messing up the upstream code which handle storing the hiscore to the file), same issue. |
Ahh... ok, well I'm kinda out of ideas hopefully someone else has some. |
Hmm i'm not really a C/C++ developper, upstream is not particularily aware of the specifics of libretro cores/frontend, perhaps it would be a good thing if someone knowledgable take a look at https://github.com/libretro/fbalpha/blob/master/src/burn/hiscore.cpp just to make sure we are not overlooking something. |
@Alcaro can i ask for your expertise in this matter? |
Just build with ASAN? |
I'll try building retroarch with asan when i'm back home, that's actually pretty dumb of me to not try this since i did try asan on the core itself. |
The only thing I can offer here is 'use asan or valgrind until you've got a stack trace'. |
I was probably drunk last time i ran dkong with asan. I tried again and found the following issue :
Funny thing (or not), if i disable everything related to libretro-common's file_stream_transforms, it fixes the issue. I'll link @albertofustinoni since i think he is responsible for this code. |
Had to hotfix libretro-common's file_stream_transform by myself since the previous code was buggy and the current one makes dkong crashes. The current commit of libretro-fbalpha probably don't work properly with some windows devices, but that's still better than having file corruption and settings not being saved properly for everyone. |
Description
Following libretro/fbalpha#162 , i think this is a retroarch issue, while doing my tests i ended up having the string /home/myusername/.config/retroarch/retroarch-core-options.cfg in my dkong.hi file, this path doesn't exist anywhere in the core code, so how could this be a memory overflow in the core code ?
Also, i tried building the core with address sanitizer (which i think is supposed to detect this kind of issue) and it didn't detect anything.
Expected behavior
Not having random string belonging to the core options system in the hiscore files, so they won't corrupt the game when loading.
Actual behavior
Random string appear in the hiscore files, they prevent the game to run properly.
Steps to reproduce the bug
Bisect Results
I don't know, i tried an older release of retroarch (1.5.0) and it was the same
Version/Commit
Retroarch 1.6.9 release with current commit of fbalpha (also happen with older commit of fbalpha)
Environment information
Sorry in advance if it's not an issue in retroarch itself, but from my understanding :
The text was updated successfully, but these errors were encountered: