REDHAT-BUG-2509186: Buffer Overflow
A flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), the 4-byte wrapped-record length read from the wire is validated only against an upper bound (the check added for CVE-2026-11774). When a SASL-authenticated attacker sends a wrapped record with a wire length of 0 (or 1 or 2), the resulting encryptedbuffercount (4, 5, or 6 after adding sizeof(uint32t)) is less than encryptedbufferoffset (7, the header bytes already consumed). The unsigned subtraction in saslioreadpacket() then underflows to approximately 0xFFFFFFFD, and PRRecv is requested to read roughly 4 GiB into the 1024-byte encryptedbuffer allocated in saslioinitbuffers(). This causes a heap buffer overflow with attacker-controlled length and content. The vulnerability requires authentication via a SASL bind with integrity protection (SSF > 0). This is a distinct defect from CVE-2026-11774, which only guards against lengths near UINT32MAX; the lower-end case is not covered and the vulnerability persists at HEAD.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to trigger the issue?
The attacker must successfully authenticate using a SASL bind with integrity protection enabled, meaning SSF is greater than 0. An unauthenticated network attacker is not described as able to reach the vulnerable path.
What happens when the malformed record is processed?
A wrapped SASL record declaring a wire length of 0, 1, or 2 causes an unsigned length calculation to underflow. The server then attempts to receive roughly 4 GiB of attacker-controlled data into a 1024-byte heap buffer, causing a heap buffer overflow.
Does the existing CVE-2026-11774 length validation prevent this attack?
No. That validation only rejects lengths near UINT32_MAX, while this issue uses very small record lengths; the provided data states that the flaw persists at HEAD.