OOB read in bencode_decode: strtoll called on non-NUL-terminated buffer
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 67/100
Research direction
Start in lib/bencode.c at __bencode_decode_integer around line 448, then read how bencode_decode_expect receives the buffer from ng_client.c around line 176. Check how the integer parser handles the input length and NUL termination. Done means malformed input such as i is rejected without reading past the buffer, while valid integers still decode.
Written by the indexing model from the issue text.
Description
__bencode_decode_integer (lib/bencode.c:448) calls strtoll(s, &convend, 10) on the length-delimited input buffer. strtoll requires NUL termination but bencode buffers are not NUL-terminated.
When the integer payload begins with whitespace (e.g. i , hex 69 20), strtoll skips it and scans past the buffer boundary looking for digits, causing a heap-buffer-overflow read.
Reachable from: ng_client.c receives into a 4096-byte arena buffer (arena_alloc, no NUL terminator) and passes it to bencode_decode_expect at line 176. A remote NG peer response with a valid cookie and malformed bencode body triggers the read.
Impact: Out-of-bounds read, process crash (DoS). No write primitive.
Fix: Copy the integer text into a stack buffer with NUL termination before calling strtoll, or bound the scan manually without strtoll.
Reproduce:
# 2-byte payload: "i " (0x69 0x20)
echo -n "i " | base64
# aSA=
Found by Bright Security using automated fuzz testing.
- Dominant language
- Perl
- Stars
- 992
- Forks
- 459
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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 sipwise/rtpengine
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 2 days
-
HTTP/WS worker threads spin forever in `__websocket_write_done()` (`sched_yield` loop) — 100% CPU with `--listen-http`Possibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 15/100
sipwise/rtpengine#2197 · 1 comment ·
Maintainers usually reply within 2 days
-
Kernel NULL pointer dereference in target_put() during target deletionPossibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
sipwise/rtpengine#2190 · 1 comment ·
Maintainers usually reply within 2 days
-
Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sipwise/rtpengine#2181 · 4 comments ·
Maintainers usually reply within 2 days
All issues in sipwise/rtpengine
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bioconda/bioconda-recipes#70187 ·
Maintainers usually reply within 2 days
-
documentation Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 93/100
Maintainers usually reply within 1 day
-
Proposed Text EditsOpen
Difficulty 1/5 Under an hour Newbie friendliness 82/100
curl/everything-curl#658 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
PDLPorters/pdl#561 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
objectionary/eolang.sty#197 ·
Maintainers usually reply within 1 day