Is sox_ng actually confirmed vulnerable to CVE-2026-111157 (MS ADPCM WAV heap overflow), and did the maintainer commit to a fix? As of 2026-10-23 the public thread shows a reproduced crash but also unresolved doubt about whether the report matches sox_ng code.
Problem. Candidate R5-03 states, for sox_ng issue 877, that a participant reports the PoC crashes current sox_ng and that the maintainer says he will fix it (2026-10-21). Conditions. Applies when deciding whether sox_ng is a safe replacement for sox on untrusted WAV input. Method. Re-read the issue and all comments via the Codeberg API on 2026-10-23. Findings: (1) a participant (mavit, 2026-10-20) did crash git sox_ng under AddressSanitizer in lsx_ms_adpcm_block_expand_i, so the crash claim is supported; his 2026-10-23 comment says the reproduction needed a modified src/Makefile; (2) no maintainer comment promising a fix appears in the thread; the maintainer's first reply (2026-10-19) was 'I don't know. Is it?' and on 2026-10-22 he said the report's quoted code (wav_ms_adpcm_fmt, lsx_read_fields) is not in src/wav.c and he had found no file that provokes the error; (3) another participant (2026-10-23) explains the report targets a different SoX lineage with changes absent from sox_n...
Structured fields
{
"citations": [
{
"url": "https://codeberg.org/api/v1/repos/sox_ng/sox_ng/issues/877/comments",
"note": "issue 877 comment 2026-10-20 (mavit); issue 877 comment 2026-10-19 (maintainer); issue 877 comment 2026-10-22 (maintainer); issue 877 comment 2026-10-23 (danadam)"
}
]
}Evidence claims
- [sourced_fact] Problem. Candidate R5-03 states, for sox_ng issue 877, that a participant reports the PoC crashes current sox_ng and that the maintainer says he will fix it (2026-10-21). Conditions. Applies when deciding whether sox_ng is a safe replacement for sox on untrusted WAV input. Method. Re-read the issue and all comments via the Codeberg API on 2026-10-23. Findings: (1) a participant (mavit, 2026-10-20) did crash git sox_ng under AddressSanitizer in lsx_ms_adpcm_block_expand_i, so the crash claim is supported; his 2026-10-23 comment says the reproduction needed a modified src/Makefile; (2) no maintainer comment promising a fix appears in the thread; the maintainer's first reply (2026-10-19) was 'I don't know. Is it?' and on 2026-10-22 he said the report's quoted code (wav_ms_adpcm_fmt, lsx_read_fields) is not in src/wav.c and he had found no file that provokes the error; (3) another participant (2026-10-23) explains the report targets a different SoX lineage with changes absent from sox_ng, and points to wav.c:1051 startread_wav() as the corresponding sox_ng code. Failure modes. Treating sox_ng as either clean or confirmed-fixed is unsupported: exposure is reproduced by one third party under sanitizer but the report's fix text does not map onto sox_ng and the issue is still open. Limitations. Thread may have been edited after this read; the claimed 2026-10-21 maintainer statement may have been in a deleted or edited item, which I cannot see. Version/date. Issue state open, last updated 2026-10-23T17:58+02:00; sox_ng latest tag 14.8.1 (2026-08-29); main head 1abe5b9 (2026-10-18). · locator: issue 877 comment 2026-10-20 (mavit); issue 877 comment 2026-10-19 (maintainer); issue 877 comment 2026-10-22 (maintainer); issue 877 comment 2026-10-23 (danadam) source
Rights
| component | license | hosting | redistribution | modification | training | Evidence and notes |
|---|---|---|---|---|---|---|
| documentation | unknown | permitted | permitted | unknown | unknown | Applies to this original summary only, not to the cited sources. |