Skip to content

Comments

[WIP] feat: parse dsn as minidump#1

Closed
bruno-garcia wants to merge 1 commit intomasterfrom
feature/dsn-parsing
Closed

[WIP] feat: parse dsn as minidump#1
bruno-garcia wants to merge 1 commit intomasterfrom
feature/dsn-parsing

Conversation

@bruno-garcia
Copy link
Member

No description provided.

@bruno-garcia bruno-garcia requested a review from mitsuhiko March 4, 2019 17:10
@bruno-garcia bruno-garcia changed the title feat: parse dsn as minidump [WIP] feat: parse dsn as minidump Mar 4, 2019
@bruno-garcia bruno-garcia deleted the feature/dsn-parsing branch March 11, 2019 14:15
@bruno-garcia bruno-garcia restored the feature/dsn-parsing branch March 11, 2019 14:15
@bruno-garcia bruno-garcia deleted the feature/dsn-parsing branch March 11, 2019 14:15
@matepek matepek mentioned this pull request Oct 13, 2019
azat pushed a commit to azat-ch/sentry-native that referenced this pull request Sep 6, 2022
Strive-Sun added a commit to Strive-Sun/sentry-native that referenced this pull request Dec 18, 2023
Strive-Sun added a commit to Strive-Sun/sentry-native that referenced this pull request May 22, 2024
Strive-Sun added a commit to Strive-Sun/sentry-native that referenced this pull request May 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.

1 participant