提出 #941761: GPAC 26.08-DEV Memory Corruption

GPAC 26.08-DEV, built from master at commit
6fed75dfd06b23ee646d110298668dfd9b8d2e2b, contains an out-of-bounds read
in wait_for_header_and_parse() in src/utils/downloader.c.

Affected file: src/utils/downloader.c
Affected function: wait_for_header_and_parse
Affected parameter: the value of the HTTP response header "Content-Range"

An HTTP server that replies with the header "Content-Range: bytes", with
nothing following the word "bytes", causes GPAC to read one byte past the
end of a 6-byte heap allocation.

Root cause. At src/utils/downloader.c:3748 the header value is stored
verbatim with gf_strdup(), so the value "bytes" produces a 6-byte
allocation (five characters plus the terminator). At
src/utils/downloader.c:3819 the code does:

else if (!stricmp(hdr->name, "Content-Range")) {
if (!strnicmp(hdr->value, "bytes", 5)) {
val = hdr->value + 5;
while (strchr(":= ", val[0]))
val++;

strnicmp compares only the first five characters, so the value "bytes"
passes and val points at the terminating null. strchr() treats the
terminating null of its search string as part of that string, so
strchr(":= ", 0) returns a non-NULL pointer. The loop condition is
therefore satisfied by the terminator, val is incremented, and the read at
src/utils/downloader.c:3822 is past the end of the allocation. How far the
pointer walks depends on the heap bytes that follow.

The guarded form is already the convention elsewhere in the project, for
example src/scenegraph/svg_attributes.c and src/scene_manager/loader_bt.c
both test the terminator before calling strchr.

Reproduction. Run a listener on 127.0.0.1:8099 that replies with:

HTTP/1.1 206 Partial Content
Content-Range: bytes
Content-Length: 4

AAAA

Then run: gpac -i http://127.0.0.1:8099/x.mp4 inspect

An AddressSanitizer build reports:

ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1
#0 wait_for_header_and_parse src/utils/downloader.c:3822:27
#1 http_do_requests src/utils/downloader.c
#2 gf_dm_sess_fetch_data src/utils/downloader.c:2536:3
#3 httpin_process src/filters/in_http.c:517:7
located 0 bytes after 6-byte region, allocated by strdup at
src/utils/downloader.c:3748:20

Well-formed values are clean: "bytes 0-3/4", "bytes:0-3/4" and
"bytes=0-3/4" all produce no report. "byte" is also clean because it fails
the strnicmp check. Only the value that is exactly "bytes" triggers it.

Impact. This is reachable from the network and needs no file to be
delivered to the victim. Any application using GPAC to fetch media over
HTTP, including normal DASH and HLS playback, can be made to read out of
bounds by the server it is talking to or by an attacker able to modify the
response in transit. On a build without a sanitizer the one-byte overread
does not necessarily crash.

Classification: CWE-125, out-of-bounds read.
Suggested CVSS 3.1 vector: AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L

Fix. Test the terminator before the strchr call:

val = hdr->value + 5;
- while (strchr(":= ", val[0]))
+ while (val[0] && strchr(":= ", val[0]))
val++;

Reported publicly at https://github.com/gpac/gpac/issues/3859 on
2026-08-18. Fixed upstream in commit c74a30650 ("fuzz: fix a problematic
strchr pattern leading to heap overflows"). The current code at
src/utils/downloader.c:3832 reads
while (val && val[0] && strchr(":= ", val[0])).

• ソース: ⚠️ https://github.com/gpac/gpac/issues/3859
• ユーザー: dutch (UID 100715)
• 送信: 2026年08月21日 02:15 (27 日 ago)
• モデレーション: 2026年09月16日 14:15 (26 days later)
• ステータス: 承諾済み
• VulDBエントリ: 405734 [GPAC 26.08-DEV src/utils/downloader.c wait_for_header_and_parse Content-Range 情報漏えい]
• ポイント: 20