32bit overflow does not work
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- networking
Research direction
Start with the cited timestamp calculations and timeout check in dtls.c, then inspect sorted insertion in netq.c and the uint32_t handling in dtls_time.h. Verify behavior around 32-bit timestamp overflow; done means timeout checks and queue ordering handle those timestamps correctly.
Written by the indexing model from the issue text.
Description
dtls_time.h seems to be uint32_t aware:
https://github.com/eclipse/tinydtls/blob/68b2521ca668c632d6febf85fe3f9090d26b7b4e/dtls_time.h#L64
but these lines may produce problems with 32bit overflow:
these calculate possibly overflowing time stamps:
https://github.com/eclipse/tinydtls/blob/68b2521ca668c632d6febf85fe3f9090d26b7b4e/dtls.c#L1763
https://github.com/eclipse/tinydtls/blob/68b2521ca668c632d6febf85fe3f9090d26b7b4e/dtls.c#L4534
these do not deal with overflowing timestamps:
calculating if the timeout happend: (timestamp passed by)
https://github.com/eclipse/tinydtls/blob/68b2521ca668c632d6febf85fe3f9090d26b7b4e/dtls.c#L4596
inserting (sorted) into the netq
https://github.com/eclipse/tinydtls/blob/68b2521ca668c632d6febf85fe3f9090d26b7b4e/netq.c#L96
In #123 @boaks and me pointed that out
reference / line number are current develop branch
- Dominant language
- C
- Stars
- 122
- Forks
- 67
- Avg merge
- 6d 8h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from eclipse-tinydtls/tinydtls
-
ECDHE_ECDSA ClientKeyExchange rejected as too short when DTLS_PSK_MAX_CLIENT_IDENTITY_LEN > 64Possibly taken A pull request linked to this issue is open or already merged. Openbug good first issue please retest
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
eclipse-tinydtls/tinydtls#298 · 2 comments ·
Maintainers usually reply within 2 days
-
`dtls_get_cookie`: dereference before the length check (currently masked by `dtls_create_cookie`)Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
eclipse-tinydtls/tinydtls#279 · 2 comments · 1 reaction ·
Maintainers usually reply within 2 days
-
MSVC build is broken (undeclared `DTLS_DEBUG_BUF_SIZE`)Possibly taken @mrdeep1 claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
eclipse-tinydtls/tinydtls#283 · 5 comments ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 57/100
eclipse-tinydtls/tinydtls#278 · 3 comments · 1 reaction ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
eclipse-tinydtls/tinydtls#274 · 2 comments ·
Maintainers usually reply within 2 days
All issues in eclipse-tinydtls/tinydtls
Similar issues
-
UB: (int) cast of a user double outside int range in dispatch / vm_index_is_int / flat_index_atOpenarea:runtime-vm
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
InauguralSystems/EigenScript#1748 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wasm-micro-runtime/wasm-micro-runtime#5159 ·
Maintainers usually reply within 7 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 Half a day Newbie friendliness 62/100
Maintainers usually reply within 1 day