Hi,

The following vulnerability was published for speex. The security tracker
currently records no fix, but upstream merged one on 2026-11-01:

CVE-2026-116741[0]:
Speex (libspeex) through 1.2.1 contains an out-of-bounds write in
speex_bits_read_whole_bytes() in libspeex/bits.c. When the SpeexBits
structure does not own its buffer and the input is larger than the free
space, nchars is truncated to bits->buf_size, ignoring the bytes already
in the buffer (bits->nbBits). The copy loop then writes up to
pos + buf_size bytes, i.e. past the end of the caller-supplied buffer.

Upstream report:
https://www.google.com/url?q=https://github.com/xiph/speex/issues/42&source=gmail&ust=1793764410596000&sa=E
Upstream fix:
https://www.google.com/url?q=https://gitlab.xiph.org/xiph/speex/-/merge_requests/32&source=gmail&ust=1793764410596000&sa=E
https://www.google.com/url?q=https://gitlab.xiph.org/xiph/speex/-/commit/09b569d1b437e5edccf3406a38714ad795e46d38&source=gmail&ust=1793764410596000&sa=E

The fix is a one-line change that uses the same bound as the existing
realloc-failure branch:
--- a/libspeex/bits.c
+++ b/libspeex/bits.c
@@ -174,7 +174,7 @@ EXPORT void speex_bits_read_whole_bytes(SpeexBits
*bits, const char *chars, int
}
} else {
speex_warning("Do not own input buffer: truncating oversize input");
- nchars=bits->buf_size;
+ nchars=bits->buf_size-(bits->nbBits>>LOG2_BITS_PER_CHAR)-1;
}
}

I checked that it applies cleanly to the 1.2.1-3 source (patch -p1
--dry-run against libspeex/bits.c from
https://www.google.com/url?q=http://sources.debian.org&source=gmail&ust=1793764410596000&sa=E).
I have not
built or runtime-tested the package with it.

If you fix the bug, please make sure to include the CVE identifier in
your changelog entry.

[0]
https://www.google.com/url?q=https://security-tracker.debian.org/tracker/CVE-2026-116741&source=gmail&ust=1793764410596000&sa=E
https://www.google.com/url?q=https://www.cve.org/CVERecord?id%3DCVE-2026-116741&source=gmail&ust=1793764410596000&sa=E

Thanks!