UBSAN: left shifts into the sign bit in unaligned-read helpers
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 73/100
Research direction
Start with the listed shift expressions in src/libAtomVM/bitstring.h, src/libAtomVM/utils.h, src/libAtomVM/opcodesswitch.h, and src/libAtomVM/inet.c; read how each helper builds its integer value. Run the test suite with -fsanitize=undefined to reproduce the reports, then rerun it to confirm they are gone after the shifts are made defined. Done means all listed cases pass without UBSAN reports.
Written by the indexing model from the issue text.
Description
Running the test suite with -fsanitize=undefined reports "left shift of N by 24 places cannot be represented in type 'int'" (and by 56 places into 'long') from:
READ_32LE_UNALIGNEDinsrc/libAtomVM/bitstring.h:45andREAD_32_UNALIGNEDinsrc/libAtomVM/utils.h:57,:85and:138:((uint8_t *) ptr)[3] << 24promotes the byte tointbefore shifting, so any byte >= 0x80 overflows.large_integer_to_terminsrc/libAtomVM/opcodesswitch.h:1339and:1378:((int32_t) compact_term[0]) << 24and((int64_t) compact_term[0]) << 56.src/libAtomVM/inet.c:66:(term_to_int32(...) & 0xFF) << 24.
The generated code does what is intended today, but it is undefined behaviour and a compiler may legitimately miscompile it. Casting each byte to uint32_t/uint64_t before the shift (and converting to the signed type afterwards) fixes all of them.
- Dominant language
- Erlang
- Stars
- 2.3k
- Forks
- 171
- Avg merge
- 4d 11h
- Merged PRs (30d)
- 20
Getting set up
- No Dockerfile or Docker Compose file
- Has a 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 atomvm/AtomVM
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
lwIP sockets: a failed listen or connect leaves the socket lock held, a later close hangs foreverOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 3 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
milind-soni/OpenMausBot#5829 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
finos/fluxnova-bpm-platform#387 ·
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
OHDSI/Data2Evidence#3693 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
kubernetes-sigs/headlamp#8408 ·
Maintainers usually reply within 1 day