Skip to content
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

fix crash - buffer overflow by one in fexpand #521

Merged
merged 1 commit into from
May 29, 2024
Merged

Conversation

avih
Copy link
Contributor

@avih avih commented May 29, 2024

The symptom, on Windows, using LESSOPEN, was that "less" would sometimes (up to 5-10%) crash with exit code 116.

gdb detected heap block overflow in free(filename) in lglob.

The overflow is because fexpand_copy(s, NULL) return value (and allocated size) doesn't count the final \0, but fexpand_copy(s, x) does write a final \0.

This appears to be a regression of commit 1626d06, where fexpand_copy returned the strlen of the result, and fexpand allocated n+1, but commit 1626d06 changed the allocation to n.

Fix it by always counting the \0 - which appears to fix the crash.

fexpand_copy is only used from fexpand (once to count, and once for the actual copy), so there's no risk elsewhere from this change.

The symptom, on Windows, using LESSOPEN, was that "less" would
sometimes (up to 5-10%) crash with exit code 116.

gdb detected heap block overflow in free(filename) in lglob.

The overflow is because fexpand_copy(s, NULL) return value (and
allocated size) doesn't count the final \0, but fexpand_copy(s, x)
does write a final \0.

This appears to be a regression of commit 1626d06, where fexpand_copy
returned the strlen of the result, and fexpand allocated n+1, but
commit 1626d06 changed the allocation to n.

Fix it by always counting the \0 - which appears to fix the crash.

fexpand_copy is only used from fexpand (once to count, and once for
the actual copy), so there's no risk elsewhere from this change.
@avih
Copy link
Contributor Author

avih commented May 29, 2024

Interestingly, it doesn't seem to crash when compiled with UCRT (either gcc or clang), but does crash when compiled with MSVCRT (either gcc or clang).

Maybe the UCRT malloc leaves some space after the block, so it can avoid crashes with small overflows? Or maybe the allignment or selected block size is bigger with UCRT...

EDIT: it also crashes with UCRT, just with different filename lengths. So I guess the UCRT malloc doesn't use exactly the same block sizes as MSVCRT. This PR fix the crash also with UCRT.

@gwsw gwsw merged commit f752294 into gwsw:master May 29, 2024
@avih avih deleted the crash-fexpand branch May 30, 2024 02:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants