-
Notifications
You must be signed in to change notification settings - Fork 647
Document SysCfb_GetFbPtr bug #2586
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
base: main
Are you sure you want to change the base?
Conversation
| //! @bug fbIdx is a signed integer that can overflow into the negatives. When compiled with a C99+ compiler or IDO, | ||
| //! the remainder operator will yield -1 for odd negative values of fbIdx. | ||
| //! This results in an out of bounds array access in SysCfb_GetFbPtr due to the negative index value, | ||
| //! which will crash the game. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest something like
| //! which will crash the game. | |
| //! which will most likely read an invalid pointer (a NULL pointer in the case of all matching versions) and crash the game when trying to render to that "framebuffer". |
to not make it sound like it's the OoB access which directly crashes the game
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea this is why i didn't bother stating that it crashes the game. It should be pretty obvious that fetching the color framebuffer pointer from an unintended memory address would lead to devastating consequences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may as well not leave things up to interpretation though, right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bump
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, there isn't a good reason to explain what happens past the OOBs read. When you go beyond that point, there are so many different possible outcomes to consider, none of which are consistent, and none of which are important if your goal is to fix the bug.
Where I think I could be clearer is I could state that the oobs read happens when trying to retrieve the next framebuffer pointer. I think knowing that the color framebuffer pointer is being set to a garbage value is enough on it's own to hint that bad things are going to happen soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont see why we have to "hint" at anything. Its perfectly okay to say what will probably happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I don't know what would "probably" happen once the framebuffer ptr is assigned to garbage data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what dragorn wrote is fine.
Contributions made in this pr are licensed under CC0