Skip to content

Comments

feat: Upload event attachment#3

Merged
bruno-garcia merged 5 commits intomasterfrom
feature/upload-event-attachment
Mar 7, 2019
Merged

feat: Upload event attachment#3
bruno-garcia merged 5 commits intomasterfrom
feature/upload-event-attachment

Conversation

@bruno-garcia
Copy link
Member

No description provided.

@bruno-garcia bruno-garcia requested a review from mitsuhiko March 7, 2019 09:56
@bruno-garcia bruno-garcia merged commit 98216e3 into master Mar 7, 2019
@bruno-garcia bruno-garcia deleted the feature/upload-event-attachment branch March 7, 2019 10:01
azat pushed a commit to azat-ch/sentry-native that referenced this pull request Sep 6, 2022
Update modulefinder to compile on riscv
Strive-Sun added a commit to Strive-Sun/sentry-native that referenced this pull request Feb 22, 2024
supervacuus added a commit that referenced this pull request Oct 28, 2024
This is in response to CodeQL security scan alert #1-#3.

`Elf[32|64]_Ehdr[.e_phnum|.e_phentsize|.e_shnum|.e_shentsize]` are all `uint16_t`, this means the loop-var `i` is bounded by `uint16_t` and should fit in a `uint32_t` (to prevent unsigned overflow in the loop). A switch to unsigned still makes sense, because we reduce the future chance of unnecessary signed overflow (=UB) in the loop body.

All program/section-header table entry sizes are cast to `uin64_t` even though the multiplication is bound to `uint32_t` by both factors being bound by `uint16_t`. This fixes the potential overflow before conversion to the bigger type.
supervacuus added a commit that referenced this pull request Oct 28, 2024
* fix: remove a potential overflow before conversion

This is in response to CodeQL security scan alert #1-#3.

`Elf[32|64]_Ehdr[.e_phnum|.e_phentsize|.e_shnum|.e_shentsize]` are all `uint16_t`, this means the loop-var `i` is bounded by `uint16_t` and should fit in a `uint32_t` (to prevent unsigned overflow in the loop). A switch to unsigned still makes sense, because we reduce the future chance of unnecessary signed overflow (=UB) in the loop body.

All program/section-header table entry sizes are cast to `uin64_t` even though the multiplication is bound to `uint32_t` by both factors being bound by `uint16_t`. This fixes the potential overflow before conversion to the bigger type.

* also safely cast the access to section header string table.
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