[GH-ISSUE #13] Potential buffer over-read #12

New issue

Closed

opened 2026-05-05 03:29:44 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 03:29:44 -06:00

Owner

Originally created by @jonirons on GitHub (Dec 3, 2021).
Original GitHub issue: https://github.com/cy384/ssheven/issues/13

I believe the following lines allow for a buffer over-read (however remote the possibility):

d8753b3676/ssheven.c (L35)
d8753b3676/ssheven.c (L39)

The arrays are length 255 rather than 256; in both cases, I think it's possible for the array to end up being indexed with [255], which over-reads the buffer.

When reading from ascii_to_control_code, you might send garbage across the wire:
d8753b3676/ssheven.c (L576)

For keycode_to_ascii, the index to the above read might also end up being garbage:
d8753b3676/ssheven.c (L571)

If this looks like a problem, you'll also want to update this loop:

d8753b3676/ssheven.c (L50)

to:

	for (uint16_t i = 0; i < 256; i++)

I don't know that any Mac keyboard would even have a key code on it equal to 0xff, nor do I know if the translation to "ASCII" would ever give 0xff. This latter seems like it could be possible if there is a layout with a ˇ key.

Originally created by @jonirons on GitHub (Dec 3, 2021). Original GitHub issue: https://github.com/cy384/ssheven/issues/13 I believe the following lines allow for a buffer over-read (however remote the possibility): https://github.com/cy384/ssheven/blob/d8753b3676a63b8763a5480817eaad5ce28e4735/ssheven.c#L35 https://github.com/cy384/ssheven/blob/d8753b3676a63b8763a5480817eaad5ce28e4735/ssheven.c#L39 The arrays are length `255` rather than `256`; in both cases, I think it's possible for the array to end up being indexed with `[255]`, which over-reads the buffer. When reading from `ascii_to_control_code`, you might send garbage across the wire: https://github.com/cy384/ssheven/blob/d8753b3676a63b8763a5480817eaad5ce28e4735/ssheven.c#L576 For `keycode_to_ascii`, the index to the above read might also end up being garbage: https://github.com/cy384/ssheven/blob/d8753b3676a63b8763a5480817eaad5ce28e4735/ssheven.c#L571 If this looks like a problem, you'll also want to update this loop: https://github.com/cy384/ssheven/blob/d8753b3676a63b8763a5480817eaad5ce28e4735/ssheven.c#L50 to: ``` for (uint16_t i = 0; i < 256; i++) ``` I don't know that any Mac keyboard would even have a key code on it equal to `0xff`, nor do I know if the translation to "ASCII" would ever give `0xff`. This latter seems like it could be possible if there is a layout with a `ˇ` key.

gitea-mirror closed this issue

2026-05-05 03:29:47 -06:00

gitea-mirror commented

2026-05-05 03:29:51 -06:00

Author

Owner

@cy384 commented on GitHub (Dec 3, 2021):

thanks for the report, and for reading the code closely! should be an easy fix, I'll get to it this evening

@cy384 commented on GitHub (Dec 3, 2021): thanks for the report, and for reading the code closely! should be an easy fix, I'll get to it this evening

gitea-mirror commented

2026-05-05 03:29:55 -06:00

Author

Owner

@cy384 commented on GitHub (Dec 5, 2021):

should be fixed, thanks again

@cy384 commented on GitHub (Dec 5, 2021): should be fixed, thanks again

gitea-mirror referenced this issue

2026-05-05 03:33:58 -06:00

[PR #12] [MERGED] Temporary fix for reopen the window if password fails #33